The Problem: Research That Describes Without Explaining
You run user interviews. You collect feature requests. You segment users by demographic ("millennials," "enterprise," "power users"). You have a lot of data about who your users are and what they say they want — and almost no insight into why they use your product at all or why some users churn while apparently similar ones don't.
This is the limitation of most conventional user research: it describes users' attributes and actions but doesn't explain the underlying motivation that drives both. Knowing that 35-45 year-old marketing managers use your tool on Tuesday mornings doesn't tell you why they chose your product over an alternative — or what would cause them to stop.
The Jobs-To-Be-Done (JTBD) framework for user research reframes the question: instead of asking "who is this user?", you ask "what job is this user hiring this product to do?" The job is the progress the user is trying to make in a specific circumstance. Understanding the job — and the forces that drive users toward or away from products that do the job — is what produces research that actually explains behavior.
Where the Jobs-To-Be-Done Framework Comes From
Jobs-To-Be-Done was developed primarily by Clayton Christensen, a Harvard Business School professor best known for The Innovator's Dilemma (1997). Christensen and his colleagues developed the JTBD concept over years of research and consulting, presenting it in Competing Against Luck: The Story of Innovation and Customer Choice (2016, with Karen Dillon, David Duncan, and Taddy Hall).
The famous example Christensen used to introduce the concept: McDonald's wanted to increase milkshake sales. Market research — demographic segmentation, taste preferences — had failed. Bob Moesta (a researcher working with Christensen) spent time observing and interviewing milkshake buyers. What they found: 40% of milkshake sales happened early in the morning, to lone commuters. These buyers weren't "milkshake people" — they were "need something to make the commute less boring and keep me full until lunch" people. The milkshake was hired to do a job; the demographic profile of the buyer was irrelevant to understanding why.
Two related but distinct schools of JTBD developed:
Christensen's "Big Hire" model: Focuses on the decision to purchase (or switch) — what circumstances and forces cause someone to "hire" a product for a job it had previously done some other way.
Bob Moesta and Chris Spiek's "Switch" model: Developed through the Re-Wired Group, focuses on the four forces model: push (what's wrong with the current situation), pull (attraction of the new solution), anxiety (concerns about switching), and habit (inertia against switching). Formalized in Moesta's Demand-Side Sales 101 (2020).
Alan Klement's JTBD narrative: Klement (When Coffee and Kale Compete, 2018) extended JTBD with a focus on how jobs relate to the user's desired life narrative — the story they want to tell about themselves.
The JTBD Framework for User Research, Step by Step
Step 1: Identify the "Switch Moment" to Research
JTBD research is most useful when focused on a specific behavioral transition:
- When a user first adopted your product (or a competitor's)
- When a user churned from your product
- When a user significantly upgraded their usage
The switch moment is where the most valuable causal information lives. Ask "why did you change?" and you uncover the job better than "why do you use this?" (which produces post-hoc rationalization).
Step 2: Recruit Participants Who Have Made the Switch
Interview people who recently made the switch you're investigating:
- Recent new signups (why did they just switch?)
- Recent churners (why did they just leave?)
- Users who recently upgraded or expanded their usage
"Recently" matters: the closer to the switch, the more accurate the memory and the less post-hoc rationalization.
Step 3: Conduct the JTBD Interview
The JTBD interview is a structured timeline interview, not a preference survey. The goal is to reconstruct the decision journey — the circumstances, triggers, and forces that led to the switch.
Interview structure (the "story of purchase" interview):
1. First thought:
"When did you first start thinking about solving this problem? Take me back to that day."
2. The triggering event:
"What was happening in your life that made you start looking?"
(You're looking for the push: what was so wrong with the existing situation that action was triggered)
3. The search:
"What did you do first? What were you looking at or considering?"
4. The decision:
"Walk me through the day you decided. What made you choose [this product]?"
(You're looking for the pull: what specifically attracted them to the solution)
5. Anxiety and trade-offs:
"What were you worried about before committing? Was there anything giving you pause?"
(You're looking for anxiety: what almost stopped them)
6. First use:
"Tell me about the first time you actually used it. Did it work the way you expected?"
7. Progress:
"How is life different now? What can you do now that you couldn't before?"
Step 4: Code the Interviews for Job Statements and Forces
After interviews, analyze the transcripts to identify:
The Job Statement: A job statement has a standard structure: [Verb] + [Object of the Verb] + [Contextual Clarifier]
- "Get through my commute feeling entertained (not just fed)"
- "Organize my research so I can find it when writing"
- "Prepare for a client presentation without missing key market context"
The Four Forces:
- Push (what was wrong with the current situation that created pressure to act?)
- Pull (what was attractive about the new solution?)
- Anxiety (what almost stopped the switch?)
- Habit (what made staying in the old situation feel safe or comfortable?)
The four forces produce a complete picture of the switch decision — not just "why did you buy?" but "what overcame the inertia of not changing?"
Step 5: Cluster Jobs and Forces into Patterns
After coding 10-15+ interviews, look for patterns:
- What jobs appear repeatedly across different users?
- What pushes keep coming up?
- What anxieties appear most often?
- What pulls were most decisive?
The patterns reveal: which jobs are being done (your actual use cases), which jobs are underserved (highest push, but pull is weak), and which anxieties are reducing conversion.
Step 6: Translate to Product and Marketing Decisions
JTBD research feeds directly into:
Product decisions:
- Build features that do the job better (address the push and improve the pull)
- Reduce friction that causes anxiety
- Address the specific outcome users are hiring for, not just the feature they say they want
Marketing decisions:
- Talk to users in the language of the job, not demographic identity
- Show the progress the product enables, not the features it has
- Reduce stated anxieties in onboarding and sales materials
A Worked Example
A product manager, Sam, runs JTBD research on why users sign up for a web clipping tool.
Switch interviews (8 recent signups):
Recurring push themes:
"I had hundreds of saved links I couldn't find when I needed them" (5/8)
"I'd read something and couldn't remember where I'd seen it" (6/8)
"My browser bookmarks folder was a black hole" (7/8)
Recurring pull themes:
"The collections looked organized immediately" (4/8)
"I could see the actual content, not just the link" (5/8)
"Someone on a Slack community recommended it" (3/8)
Recurring anxieties:
"I wasn't sure my clips would still be readable if the original site went down" (4/8)
"I worried about importing from my existing bookmarks" (3/8)
Job statement emerging:
"Find the web content I've saved when I need it for a specific project or piece of writing — not 3 months later when I can't remember where I saw it."
Product implications:
- Build better search and tagging (the core job is finding, not saving)
- Address the "site goes down" anxiety explicitly in onboarding (content preservation)
- Make bookmark import faster and more visible (reduces switching cost anxiety)
Where JTBD Shines
For understanding churn: JTBD interviews with churners reveal what competitors or alternatives are being hired to do the job better — the most valuable competitive intelligence.
For messaging and positioning: When you know the job, you can speak directly to the progress users want to make, not to product features. "Get through your research in a fraction of the time" speaks to the job; "save links in organized collections" speaks to the feature.
For prioritizing the product roadmap: Features that address the core job (and its push/pull/anxiety forces) deserve higher priority than features that users request but that don't relate to the primary job.
Where JTBD Breaks Down
For large-scale quantitative research: JTBD is fundamentally qualitative — it's built on small-n interview-based research. It surfaces why, not how many. For quantitative questions (what percentage of users experience this issue?), surveys and analytics are more appropriate.
For products with highly complex job landscapes: Consumer apps used by millions for wildly different jobs (social media, general-purpose tools) are difficult to analyze with JTBD because the job landscape is too broad and fragmented for meaningful clustering from small interview samples.
For early-stage discovery: If you have no users yet, there are no switches to research. JTBD works on existing behavior; for pre-product research, Jobs Theory still applies conceptually but requires different methods (observation of the problem space, not purchase interviews).
JTBD vs. Other User Research Methods
| Method | Focus | Question | Output |
|---|
| JTBD interviews | Causal decision journey | Why did you switch? | Job statements and forces |
| User persona research | Demographic/behavioral profile | Who is this user? | Persona documents |
| Usability testing | Task completion | Can users do this? | Usability findings |
| NPS surveys | Satisfaction | Would you recommend? | Satisfaction scores |
| Feature surveys | Feature preferences | What do you want? | Feature priority rankings |
JTBD is uniquely causal — it explains why behavior happened. Other methods (personas, NPS, feature surveys) describe or measure but don't explain the underlying motivation.
Tools That Support JTBD User Research
| Tool | Role | Notes |
|---|
| Calendly | Interview scheduling | Recruit and schedule switch interviews |
| Zoom / Loom | Interview recording | Record for transcript analysis |
| Otter.ai / Rev | Transcription | Transcribe recorded interviews |
| Airtable | Coding and clustering | Tag transcripts with push/pull/anxiety/habit |
| Notion | Job statements and research synthesis | Document jobs and patterns |
| Dovetail / Condens | Qualitative research analysis | Code and cluster interview data |
| WebSnips | Competitive research | Clip competitor marketing messages to analyze how they speak to user jobs |
WebSnips and JTBD research: Competitive research is an important complement to JTBD interviews — when you understand the jobs users are trying to do, you need to understand how competitors are positioning themselves to do those jobs. WebSnips clips competitor landing pages, onboarding messages, and marketing copy into organized collections. Comparing competitors' language with your own JTBD findings reveals positioning gaps and competitive differentiation opportunities.
Common JTBD Research Mistakes
Mistake 1: Asking "why do you use this product?" instead of "walk me through when you first decided to switch."
"Why do you use X?" produces rational post-hoc justifications ("it's organized," "it's easy to use"). The timeline interview produces the actual decision story, with real pushes, pulls, and anxieties.
Mistake 2: Recruiting based on demographic profile instead of switch behavior.
JTBD research should recruit based on switch behavior (recently signed up, recently churned), not demographic characteristics. The job is independent of the demographic.
Mistake 3: Stopping at the job statement and ignoring the forces.
The four forces (push/pull/anxiety/habit) are what make JTBD actionable for product and marketing. A job statement without the forces tells you what people are trying to do but not what's driving and blocking the switch.
Mistake 4: Running too few interviews.
JTBD patterns require 10-15+ interviews to emerge. With 3-4 interviews, every anecdote looks like a pattern. At 10+, true patterns separate from individual idiosyncrasies.
Frequently Asked Questions
How many JTBD interviews are enough?
10-15 is typically sufficient to identify the primary jobs and forces for a focused question (e.g., why users sign up). For a complex multi-segment product, 20-30. When themes start repeating without new patterns emerging (saturation), you've done enough.
Is JTBD the same as user stories?
Related but distinct. User stories ("As a [user], I want to [feature], so that [benefit]") are feature-level specifications. JTBD is motivation-level theory — what progress is the user trying to make in their life? User stories can be derived from JTBD job statements, but JTBD operates at a more fundamental level.
Can JTBD be used for B2B products?
Yes — in fact, JTBD can be especially valuable for B2B because the switch decisions are more deliberate and the forces are more articulable. The interview structure is the same; the stakeholders are often more complex (organizational, not individual purchase).
Key Takeaways
- Jobs-To-Be-Done framework for user research reframes research from "who is this user?" to "what job is this user hiring this product to do?" — the progress they're trying to make in a specific circumstance.
- Developed by Clayton Christensen at HBS; refined by Bob Moesta, Chris Spiek, and Alan Klement; published most completely in Competing Against Luck (2016).
- The switch interview — a structured timeline of the decision to switch — is the primary JTBD research method; it uncovers the real causal decision story, not post-hoc justification.
- The four forces — push (what's wrong now), pull (what's attractive about the solution), anxiety (what almost stopped the switch), habit (inertia toward status quo) — explain why switches happen or don't.
- Output: job statements and force patterns that feed product prioritization (address the job), onboarding (reduce anxiety), and messaging (speak to the progress, not the feature).
- Best for: understanding churn, positioning and messaging, product roadmap prioritization; requires qualitative interview-based research (10+ interviews per question).
Conclusion
The Jobs-To-Be-Done framework for user research is the most causally powerful approach available for understanding why users choose, use, and abandon products. By focusing on the job — the progress users are trying to make, in the specific circumstances that triggered the switch — JTBD cuts through the noise of demographic profiles and feature surveys to the underlying motivations that actually drive behavior. For product managers and strategists who need to build products people actually use and communicate their value clearly, JTBD research is one of the most reliable paths from "we have a lot of data" to "we understand what's really happening."
Try WebSnips free — clip competitor marketing pages and customer testimonials to analyze how they speak to user jobs, grounding your JTBD competitive research in real positioning evidence.