The Jobs To Be Done framework
Back to the frameworks catalog
Customers do not buy your product because of an age bracket, a gender, or a feature list. They hire it to make progress in a specific situation. That is the core of Jobs To Be Done.

A “job” is not a ticket on your board. It is the progress a person wants in a circumstance: faster, calmer, more credible, less risky. If you miss that progress, you will build the right feature for the wrong problem.
Why demographics and personas are not enough
A persona such as “Sara, 28, lives in a capital city” makes the team feel informed. It does not explain the purchase. Two people with the same demographics can have two different jobs. The same person can hire two different products in two different situations.
Clayton Christensen’s milkshake example still holds: in the morning, a driver hires the milkshake to stay full and occupied in traffic. In the afternoon, a parent hires the same product to say “yes” to a child without ruining dinner. One product, two jobs, two designs.
The useful question is not “who is our customer?” It is: in what situation, for what progress, do they hire this instead of the alternative?
Three dimensions of a job
A job is not only a functional task. Three layers usually decide the hire:
- Functional: the work must get done — food arrives, a file is sent, a payment is recorded.
- Emotional: how the person wants to feel — calm, in control, less embarrassed.
- Social: how they want to be seen — professional, current, responsible, or “like everyone else.”
A product that only sees the functional layer usually loses the comparison. A spreadsheet can also “do the work.” What switches the hire is often less anxiety or more status.
The job statement and the job story
Use the Intercom / Alan Klement shape:
When [situation], I want to [motivation], so I can [expected progress].
A good sentence does not name your product. “When I click Subscribe I want the modal to open” is not a job; it is a UI note. A good sentence is: “When several subscriptions leave my account at month-end and I cannot tell which is which, I want to settle each one before the next charge, so I am not surprised.”
Tony Ulwick writes a job as verb + object + context: “Finish breakfast in the car, on the morning commute, without stopping.” Both forms work when they pin down the situation.
The four forces of switching
Bob Moesta showed that people switch when four forces fall out of balance:
- Push of the current situation: pain, wasted time, embarrassment, hidden cost.
- Pull of the new alternative: a better life after the switch.
- Anxiety of the new alternative: “What if it fails? Do I lose my data? Is it hard to learn?”
- Habit of the present: inertia; “it works well enough for now.”
A new product is hired only when push + pull is larger than anxiety + habit. Many failed launches show value and still lose because they never reduce the anxiety of leaving.
How to use JTBD in real work
- Find switchers. People who just came to you, or just left you. They still remember the hiring moment.
- Buy the story, not the opinion. Do not ask “what feature do you want?” Ask when they last moved from the previous solution, what happened, and what they tried first.
- Build a timeline. First thought, search, advice from others, the purchase. The job usually appears on that timeline, not in an abstract slogan.
- Put the forces on a board. For each switch, write push, pull, anxiety, and habit.
- Bring the solution later. Job and forces first. Then ask which opportunity is worth a test. That is where assessing product opportunities and an Opportunity Solution Tree help.
Common mistakes
- Writing the job around your brand or feature.
- Treating a UI task as the job (“they click,” “they filter”).
- Building ten personas instead of three repeating situations.
- Asking “would you use this feature?” instead of hearing the switch story.
- Confusing JTBD with market segmentation. JTBD is why they hire, not a demographic label.
Tool: job-statement builder
Fill the three fields. The tool writes the sentence, warns you if it sounds like a feature, and copies it for the next meeting.