Jobs to be done: the JTBD framework, interviews and job stories

Keep three levels apart when you read an interview:

A task can reveal a hard point, but on its own it doesn't explain a purchase. Naming a solution doesn't prove the job. Move between the levels on purpose so the research stays sharp without getting stuck inside your current product.

Most jobs have three sides, and a decision is often driven by the two people don't mention first:

Don't force three tidy sentences into every interview. Look for evidence that each side shaped the choice. If someone keeps mentioning rehearsal, ask what they were afraid would happen and what being ready meant to them.

Every switch is a balance between forces that pull someone toward a new way and forces that keep them where they are:

These are hypotheses until interviews back them up. A study might show that the feared migration problem is small and internal approval is the real wall. A new feature raises pull, but if anxiety is what blocks adoption, a clear migration plan, setup help or a smaller trial may matter more.

Pick the approach that fits the decision your research has to support:

Write the decision down first. Understand customers is too broad. Decide whether onboarding should tackle migration risk or setup effort gives the study a boundary and a way to judge whether it worked. And say which artifact you are producing, especially when several teams will use it.

Recruit people who recently made the change you care about, plus some who nearly did and stayed put. Then rebuild one real decision:

1. 1

   Anchor the event. Which purchase, cancellation, workaround or change do they remember, and roughly when was it?

2. 2

   Explore the old way. What were they doing before, and what about it worked well enough to keep?

3. 3

   Find the first thought. When did they first think they needed something else, and what happened just before?

4. 4

   Rebuild the search. What did they look at, compare and rule out?

5. 5

   Understand the choice. What tipped the decision, and what nearly stopped it?

6. 6

   Check real use. How did what they expected compare with what happened after they switched?

This follows the JTBD timeline from first thought through looking, deciding, buying and use. Treat it as a guide, not a script: follow the person's story and fill the gaps later. Useful prompts include what happened right before that, what did you try next and what made that option not work.

Take notes in three columns, so a guess never passes for a finding:

Keep contradictions instead of smoothing them over. Someone may call a solution expensive and still pick it over a cheaper one; the cheap option may have needed more coordination or felt riskier. And don't claim a handful of interviews shows how common a need is. Use interviews to form and sharpen ideas, then size them with other research.

A job story, the format Intercom popularized, has three parts: When [situation], I want to [motivation], so I can [expected outcome]. Here is a weak draft and a stronger one:

The weak version ties the situation to using the product, names a solution as the motivation and gives an outcome nobody can test. The stronger one names a real moment and a real struggle, leaves room for several solutions and raises good follow-up questions: which systems, which issues, and what makes an issue easy to miss?

Outcome-Driven Innovation keeps two things apart. A job statement says what someone is trying to get done: prepare priorities for a client review. A desired outcome statement says how they judge whether it was done well, for example minimize the time it takes to find open issues, or minimize the chance of missing an issue that blocks the client. Check candidate outcomes with customers before treating them as needs.

Run every statement through these checks before you share it:

• Situation: It names a real trigger or setting.
• Progress: It shows what the person is trying to achieve.
• Neutral: More than one kind of solution could meet it.
• Evidence: The main claims trace back to research.
• Scope: Specific enough to study, broad enough not to be a button click.
• Clear: Someone outside the project would know what success means.

If a statement fails several checks, go back to the research. Rewording can't fix missing evidence.

Use it as a working research document. Each field links the final statement back to the evidence behind it:

Note the scope of each finding. A worry from one person should not quietly become a universal need.

For a short workshop, put each evidence-backed job on a card with the same fields:

Group cards by similar situations, struggles and success criteria, not by shared words like speed or confidence. Two people can both ask for speed while facing unrelated limits. Then look at the differences inside each group: a new user who wants reassurance may need something different from an expert who wants control.

End with a decision record: the opportunity chosen, the evidence behind it, the options rejected and the next test. Without it, a wall of cards can look like agreement without changing what anyone does.

Once a job is backed by evidence, use it to compare options rather than to justify one feature. For the client review job, a single issue view, clearer ownership and a better preparation checklist each fit a different cause. Test the cause before committing to the biggest build. Compare opportunities on the same questions:

• Evidence strength: Is it based on real accounts or on guesswork?
• Consequence: What happens when the person can't make progress?
• Current alternatives: Where do today's options work, and where do they fail?
• Strategic fit: Can your organization credibly solve this?
• Constraints: What could block a useful solution?
• Learning value: Which next test would settle the biggest doubt?

Skip numeric scores unless you define the inputs and keep evidence apart from judgment; a clear written assessment beats fake precision. For marketing, describe the situation and the progress the offer can actually support. Prepare client priorities without checking several systems is testable; unlock productivity is not. Use the anxiety and habit forces to decide what reassurance belongs next to the offer, such as setup details or a demo of a real workflow.

After launch, measure progress, not only usage. More dashboard visits could mean the tool is useful or that people keep failing to find what they need. Read usage alongside task success, customer reports and the result you set out to improve. Actionable metrics and A/B testing cover how.

Watch for these in your own work:

1. 1

   Starting with the feature. Rewrite the job without naming your solution and check that the progress still reads clearly.

2. 2

   Vague wishes. Replace save time with the exact work, situation and result.

3. 3

   Ignoring what the old way does well. Record why people keep it, not only where it hurts.

4. 4

   Treating everyone as one group. Compare situations and trade-offs before merging accounts.

5. 5

   Overstating a pattern. A likely pattern from a few interviews is not proof of how common it is.

6. 6

   Stopping at notes. Give the chosen opportunity one owner, one decision and one next test.

The sentences and the cards are not the point. The point is clearer thinking about whose struggle matters, why the current way falls short and what evidence would justify building something else. When you are ready to test, a minimum viable product is often the next step.