Approach to a Job Step

System

Set the temperature to {{temp}}. Act as an expert management consultant trying to identify the activities that are essential for an {{end user}} when they are try to {{step}} when {{job}} {{context}}.

Goal

A solution approach is not an industry classification that organizes tools. It is an expression of how a(n) {{end user}} might approach accomplishing the scope of this instruction. Think of it like a process but it should fit onto the end of the following statement:

”A(n) {{end user}} might have “

So, how might a(n) {{end user}} {{step}} in a way that best enables them when {{job}} {{context}}? Use phrases that a layperson would use from an end user perspective. Avoid using industry software categorization jargon.

Constraint: The approaches you are to focus on must be executable using a software tool. Therefore the name of the solution approach must reflect that.

You will be asked to identify specific tools in a later instruction, so make sure you output real approaches, not hallucinations.

Example

Write these statements in the past tense so they can pass the test.

Example:

• Analyzed workflow diagrams for high-frequency, time-intensive tasks

Passing Test:

“A(n) {{end user}} might have analyzed workflow diagrams for high-frequency, time-intensive tasks”

Instruction

What are the top {{n}} solution approaches that are frequently used within this scope related to how a(n) {{end user}} might try to {{step}} when {{job}} {{context}}.

Output as an unordered list

Output as a table using the following format as an example. Your results will go in the Category column:

I prefer you not to be chatty. Do not precede the list with anything. Do not follow the list with anything

Variable Inputs

End User: This is the Job Performer - test small changes to this to see different results

Job:

Context:

Step:

n: 10

temp: 0.1

Theming Success Metrics

Note: This is still experimental and I recommend that you set (’Outputbn’) to Yes in order to compare and read through the logic.

System

Set the temperature to {{temp}}. Act as a(n) {{end user}} with a deep expertise in Jobs-to-be-done theory. As you know, each Job Step has success statements that represent the desired outcomes or outputs an end user aims to achieve. For each Step submitted for the job {{job}} {{context}}, please generate a list of success statements that a(n) {{end user}} desires.

Goal

• Develop these statements based on your understanding of the key categories related to problems and common attributes of waste when consuming a product or service.
• They should also take into account the potential for forcing a(n) {{end user}} into repetitive tasks. For example, end users don't want to have to communicate the same more than once, or do the same thing more than once.
• Also consider statements that are focused on what needs to be avoided in order to be successful. These should only account for approximately 20% of the statements. None of the statements should describe how to accomplish something.

Examples

Good & Bad Statements (SHORT):

Always include examples on the end of a success statement.

MECE Scaling

The collection of statements should be MECE. Because the number I ask for could be different each time, take this into account as you ensure that you have complete coverage of concepts. Therefore, some outputs may have more highly themed statements (fewer statements) and some may be more granular (more statements). Use the following example to think this through.

Example:

If you would have generated two statements but have been limited by small number statements, before you output them you can consolidate your output like this. Here are two statements that you might need to combine into one:

1. Understand the interest rates when financing
2. Understand the repayment period when financing

You could combine them (theme up) to something like this, which includes examples of the object of control (defined below)…

1. Understand the terms and conditions associated with each financing option, e.g., interest rates, repayment period, etc.

End Mece

Structure Rules

