Jobs-to-be-Done (JTBD) Framework & Job Stories
Shift from describing who users are to understanding what they're trying to accomplish — and build products that win by solving the right job.
8 min read
The full lesson
Feature roadmaps have a graveyard problem: teams ship exactly what users asked for — and users still churn. Jobs-to-be-Done (JTBD) explains why. It reframes design from “who is the user?” to “what progress is the user trying to make?” That sounds like a small shift. It changes every research, design, and prioritization decision downstream. JTBD is what separates teams that build useful things from teams that build busy things.
What “Job” Actually Means
Clayton Christensen popularized the idea: people don’t buy products — they hire them to do a job. A milkshake isn’t competing with other milkshakes. It’s competing with a banana, a granola bar, and a podcast — all hired for the same commute job of “make the drive less boring and keep me full until lunch.”
A job is the underlying progress a person is trying to make in a specific situation. It has three dimensions:
- Functional — the practical outcome (file my taxes, book a flight, onboard a new hire)
- Emotional — how the person wants to feel (confident, in control, not embarrassed)
- Social — how they want to be perceived by others (competent, responsible, thoughtful)
All three dimensions are real constraints. A tax-filing product that is functionally accurate but makes users feel anxious or stupid will get fired.
The Two Main JTBD Schools
You’ll encounter two traditions. They are compatible, not competing.
| School | Primary figure | Core output | Best for |
|---|---|---|---|
| Forces / Demand-side | Clayton Christensen | Understand the switch: what caused someone to hire/fire a product | Market sizing, positioning, retention |
| Outcome-driven innovation (ODI) | Tony Ulwick | Map jobs and desired outcomes as measurable statements | Opportunity scoring, roadmap prioritization |
Most design teams land somewhere between the two. They use switch interviews (Christensen) to build empathy and uncover unmet jobs, then use outcome statements (Ulwick) to prioritize which jobs to serve.
Conducting a Switch Interview
The switch interview is JTBD’s primary research tool. It reconstructs the timeline of a decision — from the first thought that something needed to change, through the search, to the moment of “hire.” You’re looking for the forces that drove the switch.
The Four Forces model:
- Push — frustration with the current situation that pushes the person away
- Pull — attraction toward the new solution or outcome
- Anxiety — fear or uncertainty that slows the switch
- Habit — inertia of existing behavior that resists change
A good switch interview asks open-ended, timeline-based questions — not hypothetical opinion questions. “Walk me through the day you first realized you needed a different solution” surfaces real behavioral evidence. “What features would make this better?” surfaces rationalizations. That’s the say/do gap at work.
Do
Don't
Sample Size Expectations
A qualitative JTBD study needs enough interviews to reach saturation — typically 8–15 switch interviews per job segment. This is different from the 5-user usability rule, which applies to finding surface-level UI problems, not mapping deep motivational structures. If you move into quantitative opportunity scoring (Ulwick’s ODI), you need 40 or more respondents for statistically meaningful importance/satisfaction data at 95% confidence.
Writing Job Stories
User stories follow the format: “As a [persona] I want [feature] so that [benefit].” They have a known failure mode: they collapse into solution descriptions that encode persona assumptions and pre-decided features. “As a power user I want bulk delete so I can manage my inbox” tells the team almost nothing useful about the job.
Job Stories, introduced by Alan Klement, strip out the persona. They center the situation and motivation instead:
When [situation], I want to [motivation / job], so I can [expected outcome].
The situation is the environmental trigger. It replaces the persona because context drives behavior more reliably than demographic identity. The motivation is the job itself. The expected outcome captures the progress the person is trying to make.
Comparison:
| Format | Example | Problem |
|---|---|---|
| User story | As a busy professional I want to snooze emails so I can deal with them later | Assumes persona; solution (snooze) already encoded |
| Job story | When I’m in the middle of a task and an email arrives that needs action later, I want to set it aside without losing track of it, so I can stay focused now and follow through reliably | Describes context, motivation, outcome — leaves solution space open |
Anatomy of a Strong Job Story
A weak job story reads like a user story with the persona removed. A strong one passes three tests:
- Situation specificity — the “when” describes a real, triggerable moment, not a permanent state. “When I’m onboarding a new team member” is specific. “When I manage a team” is a permanent state, not a situation.
- Motivation neutrality — the “I want to” names the job, not a solution. “I want to delegate a task” names the job. “I want to use the assignment feature” names a solution.
- Outcome measurability — “so I can” describes observable progress. “So I can trust the task will happen without me monitoring it” is measurable. “So I can be more productive” is not.
Mapping Jobs to Opportunity Space
Once you have a set of validated job stories, the next step is finding which jobs are underserved. Ulwick’s opportunity score formula gives teams a clear prioritization signal:
Opportunity score = Importance + max(Importance - Satisfaction, 0)
Jobs with high importance and low satisfaction are the richest opportunities. Jobs with high importance and high satisfaction are table stakes — match them, but don’t over-invest. Low-importance jobs are traps: users might ask for them, but fixing them won’t move retention or willingness to pay.
This is where JTBD connects directly to outcome-driven roadmapping. Instead of prioritizing features by stakeholder seniority or gut feel, teams prioritize by underserved-job coverage.
JTBD vs. Personas: When to Use Each
JTBD and personas are not enemies. They answer different questions.
| Question | Use |
|---|---|
| Who are our users and what do they care about? | Persona |
| What are users trying to accomplish in this context? | Job story |
| Why did someone switch to/from our product? | JTBD switch interview |
| How do we segment opportunity space for the roadmap? | ODI outcome mapping |
| How do we build team empathy and a shared mental model? | Both |
The failure mode is using personas as a proxy for jobs. “Sarah the Marketing Manager needs…” encodes assumptions about a demographic category. Two people with identical personas may be hired for completely different jobs. A startup founder and a freelance writer both use Notion — but one hires it for team alignment, the other for personal knowledge management. Their jobs diverge so sharply that a single persona-driven feature will optimize for one and frustrate the other.
Connecting JTBD to Design Decisions
JTBD is a synthesis tool, not a wireframing tool. Its output feeds design decisions, not screen layouts. Here is how the connection works in practice:
Information architecture — Group features by job, not by product capability. Users don’t think “I need to use the notifications module.” They think “I need to know when something needs my attention.” Job-aligned navigation matches the user’s mental model.
Onboarding flows — Each new user arrives with a primary job. Onboarding that discovers the job early — through a brief contextual question, not a demographic form — converts faster and reduces early churn.
Empty states — Empty states are job moments: the user just started a job and the product hasn’t helped yet. Copy and calls-to-action in empty states should be written to the job, not the feature. “Start your first project” assumes the user knows what a project is. “What are you working toward?” is written to the job.
Success metrics — JTBD aligns teams on what outcome to measure. If the job is “feel confident I haven’t missed anything important before a meeting,” the metric is not page views or feature adoption. It is task success rate on a pre-meeting review flow and post-task confidence rating via a validated single-ease question (SEQ). This is the outcome-driven measurement approach: tie North Star metrics to job completion, not engagement vanity metrics.
Common Mistakes to Avoid
- Mistaking features for jobs. “I want to search” is not a job. “When I know a document exists but can’t recall where it is, I want to locate it immediately so I can keep my workflow moving” is a job. The test: can the job be accomplished without your product? If yes, it’s a real job.
- Writing jobs at the wrong altitude. “Live a fulfilling life” is too high. “Click the send button” is too low. Good jobs sit at a level where design decisions can serve them: specific enough to constrain solution space, broad enough to leave room for creative approaches.
- Ignoring the fire moment. Christensen’s framework asks not just why people hire a product, but why they fire it. Fire-moment interviews reveal the emotional and social jobs that weren’t served — often the most actionable design input.
- Treating JTBD as a one-time exercise. Jobs are stable, but the population of people trying to accomplish them shifts. Revisit your job map when entering new markets or when churn patterns change unexpectedly.