Using the Jobs to be Done Framework Correctly

A common misuse — it has become a restatement of a persona

When a product team adopts JTBD, the most frequent failure is treating the "job" as a mere rewording of attributes. For example, you often see job statements like "A marketer in their thirties wants to make report creation more efficient," but this merely pastes a generic desire — "wants to make it more efficient" — onto the persona attributes of age and occupation, and it does not contain the causal structure JTBD is meant to ask about. The starting point of JTBD, as proposed by Clayton Christensen, is the idea that behind a customer "hiring" a product or service lies a desire for progress that arises in a specific situation. The subject is not who they are, but what situation they are placed in and what they were trying to accomplish.

The causal structure the original work presents

The milkshake study Christensen introduced in his book "Competing Against Luck" is frequently cited as a representative example that explains this difference. Even for the same product — a milkshake — the volume, viscosity, and speed of service the customer expects differ entirely between a shake bought during the morning commute "to keep a long drive from being boring and to be filling with one hand" and one bought in the evening as a treat for a child. Here the "job" is defined not by age or gender but by the combination of a situation (the morning commute / after an evening meal out) and the progress one wants to achieve there (relieving boredom and feeling full / making a child happy). Placing situation and progress, not attributes, as the subject — this is the core of JTBD.

How to write a job statement correctly

A format often used in practice makes explicit three elements: situation, motivation, and desired outcome.

Situation (When...): when, and in what context
Motivation (I want to...): what you want to do / move forward
Desired outcome (So I can...): what you want to gain as a result

Example:
When I need to compile the progress of multiple teams before the weekly standing meeting,
I want to check data scattered across various tools on a single screen,
So I can reduce the time spent preparing materials before the meeting and spend time preparing for the discussion.

Putting it in this format lets you distinguish the feature request "I want a report feature" from the desire for progress "I want to reduce preparation time before the meeting." A feature request is only one proposed solution, and there can be multiple solutions for the same job.

The difference from Tony Ulwick's Outcome-Driven Innovation

There are several schools of thought in applying JTBD in practice. Outcome-Driven Innovation (ODI), proposed by Tony Ulwick, is characterized by breaking down the "desired outcomes" that make up a job into quantitatively measurable statements, and scoring them by the gap between importance and current satisfaction. Compared with Christensen's qualitative causal understanding, Ulwick's method can be said to lean toward quantitative research in its operation. Which one to adopt depends on the data a team has and its decision-making style, and it is not something that can be discussed in terms of superiority. That said, because ODI presupposes large-scale quantitative research, introducing it abruptly in an early-stage product carries a heavy load, and the reality is that many teams start by organizing qualitative job statements first.

Where JTBD works, and where it doesn't

JTBD functions strongly when you want to dig into the motivations behind existing usage and grasp the competitive structure with alternatives. Asking "what is our product competing with?" can surface as competitors not only direct rivals but also Excel, manual work, and even the option of "doing nothing." These are realizations that a feature-comparison table cannot reveal. On the other hand, in situations where you optimize the experience after someone has already decided to use the product — such as the fine usability of the UI or improvements to the operation flow — usability testing and behavioral-log analysis work more directly than JTBD. A job explains "why they hired it," but it does not explain "how they felt after hiring it." Bringing out JTBD as an all-purpose analytical framework is itself another form of misuse.

Read next

The concrete procedure for collecting the statements that become the basis of a job statement is explained in Designing and Conducting User Interviews. For how to connect an understanding of the job to positioning, see Positioning and Differentiation Strategy.