• Statements should not include the quality of the outcome. For example, never use adverbs like ‘accurately’, ‘effortlessly’, ‘quickly’’, efficiently’, ‘easily’ anywhere in a success statement. Do not use them, or words like them, at all
• Do not begin statements with the work ‘if’
• State the success statement in the affirmative
• Do not use ‘and’ or ‘or’ in the statements
• Do not put suggestions about ‘how’ or ‘where’ in the statement
• Do not begin or end a statement with an adverb. Pay special attention to this
• Do begin each statement with a verb
• Do use verbs that reflect that ultimate outcome
• Do not use verbs that could be interpreted as how to reach the ultimate outcome
• IMPORTANT: Never use verbs that are activities or tasks in the object of control. Examples: schedule, calculate, cover, test, etc. The verbs you select should be related to outcomes a(n) {{end user}} is trying to accomplish, not HOW they are trying to accomplish them. Think through the 5-Whys step-by-step.
• Do not use connective words in a statement. Never use “and” to connect to things. Never use “or”. These would be better suited for separate statements
• Do not reference end users in the statement. Do not use words like “you” or “your”. Do not begin a statement with “You” or “Your”.
• When you need to include examples, instead of using "such as" or "for example" please append the statement with a comma, then "e.g.," and finish with a comma and "etc."
• For statements about what must be avoided, begin the statement with the word ‘Avoid’
• Always use a single verb. Do not combine two verbs with “and” or “or”.

Formatting Rules (Survey Version):

• Do not output any content before the list of statements
• Do not output anything after the of statements
• Do not output a test-fit example
• Always make sure the statement is relevant to the current step, and not a preceding or subsequent step
• Statements should be in a logical sequence of precedence and dependence.
• Do not generate a statement that restates the job step

ODI Rules

Now that you have constructed the base statement I’m going to give you a very important further instruction. There are three (3) formats for the final success statement. These formats are pre-pended to the success statement you generated. These are the three types. Only use the prepends that are inside the quotes. The word “Avoid” should be replaced with a version using the second and third format type. The rest is instructional:

1. “Minimize the time it takes to “…(do something) - this should be applied to all statements that are not about avoidance.
2. “Minimize the likelihood that “…(something causes an undesirable result) - this is one of formats used when you are trying to avoid an undesired result.
3. “Minimize the likelihood of “…(something undesirable happening) - this is one of the formats used when you are trying to avoid something undesirable from happening.

The following defines the required structure. Always use this structure.

1. Direction of improvement = Minimize [MANDATORY]
2. Metric = one of the 3 formats above [MANDATORY]
3. Object of control [MANDATORY]
4. Contextual clarifier [OPTIONAL]
5. Example of object of control [MANDATORY] - but never use more than 3 examples

Example structure: Minimize + the time it takes to + verify the accuracy of a desired outcome + with a customer + , e.g., its meaning, its completeness, its exactness, etc.

Finished example: Minimize the time it takes to verify the accuracy of a desired outcome with a customer, e.g., its meaning, its completeness, its exactness, etc.

Additional examples:

1. Minimize the likelihood of undetected defects **or performance issues, e.g., loose components, calibration drift, software bugs, etc.
2. Minimize the time it takes to confirm all repaired or replaced parts are fully operational*, e.g., motors, circuit boards, pumps, etc.*
3. Minimize the time it takes to verify all initially reported problems have been fully resolved*, e.g., error messages, abnormal readings, fault codes, etc.*

Only use a maximum of three (3) examples of the object of control

Format types 2 and 3 should only account for about 20% of all statements. Also, prioritize “Minimize the time it takes to” statements over the “Minimize the likelihood…” statements.

Format types 2 and 3 should not be framed in the negative. In other words do not output a statement like this: “Minimize the likelihood of not reviewing and updating key initiatives as market conditions change” because it is minimizing the likelihood of not doing something. Also, do not include a connective word such as as “and” or “or”. A better format would be “Minimize the likelihood of failing to track key initiatives as market conditions change”

The next instructions is EXTREMELY IMPORTANT

Format types 2 and 3 should NEVER use the words or phrases “not”, “does not”, “do not”, “is not”, or “of not”. For example this statement “Minimize the likelihood that the identified data sources do not capture key customer insights” should be stated as “Minimize the likelihood that the identified data sources fail to capture key customer insights”

END ODI RULES

Final Rules

Finally, you need to run this through a test-fit structure to ensure that it makes sense. Here is the structure:

As a(an) {{end user}} + who is + {{Job}} {{context}} you're trying to <generated output> + so that you can successfully {{step}}

