Jobs-to-be-Done (JTBD) is a framework for understanding why customers "hire" a product — not by demographics or persona labels, but by the underlying progress they're trying to make in a specific circumstance. It reframes competition around outcomes instead of categories, and gives product managers a repeatable way to size opportunities, score unmet needs, and predict who will actually switch.
Quick answer: Jobs-to-be-Done holds that customers don't buy products, they hire them to make progress in a given situation. Write a
job statementto define the job, use Ulwick'sOpportunity Scoreto rank unmet outcomes, and read the fourForces of Progress— push, pull, anxiety, habit — to judge whether someone will actually switch.
What Is Jobs-to-be-Done, Really?
Jobs-to-be-Done treats every purchase as a hire: a customer brings a product into their life to get a specific job done, then fires it the moment something else does that job better. The job itself is stable — people have needed to get news, feel prepared, or look competent for centuries — even as the products hired for it keep changing.
The clearest way to see this is Clayton Christensen's well-known milkshake study, conducted with researcher Bob Moesta for a fast-food chain trying to sell more milkshakes. Demographic and taste-preference research went nowhere. Watching purchase occasions revealed the real pattern: many milkshakes were bought alone, in the morning, by commuters. The "job" wasn't dessert — it was a long, one-handed, not-too-messy companion for a boring drive. Once the chain understood the job, it thickened the shake and moved the dispenser to the front counter, and sales climbed.
As marketing scholar Theodore Levitt put it in his classic teaching example: "People don't want a quarter-inch drill. They want a quarter-inch hole."
The Job vs. the Product
This distinction matters because products come and go, but jobs persist across generations of technology:
- The job: "help me stay informed during my commute" has been served by newspapers, radio, podcasts, and now short-form audio apps.
- The product: whichever of those currently does the job best, cheapest, or most conveniently for a given person.
- The competition: not just other apps in your category, but anything — including "do nothing" — that could get the job done instead.
Three Dimensions of a Job
Every job has layers beyond the obvious task, and missing any one of them is a common reason otherwise-functional products fail to get adopted:
- Functional dimension — the practical task itself (get from A to B, track an expense, ship a feature).
- Emotional dimension — how the customer wants to feel while doing it (in control, unhurried, unembarrassed).
- Social dimension — how they want to be perceived by others while doing it (competent, generous, decisive).
A roadmap that only optimizes the functional dimension routinely loses to a competitor that also nails the emotional and social ones — this is why "feature parity" so often fails to win a market.
Two Schools of Thought: Christensen vs. Ulwick
Jobs-to-be-Done isn't one method; it's two related but distinct traditions that PMs frequently conflate. Clayton Christensen's version is a narrative, causal theory of why customers switch, built on qualitative "switch interviews." Tony Ulwick's Outcome-Driven Innovation (ODI) is a quantitative system for scoring which unmet customer outcomes represent the biggest opportunity. Both are legitimate; they answer different questions.
| Dimension | Christensen's JTBD | Ulwick's Outcome-Driven Innovation (ODI) |
|---|---|---|
| Origin | Harvard Business School, developed through case research including the milkshake study | Strategyn, formalized in Ulwick's 2005 book What Customers Want |
| Core unit of analysis | The "job" as a causal story of struggle and switch | The "desired outcome statement" — a measurable metric of success |
| Primary artifact | Job statement + switch narrative (push, pull, anxiety, habit) | Ranked list of outcome statements with Opportunity Score |
| Data collection | In-depth "switch interviews" tracing the full purchase timeline | Structured surveys rating importance and satisfaction per outcome |
| How it prioritizes | Qualitative judgment on which forces are strongest | Quantitative formula: importance vs. satisfaction gap |
| Best used for | Understanding why people switch and what messaging will land | Ranking which unmet needs justify the next roadmap bet |
| Canonical source | Competing Against Luck (Christensen, Hall, Dillon, Duncan, 2016) | What Customers Want (Ulwick, 2005); Strategyn's ODI process |
Most mature JTBD practices use both: Christensen's lens to understand the switch story and write a sharp job statement, then Ulwick's math to decide which piece of that job to build first.
Writing a Job Statement That Survives Contact With Reality
A job statement is a single, testable sentence that names the situation, the motivation, and the expected progress — written so specifically that two different engineers would build the same thing from it. Vague statements like "users want a better dashboard" aren't job statements; they're wishes, and they collapse the moment a team tries to scope them.
The most durable format follows Christensen's structure directly:
"When [situation], I want to [motivation], so I can [expected outcome]."
For a fuller breakdown of this format with worked examples across B2B and B2C contexts, see the dedicated guide on how to write a JTBD job statement. It matters because a job statement that's well-formed in a workshop can still fall apart the moment it reaches an engineering ticket — a failure mode covered in depth in how job statements survive the handoff to engineering.
Ulwick's tradition uses a stricter, metric-first variant called a desired outcome statement:
"Minimize/Increase [metric] of [the thing being controlled] when [context]."
For example: "Minimize the time it takes to confirm a payment has cleared when processing a high-value transfer." Notice this contains no solution — no mention of notifications, dashboards, or webhooks. That's deliberate; the outcome statement is what gets scored, and scoring a solution instead of an outcome is the single most common mistake teams make when adopting ODI.
A practical sequence for writing job statements that hold up under scrutiny:
- Interview around a recent switch, not a hypothetical preference — ask what the customer used before, and what finally tipped them.
- Separate the job (stable) from the solution (variable) in every sentence you write down.
- Draft the statement in the situation/motivation/outcome format, then strip any product nouns that crept in.
- Validate it against at least three real customers before treating it as a roadmap input.
- Break large jobs into the discrete outcome statements a team could actually score and rank.
Scoring Opportunities the Ulwick Way
The Opportunity Score is Ulwick's formula for turning subjective customer ratings into a rankable number, so a roadmap decision doesn't rest on whoever argued loudest in the room. It compares how important an outcome is to how satisfied customers currently are with it, and the bigger that gap, the bigger the opportunity.
The formula, on a standard 1–10 rating scale:
Opportunity Score = Importance + max(Importance − Satisfaction, 0)
In plain terms: take the importance score, then add the gap between importance and satisfaction (but never a negative gap — an outcome that's already over-satisfied doesn't get penalized further in the base formula, it's simply flagged as overserved).
| Desired outcome statement | Importance (1–10) | Satisfaction (1–10) | Opportunity Score | Read |
|---|---|---|---|---|
| Minimize time to confirm a cleared payment | 9 | 4 | 14 | Underserved — strong opportunity |
| Minimize errors when reconciling monthly invoices | 8 | 7 | 9 | Appropriately served |
| Increase confidence that a report reflects live data | 9 | 3 | 15 | Underserved — top opportunity |
| Minimize steps to export data for a board deck | 5 | 8 | 5 | Overserved — candidate to de-invest |
Ulwick's own benchmark, drawn from years of ODI studies at Strategyn, treats scores above roughly 10 as a genuine unmet need and scores above roughly 15 as the strongest bets in the set — directionally useful thresholds rather than hard laws, since the right cutoff shifts with your sample and rating scale.
Why This Beats a Feature Vote
A raw feature-request tally rewards whoever's loudest or most recently in a sales call. The Opportunity Score instead forces two separate judgments — importance and satisfaction — which surfaces outcomes that are quietly painful but rarely mentioned, because customers have simply stopped asking for what they've decided you'll never build. That gap between silence and importance is exactly what the score is designed to expose.
The Four Forces of Progress
The Forces of Progress model explains why a customer with a real, scored job still might not switch: every decision to adopt something new is a tug-of-war between two forces pulling toward change and two forces holding the status quo in place. The model was developed by researchers Bob Moesta and Chris Spiek at the Re-Wired Group and later popularized in Christensen's Competing Against Luck.
| Force | Direction | What it is | Question a PM should ask |
|---|---|---|---|
| Push of the situation | Toward change | Growing dissatisfaction with the current way of doing the job | "What broke, or kept breaking, that made the old way untenable?" |
| Pull of the new solution | Toward change | The attraction of a better imagined future state | "What did they picture their life looking like after switching?" |
| Anxiety of the new solution | Away from change | Fear of the unknown, risk, or looking foolish with something new | "What almost stopped them from committing at the last minute?" |
| Habit of the present | Away from change | Comfort and familiarity with the existing workaround, however clunky | "What did they have to unlearn, and what made that hard?" |
A roadmap bet with a high Opportunity Score can still stall in the market if anxiety and habit outweigh push and pull — which is why Christensen argues that most switching decisions are lost not to a named competitor, but to the customer's own inertia. Reading the four forces alongside the score is what separates a feature that's merely wanted from one that's likely to actually get adopted.
From Job Statement to Roadmap Bet: The Full Arc
A job only earns its place on a roadmap once it has traveled a specific arc: named as a job statement, broken into scorable outcome statements, ranked by Opportunity Score, checked against the four Forces of Progress, and only then translated into a spec. Skipping any step is how teams end up building well-researched features nobody adopts.
The full arc, in practice:
- Discover the job through switch interviews, not surveys about hypothetical preferences.
- Write the job statement in situation/motivation/outcome form, and the underlying desired outcome statements in metric form.
- Score each outcome with importance and satisfaction ratings to compute the
Opportunity Score, ranking underserved outcomes highest. - Read the Forces of Progress for the top-ranked outcomes to sanity-check whether push and pull genuinely outweigh anxiety and habit for this segment.
- Place the job in its journey — a job rarely happens in isolation; mapping it against the surrounding emotional highs and lows is covered in the complete guide to customer journey mapping.
- Trace second-order effects — a job well served in one part of a system often creates pressure elsewhere, which is where systems thinking becomes the right lens for a roadmap bet with ripple effects.
- Model what the job requires structurally — once an outcome statement is chosen, it usually implies new entities and relationships, which is exactly what the guide to data modeling walks through.
- Expose the job outcome externally, if relevant — for platform or B2B products, a served job often needs to be reachable by other systems, which is the starting point of the guide to API product design.
Where Prodinja Fits
This arc is exactly what Prodinja's Customer Jobs tool is built to hold in one place. Instead of job statements living in a slide deck, an opportunity-score spreadsheet living separately, and a Forces-of-Progress sketch living in someone's notebook, the tool lets you capture a job statement, add its outcome statements, and get the Opportunity Score computed automatically from your importance and satisfaction inputs — deterministically, the same formula every time, autosaved as you work. It also walks you through a Forces-of-Progress read for the job, so the push/pull/anxiety/habit judgment sits next to the score rather than in a separate document. Because it's part of the same prototype workspace as Customer Journey, Systems Engineering, and Data Modelling, a job captured here can carry forward into the rest of the arc above instead of getting re-typed at every stage.
Key Takeaways
- Jobs are stable, products aren't — define the job first, and treat every current solution (including "doing nothing") as competition for that job.
- Christensen and Ulwick answer different questions: use switch interviews to understand why people change, and
Opportunity Scoreto decide which outcome to build first. - A well-formed job statement names a situation, a motivation, and an expected outcome — with no product noun anywhere in the sentence.
- The Opportunity Score formula (
Importance + max(Importance − Satisfaction, 0)) turns subjective ratings into a rankable, arguable number. - The four Forces of Progress — push, pull, anxiety, habit — explain why a highly-scored opportunity can still fail to convert switchers.
- A job isn't done in isolation: it sits inside a journey, a system, a data model, and often an API surface, and skipping those steps is how good research produces an unadopted feature.
Frequently Asked Questions
What's the difference between a job statement and a user story?
A job statement describes a stable customer motivation independent of any solution ("when I'm commuting alone, I want a filling breakfast I can eat one-handed"). A user story describes a specific piece of software to build ("as a user, I want a checkout button"). Job statements should exist before user stories and justify why a given story is worth writing at all.
Is Jobs-to-be-Done the same as persona-based segmentation?
No — JTBD deliberately segments by situation and motivation, not by demographic or firmographic traits. Two people with identical job titles can be hiring completely different jobs, while two people with nothing else in common can be hiring the exact same one, which is why Christensen argued personas often mislead product teams into building for the wrong axis entirely.
How do I calculate an Ulwick opportunity score?
Rate each desired outcome statement on importance and satisfaction, both on a 1–10 scale from real customers, then apply Opportunity Score = Importance + max(Importance − Satisfaction, 0). Scores roughly above 10 signal an unmet need worth investigating; scores above 15 are typically Strategyn's strongest ODI opportunities.
What are the four Forces of Progress in JTBD?
They are push of the current situation, pull of the new solution, anxiety about the new solution, and habit of the present way of doing things — two forces driving switching and two forces resisting it, developed by Bob Moesta and Chris Spiek and detailed in Competing Against Luck.
Do I need both Christensen's and Ulwick's approaches, or just one?
Most mature JTBD practices use both, because they're complementary rather than competing: Christensen's switch-interview tradition is best for understanding why customers hire and fire a solution, while Ulwick's ODI scoring is best for deciding which unmet outcome deserves the next sprint.