Jobs to be Done is a framework for understanding why customers buy, developed through the 2000s by Clayton Christensen, Bob Moesta and colleagues. It holds that people do not buy products so much as hire them to make progress on a job in their life, and that the job, not the customer profile, is the stable unit of analysis. Two distinct schools have grown from it, one focused on progress and one on measurable outcomes.
When you're about to add a feature and aren't sure if anyone wants it. When your buyer's stated needs don't match their behavior. When you're competing on features and losing to a product that has fewer features but wins anyway.
What Jobs to be Done is
Jobs to be Done is a framework for understanding why customers buy. It was developed through the 2000s by Clayton Christensen, Bob Moesta and colleagues at Harvard Business School, growing out of Christensen’s earlier work on disruptive innovation.
Its central claim is that people do not buy products so much as hire them to make progress on a job in their life, and that they fire them when something else does the job better. The job, not the customer’s demographic profile, is the stable unit of analysis. Two people with nothing in common can hire the same product for the same job, and one person can hire completely different products for the same job at different moments.
The practical consequence is that your competition is not the category you think you are in. It is whatever the customer would otherwise have done, including nothing.
One thing to know before reading further: two distinct schools share this name, with different units of analysis, different research methods and different outputs. Most confusion about JTBD comes from reading one and then the other without being told they differ.
- The job is the unit, not the customer The core move
People hire products to make progress. Two buyers with nothing in common can share a job; one buyer can hire different products for the same job.
- Four forces decide whether they switch Two push, two hold
Push of the situation and pull of the new solution against anxiety about switching and habit of the present.
- The switch has a timeline Mostly invisible
First thought, passive looking, active looking, deciding, consuming. Four of the five happen before you can see anything.
- Two schools disagree on what next Progress vs outcomes
Christensen and Moesta produce a narrative job statement. Ulwick produces a ranked list of quantified unmet outcomes.
Why it matters
A feature list answers the question “what does our product do”. It cannot answer “why would anyone switch to it”, and those are different questions with different answers.
The milkshake study is the standard illustration. A fast-food chain trying to sell more milkshakes studied milkshake buyers and improved the milkshake along every dimension those buyers said mattered. Sales did not move. Studying the job instead revealed that a large share of milkshakes were bought before 9am by commuters who needed something to occupy a long, boring drive, that would not leave crumbs, and that lasted the whole journey. The competition was not other milkshakes. It was bananas, bagels and boredom.
Nothing about the buyer’s demographics predicted that. The job did.
There is a small irony in how popular this has become. When ShipFit’s engine is turned loose on a real idea and allowed to pick whichever strategic framework fits, it reaches for Jobs-to-be-Done more than any other, on roughly four ideas in ten. Which is either a vindication of the theory or evidence that JTBD is the framework you reach for when you are not sure what else to reach for. Both readings are available.
Given nineteen strategic frameworks to choose from, the engine picks three of them nine times out of ten.
- Jobs-to-be-Done
- 94 ideas 39.2%
- Blue Ocean Strategy
- 82 ideas 34.2%
- 7 Powers
- 41 ideas 17.1%
- Product-Led Growth
- 18 ideas 7.5%
- Playing to Win
- 3 ideas 1.3%
- Sales-Led Growth
- 1 idea 0.4%
Sample: n = 240 ideas that reached the strategy stage
What it does not say: This is what ShipFit’s engine selected, not what worked. It observes no outcomes, and the sample is people who chose to run an AI validation tool.
This one is unflattering to us, and we are publishing it anyway. A tool that only reports the numbers making it look good is not reporting numbers.
When to run it
- Your product does what you promised and people still are not switching to it.
- You cannot describe who the product is for without listing job titles.
- You are writing positioning or messaging and every draft describes features.
- Churn is high and exit interviews return vague answers.
- You are about to expand into a new segment and want to know whether the job travels.
- You are not yet sure the problem is real at all. Use The Mom Test →
- You need to know what to charge. Use Van Westendorp →
- You are sequencing features for the next release. Use MoSCoW →
- You need to know what stops a rival copying you. Use 7 Powers →
The four forces
A switch is not caused by the new product being good. It is caused by four forces resolving in its favour, and two of them are working against you the whole time.
Has to win
- Push of the situation
The problem with how things work today. Frustration, a deadline, a change of role, something that broke.
Ask: “What happened that made today different from last month?”
- Pull of the new solution
The appeal of the alternative. What they imagine life looks like once they have it.
Ask: “What did you picture it would let you do?”
Usually underestimated
- Anxiety about the new solution
Fear of the switch itself. Migration, learning curve, looking foolish if it fails.
Ask: “What nearly stopped you signing up?”
- Habit of the present
Attachment to the current way. It is known, it is configured, and it is nobody's problem today.
Ask: “What did you like about the old way?”
Most product work adds pull and ignores the right-hand column. Reducing anxiety and breaking habit is usually cheaper than building another feature, and it moves the same balance. Migration tooling, a free trial with their real data and a visible undo button are all anxiety work, not pull work.
The timeline of a switch
The forces explain whether. This explains when, and the answer is usually “much earlier than you think”.
- First thought
A passing awareness that the current way is not ideal. Nothing changes yet.
Moves on when: Nothing. It sits.
- Passive looking
Half-noticing alternatives. Reading, hearing about tools, not evaluating.
Moves on when: Curiosity, no urgency.
- Active looking
Deliberately searching, comparing, asking peers. The push has become concrete.
Moves on when: A specific event made it urgent.
- Deciding
Narrowing to one or two, negotiating internally, managing anxiety.
Moves on when: Enough evidence to justify the risk.
- Consuming
First use. This is where anxiety either resolves or turns into churn.
Moves on when: The switch actually happens.
The practical implication is uncomfortable. If you only talk to people who bought, you are sampling the end of this line, and the interesting decisions happened at the start of it. Switch interviews are designed to reconstruct the whole timeline, working backwards from the purchase to the first thought.
The two schools
- Associated with
- Clayton Christensen, Bob Moesta
- Unit of analysis
- The progress a person is trying to make in their life
- Research method
- Switch interviews. Ten to twelve one-hour conversations in which recent buyers narrate the chronological story of their decision.
- What you get out
- A narrative job statement and a map of the four forces
- Reach for it when
- Discovery, when you do not yet know what job you are being hired for
- Associated with
- Tony Ulwick, Strategyn
- Unit of analysis
- The activity a customer is trying to execute, broken into desired outcomes
- Research method
- A needs-based survey rating each outcome on importance and satisfaction, followed by cluster analysis.
- What you get out
- A quantified opportunity score per outcome, ranking what to build next
- Reach for it when
- Innovation, when you know the job and need to rank which outcomes to target
They are not rivals and you do not have to pick a side. The progress school answers “what am I being hired for?” and the outcome school answers “now that I know, what do I build first?” Running them in that order is the normal case; running the second without the first produces a very precise ranking of the wrong outcomes.
Ranking what to build: the opportunity score
The outcome school’s contribution is a way of turning “what should we build next” into arithmetic. Customers rate each desired outcome on importance and on how well existing solutions already deliver it. The gap is the opportunity.
Opportunity = Importance + max(Importance − Satisfaction, 0) Both rated 1–10 by customers. Importance counts twice; satisfaction only subtracts, and never below zero.
| Desired outcome | Importance vs satisfaction | Score | Read |
|---|---|---|---|
| Know which feedback matters most | 15 | Under-served Important and badly handled. This is where the opportunity is. | |
| Turn feedback into something engineering can act on | 14.8 | Worth attention A real gap, but not the biggest one on the list. | |
| Show customers their input changed something | 10.7 | Appropriately served Existing solutions are broadly adequate. | |
| Collect feedback in one place | 8.6 | Over-served Already satisfied beyond what it is worth. Do not invest here. | |
| Share a public roadmap | 5.6 | Over-served Already satisfied beyond what it is worth. Do not invest here. |
- Importance
- Satisfaction with what exists
Note the bottom two rows. “Collect feedback in one place” is nearly as important as the top outcome and scores far lower, because existing tools already do it well. Importance alone would have put it near the top of the roadmap.
Writing a job statement
The progress school’s output is a sentence, and the format matters because a loose one smuggles the solution back in.
- When
- [situation] I am driving to work with a long boring commute ahead
- I want to
- [motivation] occupy myself with something that lasts the whole journey and does not make a mess
- So I can
- [expected outcome] arrive alert and not hungry, without crumbs on the seat
- Contains no solution
Fails: "When I need to schedule a meeting, I want a calendar tool."
The tool is your answer, not their job. A statement with your category in it can only ever confirm your category.
- Would still be true in 1990
Fails: "When I am reviewing a pull request…"
Jobs are stable; the technologies hired to do them are not. If the statement collapses without a modern product category, it is a feature description.
- A competitor outside your category could satisfy it
Fails: "When I want to use our dashboard…"
If nothing outside your industry could possibly compete, the statement is drawn too narrowly to teach you anything about who you are really up against.
Jobs-to-be-Done in practice: the milkshake study
This is the case that made the theory famous, and it deserves the space because the useful part is usually left out of the retelling.
A fast-food chain, via Bob Moesta and Clayton Christensen · Late 1990s, published 2005 onwards
Half of all milkshakes were sold before 8am, to people who drank them alone in a car.
A chain wanted to sell more milkshakes and had done the obvious research: segment the milkshake buyer, ask them what they wanted, improve the product along those dimensions. Thicker, chunkier, cheaper. Nothing moved.
The researchers instead stood in the restaurant and recorded when shakes were bought and what happened next. A large share went out before eight in the morning, bought alone, taken to a car, and consumed over a long commute. The competition was not other milkshakes. It was bagels, which need two hands, and bananas, which are gone in a minute.
The shake was being hired to make a boring drive less boring and to stave off hunger until eleven. Thick was a feature, not a defect, because it took twenty minutes through a straw.
- Share of shakes sold before 8am
- about half
- Useful demographic predictors found
- none
What it shows: The buyer profile predicted nothing. The circumstance predicted everything. That is the whole claim of Jobs-to-be-Done, and this case is the reason it spread.
Jobs to be Done vs the alternatives
What progress is the buyer hiring something to make?
Gives you: A job statement, a forces map, and a real competitive set
Who is the buyer, and what do they care about?
Gives you: A profile. Complementary, but demographics do not predict jobs
What should this specific piece of software do?
Gives you: Implementation scope. Downstream of the job, and often mistaken for it
What steps does someone go through with our product?
Gives you: Friction points inside a journey JTBD would first ask them to justify
When it won’t help you
- Interpretation is doing most of the work
A job statement is written by you, from stories told by other people, and two competent researchers routinely produce different statements from the same transcripts. There is no procedure that makes the answer fall out.
Instead: Write the statement, then test it as a prediction. If the job is right, it should tell you something about buyer behaviour you did not already know and can go and check.
- Almost every example is retrospective
The milkshake, the mattress, the school. All reconstructed after the fact, all from products that worked. Reading backwards from a success makes the job look obvious in a way it never is beforehand.
Instead: Use the cases to learn the shape of the reasoning, not as evidence that the method predicts winners.
- The two schools are frequently conflated
Teams adopt the vocabulary of the progress school and the survey instruments of the outcome school, and get a quantified ranking of outcomes nobody validated as mattering.
Instead: Pick which question you are answering. Discovery first, ranking second, and never the second without the first.
- It says nothing about whether the job is worth serving
A real, well-understood, correctly-stated job can still belong to a market too small to sustain a business, or to buyers with no budget.
Instead: Size it and price it separately. The job tells you what to build, not whether the building is worth doing.
ShipFit and Jobs to be Done
ShipFit uses JTBD at Stage 3 (What Hurts?) to reframe the problem statement as a hire statement rather than a feature list. That statement then anchors every downstream decision: who pays at Stage 2, what wins at Stage 4, what ships in V1 at Stage 5. Jobs framed as features produce different, and usually bigger, first releases than the same problem framed as a job, which is why the reframing happens before scoping rather than after.
Where this sits in the sequence
JTBD comes after you know the problem is real and before you decide what to charge for solving it.
- The Mom Test
Confirm the problem is real and find out what it already costs.
- Jobs to be Done
Work out what the buyer is hiring a solution to do.
You are here
- Buyer Persona
Turn the interviews into something the whole team can act on.
- Van Westendorp
Find out what that buyer will actually pay.
Further reading
- Clayton Christensen, Taddy Hall, Karen Dillon & David Duncan, Competing Against Luck (2016). The progress school in book form.
- Tony Ulwick, Jobs to be Done: Theory to Practice (2016). The outcome school, and the source of the opportunity algorithm.
- Bob Moesta, Demand-Side Sales 101 (2020). The most practical treatment of switch interviews.
- The Mom Test. How to run the conversations without leading the witness.
- Buyer Persona Canvas. Where the job statement becomes something a whole team can use.
- Van Westendorp. What to run once you know the job and need a price.
- 7 Powers. Orthogonal, and necessary: knowing the job does not stop anyone else serving it.
How to apply Jobs to be Done (JTBD)
- 1
Interview people who recently switched, not people who might
Find ten to twelve buyers who changed solutions in the last ninety days, while the decision is still recoverable in memory. Recent switchers can narrate what actually happened; prospects can only speculate, and speculation about your own future behaviour is close to worthless.
- 2
Reconstruct the timeline backwards from the purchase
Start at the moment of purchase and work back: when did you start actively looking, what made it urgent, when did you first notice the old way was not working? Four of the five stages happen before anything you can instrument, so this is the only way to see them.
- 3
Map the four forces for each story
Push of the situation and pull of the new solution, against anxiety about switching and habit of the present. Note which force was strongest and which nearly stopped the switch. The forces you have never addressed are usually on the right-hand side.
- 4
Write the job statement, and strip the solution out of it
When [situation], I want to [motivation], so I can [expected outcome]. Then test it: it must contain no solution, it must still make sense in 1990, and a competitor from outside your category must be able to satisfy it. Most first drafts fail all three.
- 5
Identify the real competitive set
Whatever they would otherwise have done, including nothing. For most products the biggest competitor is a spreadsheet, an email thread or continued tolerance of the problem. Positioning against the wrong competitive set is the most common consequence of skipping this.
- 6
If you need a build order, switch schools deliberately
The progress school tells you what job you serve. To rank which unmet outcomes to target, run the outcome school's survey and compute opportunity scores. Do them in that order; the reverse produces a precise ranking of outcomes nobody confirmed mattered.
Common mistakes
- **Writing jobs as benefits or outcomes.** 'save time' is not a job, it's a benefit. 'Get the monthly board report done by Friday without last-minute scrambling' is a job.
- **Confusing jobs with personas.** A persona is 'who.' A job is 'what they're hiring your product to do.' Same person has different jobs in different moments (buying coffee at 7am vs. at 3pm).
- **Asking 'what do you want?'.** Customers describe features (faster horse). Ask about past switches and the forces of progress instead.
- **Over-scoping the job.** 'run my business' is not a job, it's a life. Scope to something where progress is measurable in a session.
- **Skipping the switch interviews.** JTBD without talking to 10 recent switchers is a word game, not a framework.
- **Treating JTBD as a replacement for Mom Test customer interviews.** They're the same muscle. JTBD just sharpens the questions.
How ShipFit operationalizes this
ShipFit runs Jobs-to-be-Done across Stage 2 (Who Pays?) and Stage 4 (How to Win?). At Stage 2 it establishes the functional, social and emotional jobs behind the buyer's behaviour. At Stage 3 it reframes the problem statement as a hire statement rather than a feature list, and at Stage 4 it drives innovation targeting. That statement then anchors every downstream decision, because jobs framed as features produce different, and usually bigger, first releases.
ShipFit runs 55 frameworks across 9 decision stages
Jobs to be Done (JTBD) is one tool in a bigger toolkit. The full library covers market sizing, buyer discovery, MVP scoping, pricing, and launch.
The Mom Test
Q3Rob Fitzpatrick
Validation question methodology, real interviews, not theater
Jobs-to-be-Done
Q2-Q4Clayton Christensen
Functional, social, and emotional jobs your product fulfills
7 Powers
Q4Hamilton Helmer
Strategic moats: Scale, Network, Counter-positioning, Switching, Brand, Cornered Resource, Process
Van Westendorp PSM
Q6Feature-weighted price sensitivity analysis without guessing
Blue Ocean Strategy
Q4Kim & Mauborgne
ERRC framework: Eliminate, Reduce, Raise, Create
Fake Door Testing
Q7Pre-build behavioral validation with landing pages and apology modals
+ 49 more: TAM/SAM/SOM Analysis, Porter's Five Forces, Market Timing Analysis, Unit Economics (LTV/CAC)...
Frequently asked questions
What's the difference between a job, a persona, and a use case?
Clayton Christensen's milkshake example. What's the one-line summary?
How is JTBD different from user stories?
Can JTBD apply to B2B SaaS?
How many switch interviews is enough?
Is JTBD just a rebranded Theory of Use or Design Thinking?
What are the four forces of Jobs to be Done?
What is the difference between the Christensen and Ulwick versions of JTBD?
What is the opportunity score in JTBD?
What is a switch interview?
How do I write a good job statement?
Keep exploring
The 9-step playbook from market verdict to ship-ready spec.
ICE scoring ranks ideas by Impact times Confidence times Ease. How to score it honestly, where the arithmetic misleads, and how it really differs from RICE.
MoSCoW sorts features into Must, Should, Could and Won't against a fixed date. The 60% capacity rule is the part most teams drop, and dropping it breaks it.
Most founder market research is a TAM slide that nobody believes. The numbers that actually matter are smaller, harder to defend, and tell you whether the market exists for the ten-customer version of your business.
Most founders confuse idea validation with idea-receiving-encouragement. The two have nothing in common. Here's what real validation looks like, and the four methods that actually produce it.
How many months until the bank account hits zero?
Three nested market-sizing numbers. TAM (Total Addressable Market) is the entire global demand for the category. SAM (Serviceable Addressable Market) is the slice you could serve given your channels and geography. SOM (Serviceable Obtainable Market) is what you could realistically capture in 1-3 years. Most founders inflate TAM and skip SOM. The honest move is the opposite: start at SOM, work up. The ten-customer version of your business is more useful than the $10B TAM slide nobody believes.
For indie hackers who've wasted months on dead ideas. ShipFit forces 9 decisions before you write a line of code. Proven frameworks, exports to Cursor.
AI Cofounder runs 26 parallel AI agents to produce investor-ready pitch decks and business reports. ShipFit runs 9 sequential decisions with live G2 / Reddit data, Van Westendorp pricing and a 24% Kill rate. Parallel agents skip decisions. Sequence forces them.
Ready to make your next product a success?
9 decisions between your idea and a product worth building.