Set the temperature to {{temp}}. Act as a(n) {{end user}} with a deep expertise in Jobs-to-be-done theory, which you will use here. As you know, {{end user}}s want to be successful when {{job}}{{context}}. I would like you to develop a list of {{n}} success statements that an end user desires. These statements should be developed based on your understanding of the key categories that relate to problems. You may also consider 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 information more than once, or do the same thing more than once. Of equal importance are success statements that are focused on what needs to be avoided in order to be successful. These should account for approximately 20% of the statements. Begin these statements with the word “Avoid”. None of the statements should describe how to accomplish something. Generate a list of success statements related to a(n) {{end user}} {{job}}{{context}}. Think step-by-step. Do not generate a job map.
Bad | Good option | Reason |
does not | fails to | Do not use negative auxiliary verbs |
is not | Do not use negative auxiliary verbs | |
do not | fail to | |
or | The success statement should not incorporate trade-offs or make the end user make a choice between two things | |
of not | failing to | |
and | there should only be one success consideration per 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:
- Understand the interest rates when financing
- Understand the repayment period when financing
You could combine them (theme up) to something like this…
- Understand the terms and conditions associated with each financing option, e.g., interest rates, repayment period, etc.
## END MECE
Good & Bad Statements (SHORT):
Always include examples on the end of a success statement.
Bad statement | Good statement | Reason |
Minimize the time it takes to confirm the equipment is operating within required parameters, e.g., temperature range, speed settings, accuracy, etc. | It elaborates with clear examples | |
Minimize the time it takes to verify all safety mechanisms and alarms are functioning properly, e.g., sensor calibration, redundant fail-safes, etc. | It elaborates with clear examples | |
Calculate key financial metrics and ratios, such as your savings rate, debt-to-income ratio, or investment returns, to provide insights into your financial performance and goal achievement | Minimize the time it takes to understand your financial progress, e.g., evaluate key financial metrics, talk to an advisor, etc. | Calculate is not an outcome, it is an activity. Never include activities or tasks (do verbs) in a success statement. A five-whys analysis - “Why do you need to calculate key financial metrics?” - would result in the good outcome-focused statement. A better verb would be understand, know, determine, etc. |
Minimize the time it takes to calculate the quantity of paint required, e.g., room dimensions, paint coverage, etc. | Minimize the time it takes to determine the quantity of paint required, e.g., calculate room dimensions, calculate paint coverage, etc. | Another example using the same bad verb “calculate.” It’s perfectly fine to use activity verbs in the example of the object of control BUT NOT IN THE OBJECT OF CONTROL ITSELF |
Minimize the likelihood that poorly defined productivity goals lead to misalignment in resource allocation. | Minimize the likelihood of misaligning resource allocation, e.g., due to poorly define productivity goals, etc. | |
Minimize the likelihood of emergency situations due to shipment or team delays | Minimize the likelihood of emergency situations, e.g., shipment delays, team delays, etc. | Any cause should be expressed as an example, and not in the statement itself |
Minimize the likelihood that unstable connection triggers extra costs, e.g., failover to expensive network, manual troubleshooting, etc. | Minimize the likelihood that extra costs are triggered by an unstable connection, e.g., failover to expensive network, manual troubleshooting, etc. | |
Minimize the time it takes to conduct a financial review of the project to assess budget adherence and financial performance, e.g., cost-benefit analysis, financial reporting, etc. | Minimize the time it takes to assess budget adherence; e.g. cost-benefit analysis, financial reporting, etc. | Assess is the outcome, conducting something is a task. The bad statement also conflates two different things you might assess |
Minimize the time it takes to conduct a financial review of the project to assess budget adherence and financial performance, e.g., cost-benefit analysis, financial reporting, etc. | Minimize the time it takes to assess financial performance, e.g., cost-benefit analysis, financial reporting, etc. | The bad statement also conflates two different things you might assess, so the good example is the second metric that might be generated. |
Minimize the time it takes to cover furniture and floors to protect from paint spills, e.g., drop cloths, plastic sheeting, etc. | Minimize the time it takes to protect furniture and floors from paint spills, e.g., drop cloths, plastic sheeting, etc. | The bad version suggests how in the object of control. The appropriate place for that is in the examples |
Minimize the time it takes to cover and protect furniture and flooring, e.g., drop cloths, plastic sheeting, etc. | Minimize the time it takes to protect furniture and floors from paint spills, e.g., drop cloths, plastic sheeting, etc. | Once again, “cover” expresses how something is done when all we want is the actual outcome, which is “protect” |
Minimize the time it takes to test paint colors on the wall, e.g., small patches, varied lighting, etc. | Minimize the time it takes to ensure the desired wall color will be achieved, e.g., test small color patches on wall, varied lighting, etc. | Testing is an activity. Always ask “Why are we testing?” Testing should be one of the examples of the object of control instead |
Minimize the time it takes to remove or cover hardware and fixtures, e.g., doorknobs, light switch covers, etc. | Minimize the time it takes to protect hardware and fixtures, e.g., remove or cover doorknobs, light switch covers, etc. | Always ask why we want to remove or cover something because it is the ultimate outcome we want for our success statement. |
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:
- “Minimize the time it takes to “…(do something) - this should be applied to all statements that are not about avoidance.
- “Minimize the likelihood that “…(something causes an undesirable result) - this is one of formats used when you are trying to avoid an undesired result.
- “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.
- Direction of improvement = Minimize [MANDATORY]
- Metric = one of the 3 formats above [MANDATORY]
- Object of control [MANDATORY]
- Contextual clarifier [OPTIONAL]
- 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:
- Minimize the likelihood of undetected defects or performance issues, e.g., loose components, calibration drift, software bugs, etc.
- Minimize the time it takes to confirm all repaired or replaced parts are fully operational, e.g., motors, circuit boards, pumps, etc.
- 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
Always output in markdown End User: Job: Context: n: temp: 0.1