Writing Desired Outcome Statements for JTBD

Write desired outcome statements for each job step: direction, metric, object of control and clarifier, solution-free and ready to survey.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Writing desired outcome statements is how the Jobs-to-be-Done (JTBD) Framework turns a job map into something measurable. A desired outcome is a metric the job executor uses to judge whether a step of the job is going well. In Ulwick's Outcome-Driven Innovation, each outcome is written in a fixed structure: direction of improvement, metric, object of control and contextual clarifier. Strategyn's example is "minimize the time it takes to identify the correct drill bit size for the material being drilled" (Strategyn JTBD template).

The strict structure is there for the survey. Customers will rate each statement for importance and satisfaction, and Strategyn's whitepaper warns that differences in structure, terminology and syntax between statements add variability that changes those ratings (ODI whitepaper). If one statement says "minimize the time" and another says "make it quicker", respondents are reacting to wording as much as to need.

The statements must also be solution-free and stable. They describe how the executor measures success at a step, not a feature that would help. "Have an automatic reminder" is a solution. "Minimize the likelihood of missing a payment deadline" is the outcome that the reminder might serve, and it would stay true if reminders were replaced by something better.

The output is a list of outcome statements organized by job step, typically dozens for a single job. Strategyn's guidance is to capture 5 to 10 outcomes per job step and 100 or more in total across the core job and related categories (needs framework). The list becomes the item bank for Identifying Underserved Outcome Opportunities.

How It Works

Each part of the statement has a job:

• Direction of improvement: almost always "minimize", occasionally "increase" or "maximize". Using one direction consistently keeps the survey readable.
• Metric: the unit the executor cares about, most often time, likelihood, number, amount or frequency.
• Object of control: what is being measured, stated in the context of the job step. This is where the content lives.
• Contextual clarifier: an optional phrase that pins down when or where the outcome applies.

Put together: "minimize the likelihood of paying an invoice twice when a supplier resends it". Direction is minimize, metric is likelihood, object of control is paying an invoice twice, and the clarifier is when a supplier resends it.

Outcomes come from the executor's struggles at each step. In interviews, customers describe problems in their own terms: "I never know if the numbers are current", "it takes forever to find the right file". Each complaint usually points to a speed, stability or output concern at a step, and each can be restated as an outcome. The whitepaper describes capturing statements about the speed, stability and output of each process step until the needs are complete (ODI whitepaper).

A good statement passes four tests. It names one metric, so a respondent can rate it. It contains no solution, so it does not favor any product. It is stable, so it would have been true before today's tools. And it uses words a job executor would recognize, so the survey measures need rather than comprehension.

The core functional job is not the only source. Strategyn's needs framework also collects outcomes for consumption chain jobs such as setting up and maintaining a product, related jobs, emotional jobs and financial outcomes (needs framework). Keep these in separate sections so the core job's outcomes are not diluted.

The format has limits. Some emotional needs are awkward to phrase as a minimize statement, and forcing them produces strained wording that respondents misread. Write those as plain emotional job statements and keep them out of the importance and satisfaction scoring if they do not fit.

Step-by-Step Guide

Step 1: Gather the job map and interview evidence

Lay out the validated job map, step by step, and the notes from your interviews. Tag each quote or observation with the job step it relates to. Quotes that do not fit any step may reveal a missing step or a related job, so flag them. If a step has no evidence at all, plan more interviews before writing outcomes for it.

Step 2: List the struggles for one step

Pick one step and list every difficulty, delay, error or uncertainty customers mentioned there. Include workarounds, since a workaround signals an unmet outcome. Ask what could go wrong at this step in terms of time, errors, effort and missing information. Keep the list in the customer's words for now.

Step 3: Choose the metric and direction

For each struggle, decide what the executor is trying to reduce or increase. Delays become time, errors become likelihood, repeated effort becomes number or frequency. Use "minimize" unless the natural measure is something the executor wants more of. One struggle may yield two outcomes if it involves both time and error.

Step 4: Name the object of control

Write what is being measured in terms of the job step, not the product: "the time it takes to determine which invoices are due", not "the time it takes to load the invoice list". Check that the object would still make sense if your product did not exist. Replace any tool, feature or interface word with the underlying goal.

Step 5: Add a clarifier where it removes ambiguity

Add a contextual clarifier when the outcome only applies in certain situations or when two statements would otherwise read the same. Keep it short. Leave it off when the statement is clear without it, since extra words make surveys slower to answer.

Step 6: Repeat across every step and category

Work through every step of the job map the same way, then the consumption chain, related, emotional and financial categories you plan to include. Keep the structure identical across all statements. Track counts per step, and look again at any step with far fewer outcomes than the others.

Step 7: Edit the full list

Read the whole list in one pass. Remove duplicates and near-duplicates, split statements that contain two metrics or two objects, and cut any statement that describes a solution. Standardize verbs and metric words so similar statements are phrased the same way. The whitepaper's warning about wording variability applies here (ODI whitepaper).

Step 8: Test with job executors

Show a sample of statements to a few executors and ask them to explain each one back in their own words. Rewrite any statement they misread or find irrelevant. Ask whether anything important about a step is missing. The list is ready for a survey when executors understand every statement without help.

Best Practices

• Write outcomes from evidence, then check coverage with the metrics. A list written from the metrics alone tends to produce generic statements that apply to any job.
• Keep one statement per metric and object. A statement with "and" in it usually needs to be split, because a respondent cannot rate two things at once.
• Keep a glossary of the objects of control and reuse the same words. Consistent wording makes ratings comparable across statements.
• Review statements in the order the survey will present them, grouped by job step. Respondents rate more reliably when the context stays stable.
• Mind survey length. Critics of the ODI survey point out that rating a long list on two scales is demanding for respondents (Buchanan's critique), so cut statements that add little before fielding.

Common Mistakes

• Writing features as outcomes: "Have a dashboard of overdue invoices" is a solution. Ask what the dashboard would help the executor achieve and write that: "minimize the likelihood of missing an overdue invoice".
• Using vague metrics: "Make it easier to reconcile accounts" gives respondents nothing to rate. Choose a unit such as time, likelihood or number, and name the object precisely.
• Mixing wording styles: Statements that vary in verb and structure get rated partly on wording. Use the same structure for every statement (Strategyn JTBD template).
• Writing outcomes only for the execute stage: Most teams know the core action best and neglect planning, gathering and wrapping up. Check that every step of the job map has statements.
• Skipping the customer test: Statements that seem clear to the team can be opaque to executors. Test comprehension before a survey spends budget on them.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Jobs-to-be-Done (JTBD) Framework

Related Skills

• Creating Job Maps
• Identifying Underserved Outcome Opportunities
• Conducting JTBD Customer Interviews

Sources

• Strategyn: Jobs to Be Done template
• Strategyn: Customer Needs Through a Jobs-to-be-Done Lens
• Ulwick, What is Outcome-Driven Innovation? (Strategyn whitepaper)
• Braden Buchanan: Outcome Driven Innovation, a critique

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.