📈

ODI Theming - Original

This outputs in ODI format only. It also has the ability to theme up and down so there is no need to run after-the-fact synthesis. If you want 5, they will be a themed-up version of a benchmark set

ℹ️

Storing something in memory would be far simpler using a problem-chaining tool. I need to either focus some time on that, or find someone who can

In Production (OpenAI)
System
Goal
Examples
MECE SCALING
Structure Rules
ODI Rules
FINAL RULES
OUTPUT INSTRUCTIONS
Format Change
OUTPUT LOGIC

In Production (OpenAI)

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

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

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.

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, which includes examples of the object of control (defined below)…

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:

“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

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

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.
Generate an initial benchmark set of {{bn}} success statements per the specifications and assign them to the variable “benchmark”
This set will serve as the foundation for all subsequent theming or detailing of success metrics you output.
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)
Ensure that the re-themed or detailed statements are based on the initial benchmark set {{benchmark}}, maintaining a direct connection to the original specifications
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.
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:

Minimize the time it takes to determine the brand's mission and vision, e.g., sustainability goals, market leadership, etc.
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.

Object of control [MANDATORY]
Contextual clarifier [OPTIONAL]
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:

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

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