Customers don't buy products — they hire them to make a specific kind of progress. Find the job, and you find what your product is really for.
Jobs-to-be-Done (JTBD), developed by Clayton Christensen, overturns how most teams think about user motivation: people don't buy products because of features or demographics — they hire a product to do a job in their life, and fire it when a better candidate comes along.
A "job" is not a task. It's the combination of a situation someone is in, the progress they're trying to make, and the outcome that would tell them they succeeded. Every job has three dimensions — functional (what they're trying to accomplish), emotional (how they want to feel), and social (how they want to be perceived). The product that best serves all three wins, regardless of features, price, or brand.
When I am [situation / context that triggers the need],
I want to [the progress I am trying to make],
so I can [the outcome that tells me the job is done].
Each completed statement represents one job. Most products serve one to three core jobs per segment. Mapping them reveals which jobs the product excels at, which it serves poorly, and which competitors it is actually up against.
Teams that skip the job and jump to features make five predictable, expensive mistakes. JTBD exists to surface what each one hides.
| The shortcut | What it costs | What JTBD reveals instead |
|---|---|---|
| Define users by demographics "Our users are managers aged 35–50." |
Demographics say nothing about what someone is trying to accomplish. Two people with identical profiles can have completely different jobs based on their situation. | The situation that triggers the need — not age, title, or industry. |
| Define needs by feature requests Customer asks for "better reporting." |
A feature request describes a proposed solution, not the underlying job. "Better reporting" might really mean "justify this budget to my board." | The progress the user is actually trying to make — usually one level deeper than what they say. |
| Build for the user, ignore the buyer | The product delights the end user but gives the person who renews or cancels nothing to justify the spend. Churn comes from the buyer, not the user. | The full job map — including buyers whose job is entirely separate from the end-user's. |
| Assume all users share one job | Features built for one segment actively burden another. Both end up underserved. | A distinct job statement per segment — no two segments share a job map. |
| Measure the wrong proxy "Engagement is up, so we're winning." |
High activity without job completion is a vanity metric. Users are busy but the product isn't making the progress they hired it for. Churn follows. | The outcome that signals the job is done — and a metric that measures it, not just activity. |
"What were you doing before you used this product — and why wasn't that good enough?"
This reveals the fired solution — the thing the user switched away from. Most teams assume their competitor is a similar app. JTBD shows the real competitor is usually simpler and more surprising: a spreadsheet, a conversation with a colleague, a notebook, or doing nothing at all. What was fired, and why, tells you exactly what the job demands that the old solution couldn't provide.
JTBD is a lens applied to real user conversations — it is not a desk exercise. Run it before roadmap decisions are made, one segment at a time.
Before any interview, write your current belief about what job the user is hiring the product for. Treat it as a hypothesis to falsify, not confirm. The rule: you may not open a mockup, reference a feature, or mention any product capability until you've written a complete job statement for the person you're designing for. Features are downstream of jobs, always.
Ask about the last time the need arose in their life, not about the product. Focus on the situation, the trigger, and the moment things got hard. Good prompts: "Walk me through the last time this came up — what was the context?" · "Think back to the week before you signed up. What was going on?" · "If this disappeared tomorrow, what would you go back to doing?" Not one of these mentions a feature.
Use the When I am… / I want to… / so I can… format. If a single statement covers more than one segment, it's too vague — segment first, then write jobs. Strip out all product language: the "when I am" should describe a life situation, the "so I can" a human outcome, never an app action or product metric.
For each segment, name the functional job (the task), the emotional job (how they want to feel), and the social job (how they want to be perceived). Products that serve only the functional job lose to competitors that also win the emotional and social one. If you map only the functional job, you miss two-thirds of the competitive surface.
For each segment: what did they use or do before, and why wasn't it good enough? The fired solution is your real competitor and it tells you what your product must outperform. If the "fired" thing is a competing app, dig deeper — the real competition is usually simpler and more surprising than another product in your category.
For every feature, ask: which job does this serve, and does it serve that job better than what the user fired? A feature that serves a high-frequency, high-stakes job earns its place. A feature you can't tie to any job belongs in the icebox.
A short, illustrative example — not a case study to memorise, just a sense of what the framework surfaces when it's run honestly.
A team building an HR analytics product was briefed to ship "a better dashboard" — more charts, finer filters, a CSV export. Before building, a PM ran a single situation-focused interview with a buyer and opened with the firing question: "When did this product last come up in a conversation with your CFO?"
The buyer described a budget review where the CFO asked whether the tool actually reduced staff attrition. She had engagement numbers, but no way to connect them to turnover — so she couldn't answer. The job wasn't "analyse employee data." The job was: "When I'm defending this line item in a budget review, I want one credible number linking our spend to retention, so I can renew without pushback."
The fired solution wasn't a competing app — it was a manual spreadsheet she'd built herself, which the CFO didn't find convincing. That single insight replaced the roadmap: instead of more charts, the anchor feature became one defensible "retention impact" headline. The CSV export — the original brief's centrepiece — was cut, because it just recreated the spreadsheet she was trying to fire.
One card per segment. This is the deliverable JTBD produces — fill one in for each segment you serve.
When I am [the situation that triggers the need], I want to [the progress I'm trying to make], so I can [the outcome that tells me it worked].
| 🔧 Functional job | 💜 Emotional job | 👁 Social job |
|---|---|---|
| The concrete task they need to accomplish | How they want to feel while doing it | How they want to be seen by others |
Who they fired: the prior solution they abandoned · Why it failed: what the old solution couldn't provide
PM insight: the one feature this job most needs — and why everything else is secondary until it exists.
Once the cards exist, re-examine the backlog. Each surviving feature should name the exact job it serves; each cut should name the job it doesn't.
| Feature | Decision after JTBD | Job served (or why cut) |
|---|---|---|
| Anchor analytics feature | Replace granular charts with one headline outcome metric | Buyer — functional + emotional: defend the budget with a single credible number |
| Raw data export | Cut — replaced by in-product analysis | Buyer — removes the manual workaround they were firing |
| Satisfaction-survey integration | Deprioritise | Measures sentiment, not the buyer's core job — resources redirected |
| Contributor impact summary | Add to scope | Power user — social job: make their contribution visible and provable |
A product can be built flawlessly and still fail — if it serves a job nobody has. JTBD doesn't make features better; it tells you whether you're building for a real job at all.
The shift JTBD forces is from describing a category ("an engagement platform," "an analytics tool") to describing a job ("makes growth visible and defensible for everyone who touches it"). That's not a branding change — it's a product-strategy change. When the description maps to a job, the roadmap, the metrics, and the positioning all align behind the same outcome. When it describes a category, every team optimises a different proxy.
"When I'm using the app, I want to see my completion rate, so I can track progress." That's a product interaction, not a human motivation. Strip out all product language — the situation should describe life, the outcome should describe a human result.
"Our users want to learn and grow." Too broad to act on. If a single statement covers more than one segment, it serves none of them. Segment first, then write jobs.
The functional job is the easy two-thirds to miss the point on. Products that ignore the emotional and social job lose to competitors that win them. Always map all three.
If you don't know what the user abandoned and why, you can't know what your product must outperform. The fired solution is your real competitor.
Writing job statements after the roadmap is set, to justify it, is post-hoc rationalisation. JTBD must run before decisions, not after.
JTBD is a lens applied to interview data that already exists. Without disciplined discovery interviews, there's no raw material to analyse — the job map is only as good as the conversations behind it.
The VPC takes the pains and gains inside each job and maps them against your actual features to measure fit. Run them in order: JTBD defines the jobs, the VPC tests whether the product serves them.
Reach and Impact are far more accurate scored against a job than a feature assumption. A feature serving a high-stakes, high-frequency job outscores one serving a peripheral preference.
JTBD maps jobs at the user level; market tools (Porter's Five Forces, competitor types) extend it to ask who else competes to fulfil the same job — often a non-obvious substitute, not a category rival.
AI accelerates the messy middle of JTBD — turning raw interview language into candidate job statements you then judge.
The judgment that stays yours: AI pattern-matches on the words; it can't tell which job actually drives behaviour. That judgment comes from you and the evidence — treat its output as hypotheses to verify, not findings.
Pick a product you use at least once a week. Write its job statement — as a real user, not a PM. Be honest about the situation that triggers your use, the progress you're making, and the outcome that tells you the job is done.
Then answer: what were you using or doing before this product existed? Why wasn't it good enough? What would you go back to if it disappeared tomorrow?
Now look at the product's homepage. Does it describe the job you just wrote? If not, that gap is a positioning problem, a retention risk, and a product-strategy opportunity — all at once.
PM Mapped is the complete product-management course — 156 tools, 6 modules, 25 AI deep-dives. Join the waitlist to get in first.
Join the waitlist →Browse all 156 →