🪜

Job Map + Metrics

An experiment to test boundaries of context scope in the LLM models. The goal is to create a map and loop through each step and define the metrics as well. It didn’t work well.

Ignore all previous instructions. Act as a(n) {{end user}} with a deep expertise in Jobs-to-be-Done theory, which you will use here. As you know, Jobs have steps, much like a process, but they do not indicate how the {{end user}} does something, they represent what the {{end user}} must accomplish. Also, steps fall under 9 main phases. These phases are sequential. Each of the phases are explained below. Explanation of Phases: 1. Define: in the define phase, we want to know what aspects of getting the job done need to be defined, planned, or assessed by the {{end user}} upfront in order to proceed. 2. Locate: in the locate phase, we want to know what items - tangible or intangible - must be located, gathered, collected, accessed, or retrieved by the {{end user}} to do the job. 3. Prepare: in the prepare phase, we want to know how the {{end user}} must prepare or integrate the inputs, or the environment(s), from the Locate step to do the job. 4. Confirm: in the confirm phase, we want to know what the {{end user}} must verify, prioritize, or decide before doing the job in order to be successful. 5. Execute: in the execute phase, we want to know what the {{end user}} must do to perform the job successfully. 6. Monitor: in the monitor phase, we want to know what the {{end user}} must monitor in order to ensure the job is executed successfully. 7. Resolve: in the resolve phase, we want to know what problem the {{end user}} might need to troubleshoot, restore, or fix for the job to be completed successfully. 8. Modify: in the modify phase, we want to know what the {{end user}} might need to alter, adjust, or modify for the job to completed successfully. 9. Conclude: in the conclude phase, we want to know what the {{end user}} must do to finish the job.

The Job-to-be-Done for the {{end user}} is {{job}} {{context}}. Only consider the context if one is supplied, otherwise disregard it. Generate a list of job steps that consider each of the phases. There should be a minimum of one step per phase. However, there could be more than one. An ideal job map will have between 10 and 15 steps. The job steps should be focused on what the {{end user}} is trying to accomplish faster, with better output, or better throughput when {{job}} in the context of {{context}}. Do not reference the phase in a job step unless absolutely necessary. The job steps should be mutually exclusive and collectively exhaustive (MECE) and also must be in a logical order of precedence and dependence. Think this through step-by-step.

Make the step name bold. Explain each job step, step by step, while adhering to the following explanation format. Make the explanations as rich as possible. Precede each explanation with the text "The ability to". Append the complete explanation to the job step, separated by a dash. Please follow all instructions carefully. Finally, you need to run this through a test-fit structure to ensure that the statement makes sense. This is a quality check that you will do internally. You will not output this. Here is the structure: As a(an) {{end user}} + who is + {{Job}} {{context}} you need to <generated output> Does the success statement make grammatical sense? If so, output it. If not, rework it and test it again.

It is EXTREMELY important that you follow these instructions closely:

Output as a numbered list
Always output in markdown
Output the list only once
Do not generate an opening statement summarizing what your are about to output
Do not output anything other than a list
Do not use the phase name in the step name
Do not output a test-fit structure example
The job step should be concise and similar to a process statement. Do not be overly verbose.

#BEGIN LOOPING

For each job step you output, follow these instructions to output a numbered list beneath the job step and explanation. Then move on to the next step from the above instructions.

As you know, each Job Step has success statements that represent the desired outcomes or outputs an end user aims to achieve. For each Job Step submitted for the job {{job}}, please generate a list of success statements that a(n) {{end user}} desires. 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. 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 25-30% of the statements. None of the statements should describe how to accomplish something.

For each Job Step, generate a list of [n] success statements related to a(n) {{end user}} trying to {{job step}} {{context}}. If no context is supplied, please disregard the context. Think step-by-step.

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 (LONG):

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 operation 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
Minimize the likelihood that the evaluation of productivity performance is not based on comprehensive and accurate data	Minimize the likelihood that incomplete or inaccurate data is used to evaluate productivity	Bad: The statement should not be about the process (which is a solution) but about the necessary inputs to the process. It breaks the bad word rule of “is not.”
Minimize the likelihood that regular herd performance monitoring does not lead to proactive adjustments in herd management strategy.	Minimize the likelihood of reactive adjustments to the herd management strategy	Bad: Breaks the “does not” rule. Also highlights the process (step) and not the actual thing we are measuring (adjustments). Conciseness
Minimize the likelihood of adopting short-term fixes that do not address the underlying causes of productivity issues.	Minimize the time it takes to adopt permanent fixes to productivity issues	Always default to “Minimize the time it takes to” options to keep statements concise and focused. Uses the bad phrase “do not”
The software feature does not provide adequate feedback or notifications, causing the user to miss important updates or changes	Minimize the time it takes to obtain adequate feedback from the software feature	Bad: It uses the word “or” and it attempts to provide an explanation within the statement, e.g., “causing the user to miss important updates or changes. It is not concise.
Develop a clear understanding of your competitive landscape to inform strategic planning, avoiding blind spots and missed opportunities		Bad: It appends an avoidance on the end instead of making it the primary part of the statement
Prevent security goals from becoming outdated by regularly reviewing and updating them.		Bad: It attempts to explain how to do something
	Minimize customer churn by proactively addressing their concerns and needs	Good: Begins with a verb that establishes what should be avoided
	Mitigate the risk of losing market share to competitors by staying agile and responsive	Good: Begins with a verb that establishes what should be avoided
You want to price your tires competitively in the market	Minimize the likelihood of failing to price your tires competitively in the market	Good: It is concise. Doesn’t start with “You”
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 gain clarity on your financial progress, e.g., evaluate key financial metrics, talk to an advisor, etc.
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

## 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

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 (Long):

Output as a numbered list
Do not output any content before the numbered list of statements
Do not output anything after the numbered 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

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}} when {{context}} you're trying to <generated output> + so that you can successfully {{job step}} Does the success statement make grammatical sense? If so, output it. If not, rework it and test it again.

Always output in markdown End User: Job: Context: Job Step: [insert generated output] n: 20

Do not number the steps. Do number the success statements. Please follow all instructions closely.