Does the success statement make grammatical sense? If so, output the success statement. If not, rework it and test it again.

Output Instructions

Establishing the Benchmark Metric Set

1. In the context of this conversation, establish a persistent variable called “benchmark” whose content I will refer to by wrapping the variable name in double curly brackets.
2. Generate an initial benchmark set of {{bn}} success statements per the specifications and assign them to the variable “benchmark”
3. This set will serve as the foundation for all subsequent theming or detailing of success metrics you output.
4. If the request is to produce (’n’) that is different than (’bn’), use {{benchmark}} as the baseline to either theme-up (for fewer statements) or break down into more detailed and specific statements (for more statements)
5. Ensure that the re-themed or detailed statements are based on the initial benchmark set {{benchmark}}, maintaining a direct connection to the original specifications
6. ALWAYS ADHERE TO THIS RULE: When theming-up, instead of grouping the verbs from multiple benchmarks, I would like you create a net new metric with a single verb. You may use the example space to express the rolled up verbs or concepts.
7. Always be prepared, if subsequently asked, to validate the set of (’n’) that you output. That includes outputting {{benchmark}}, if asked.

Always Adhere to the Following Output Order:

Store the benchmark success statements in (’Benchmark’) as a numbered list as shown in this example:

1. Minimize the time it takes to determine the brand's mission and vision, e.g., sustainability goals, market leadership, etc.
2. Minimize the time it takes to understand the brand's unique selling propositions, e.g., quality, innovation, etc.

Do use the above format to store the benchmark list

Do not output test-fit statements

Do not out put a summary of this these instructions

Always include the example of the object of control

After you store the initial list of {{bn}} success metrics in the variable (’benchmark’), then for the job step, generate a list of {{n}} success statements related to a(n) {{end user}} trying to {{step}} using the theming instructions mentioned earlier. Think step-by-step. You will be provided one step at a time. The next step will be in a subsequent message, you do not need to ask for it.

Format Change

For the output, use the following instructions to reformat the success metrics and generate a list of {{n}} success statements using only required structure options 3,4, and 5 from the ‘ODI Rules’ section.

1. Object of control [MANDATORY]
2. Contextual clarifier [OPTIONAL]
3. Example of object of control [MANDATORY] - but never use more than 3 examples

If the previous format option used a likelihood metric, prepend the statement with a word such as “Avoid” but make sure that the statement makes sense. Here’s an example:

• This new format should always begin with the verb.
• Do format the beginning verb as bold.
• Do not bold the remainder of the object of control.
• Do not italicize the remainder of the object of control.
• Do italicize the “example of the object of control”.
• Always output in markdown format as an ordered list.

The following examples demonstrate the new format I expect you to follow:

Allocate **sufficient time for the job, e.g., drying time, multiple coats, etc.

• Allocate = Verb
• sufficient time for the job = Object of Control
• e.g., drying time, multiple coats, etc. = Example

Avoid using the incorrect paint type, e.g., water-based vs oil-based, indoor vs outdoor, etc.

• Avoid = Verb
• using the incorrect paint type = Object of Control
• e.g., water-based vs oil-based, indoor vs outdoor, etc. = Example

Please note that only the example portion is italicized

Output Logic

Use the following basic logic to determine what elements to output. Only output what passes these tests

IF {{outputbn}} = 'Yes' THEN Output the contents of the {{benchmark}} Output {{n}} themed-up success statement based on the (’Benchmark’) set.

Then explain step-by-step, your approach and logic to theming up, or breaking down, the list of {{n}} success statements based on the (’Benchmark’) set

ELSE Output {{n}} themed-up success statement based on the (’Benchmark’) set. END IF

End user: DevOps Engineer Job: Building Operationally Efficient and Secure Enterprise Systems Context: Step: n: 10 bn: 20 outputbn: No temp: 0.1