The jobs to be done framework explains why people choose products by focusing on the progress they're trying to make. This guide covers the three JTBD schools, the Switch Interview technique, and how to write JTBD statements.
The jobs to be done framework is a theory of customer motivation that explains why people choose products by focusing on the progress they're trying to make, not who they are as a user. Popularized by Clayton Christensen in Competing Against Luck (2016), the framework has three distinct schools: Christensen's narrative approach, Bob Moesta's Switch Interview technique, and Tony Ulwick's Outcome-Driven Innovation, each with different research methods and outputs.
For UX teams, JTBD is most valuable as a discovery tool: it reveals the context behind switching decisions, surfaces non-obvious competitors, and produces job statements that serve as shareable deliverables alongside personas and journey maps.
This guide covers the complete jobs to be done framework, from foundational theory to how you run a Switch Interview, write a JTBD statement, and apply it in a UX research workflow.
The jobs to be done framework is a theory of demand. Its core claim: customers "hire" products to make progress in a specific situation. When a better alternative appears, they "fire" the product.
Bob Moesta, one of the framework's co-creators, puts it directly:
People hire products to make progress in their life. At some point they're in some context and there's some outcome they want, and if we can understand that we start to realize that different things compete.
Demand-side thinking changes how you categorize competition. Snickers and Milky Way are both candy bars. Demand-side analysis reveals they compete for different jobs.
Snickers competes with protein drinks and energy bars (the job: recover from a missed meal). Milky Way competes with a glass of wine or a run (the job: emotional recovery after stress).
Feature benchmarking would never surface this. JTBD does.
UX teams have a specific problem JTBD is built to solve: understanding the why behind user decisions.
Demographics tell you who your user is. Personas capture psychographic profiles. Neither explains what pushes someone to change behavior, switch products, or choose one tool over another.
UserInterviews' UX Research Field Guide positions JTBD job statements as a research deliverable on par with personas, customer journey maps, and atomic research nuggets. The output of a JTBD research engagement is a shareable artifact, not just an internal analysis. That shift matters for UX teams who need to communicate findings to product and engineering stakeholders.
The keyword data shows sustained professional demand. "Jobs to be done framework" pulls 2,400 monthly searches at low competition. Adjacent queries like "jtbd statements" (210/mo) and "jobs to be done template" (320/mo) show specific how-to intent among practitioners.
Standard guides treat the jobs to be done framework as a single methodology. Three distinct schools emerged in the 1990s, each with different research methods, outputs, and applications.
Clayton Christensen (Harvard Business School, Competing Against Luck 2016) brought JTBD to mainstream business audiences through the milkshake story and the "hire/fire" metaphor. His approach is qualitative and narrative: understand why people make purchases in the context of their lives by studying the story around the switching decision.
Christensen is the popularizer, not the originator. He co-developed the framework with Moesta in the mid-1990s, building on work Ulwick was already doing.
Bob Moesta (The Re-Wired Group) developed the Switch Interview technique and the four forces model. His book Demand-Side Sales (2020) applies JTBD to sales contexts, and his 70-minute interview with Lenny Rachitsky on Lenny's Podcast remains the most cited practical introduction to his method.
Moesta's key contribution is the "struggling moment causes demand" insight. As he explains it:
Supply and demand are not as connected as everybody thinks. Most people think they create a product and that creates demand. But it's a struggling moment that creates demand. That struggling moment can exist for a long time and nobody solved it.
For UX researchers, Moesta's Switch Interview is the most directly applicable JTBD technique. It focuses on the specific moment a user switched from one solution to another: that switching moment is where the job reveals itself most clearly.
Tony Ulwick (Strategyn) invented Outcome-Driven Innovation (ODI) in the early 1990s, before Christensen popularized "jobs" language. Ulwick's background was in IBM product engineering; the PCjr failure in 1984 and 18 months of work on a failed product drove his innovation research.
ODI is structured and quantitative where Christensen and Moesta are qualitative. Ulwick maps customer "desired outcomes" (specific, measurable results customers want) to innovation investment decisions. This produces a prioritization framework, not just a research lens.
Most content attributes JTBD to Christensen alone. The accurate framing: Ulwick invented ODI, Moesta co-developed the framework with Christensen, and Christensen gave it mass-market reach. Using "Christensen" as shorthand for the whole framework causes practitioners to default to narrative-only research when a more structured approach (ODI) or a more interview-focused approach (Switch Interview) would serve their research question better.
Every job has three dimensions, and UX teams routinely surface only the functional job.
Functional jobs are the practical tasks a user needs to accomplish: sending a file, booking a meeting, tracking a project.
Social jobs are about how users want to be perceived by others. A finance professional buying an expensive analytics tool has a social job on top of the functional one: signaling sophistication to their CFO. A UX researcher presenting a JTBD deliverable shifts their team's status from tactical executor to strategic partner.
Emotional jobs are personal feelings and motivations. Users switching from spreadsheet budgeting to a finance app are hiring the product for a feeling: control over their finances. A LogRocket case study on JTBD in fintech confirmed the same pattern: identifying the emotional job completely redirected the team's design priorities.
Missing the social and emotional dimensions is the most common JTBD implementation failure. You can identify the functional job correctly and still ship the wrong product if you don't understand the emotional job that makes someone actually switch.
JTBD reframes competition from supply-side (who else makes a similar product?) to demand-side (who else competes for the same struggling moment?). u/feyd87 in r/ProductManagement put it clearly:
Jobs are meant to be somewhat consistent, it's the solutions that are constantly evolving. The reasons people listen to music haven't changed a whole lot over the years. But how people listen is where the innovation has occurred.
That's the structural claim: jobs are stable across technology generations. The competitive set changes, but the underlying job doesn't. A roadmap built around a struggling moment (make my commute more enjoyable and filling) survives technology disruption in a way that a roadmap built around a feature (milkshake size) doesn't.
Bob Moesta's Switch Interview is the most directly applicable JTBD technique for UX researchers. It centers on one question: what was the specific moment this user decided things had to change?
Every switching decision involves four forces pulling in opposite directions.
Force | Direction | Description |
|---|---|---|
Push | Toward switch | Dissatisfaction with the current solution |
Pull | Toward switch | Appeal of the new solution |
Anxiety | Against switch | Fear of the unknown, switching costs |
Habit | Against switch | Comfort with the old solution, inertia |
When Push + Pull > Anxiety + Habit, the switch happens. When it doesn't, the product earns agreement but not behavior change.
Understanding which force dominates tells you where to focus. A product with strong Pull but persistent Habit means you need to reduce switching friction, not add more features. A product with strong Push (users hate their current solution) but strong Anxiety means you need to reduce uncertainty in onboarding, not improve the product.
The Switch Interview is retrospective. You ask users to reconstruct a past switching decision: what triggered it, what they feared, what habits had to change. That moment is where the job reveals itself most clearly.
Key probe questions, sourced from r/UXResearch practitioners and Moesta's method:
As u/Traditional_Bit_1001 in r/UXResearch noted:
JTBD isn't just about current process. It's also about why those steps exist in the first place (the underlying progress they're trying to make). Instead of just asking 'what do you do?', try pushing on 'what triggers you to act?' and 'what would happen if you couldn't do this?'
One of the most reliable JTBD discovery techniques doesn't require interviews at all. As u/poodleface in r/UXResearch described:
I ask them to show me their ad-hoc processes or workarounds. When people make their own spreadsheet to do something as opposed to using your product, that spreadsheet (and how it is used) tells you a lot about what really matters to folks.
A workaround is an artifact of an unmet job. When users build their own tools around your product, they're telling you which job your product isn't doing.
Bob Moesta applied this logic at Southern New Hampshire University around 2010. SNHU noticed 50-60 enrolled students who never attended physically, all doing a different job: "make progress on my career without disrupting my existing life."
SNHU rebuilt its model around that job. It became one of the largest universities in the United States.
JTBD statements translate raw interview findings into structured deliverables your team can act on. The standard format:
"When [situation/trigger], I want to [motivation], so I can [outcome]."
This format appears across multiple JTBD practitioners and Moesta's own teaching. The situation captures the trigger or struggling moment.
The motivation names the underlying job. The outcome names the progress the user is trying to make.
Job stories and user stories address different stages of the product development cycle.
Format | Template | Focus | Best for |
|---|---|---|---|
User story | As a [user type], I want to [goal], so I can [benefit] | Feature/identity | Sprint planning, developer tickets |
Job story | When [situation], I want to [motivation], so I can [outcome] | Context, motivation | Discovery, strategy |
The key structural difference: job stories eliminate the persona ("As a [user type]") and replace it with the situation. This removes the assumption that identity predicts behavior (the core JTBD critique of persona-driven product decisions).
Both formats can coexist. Job stories work for discovery and strategy; user stories work for execution and sprint planning. Alan Klement (@alanklement), author of When Coffee and Kale Compete, articulates the line:
Activities are not jobs. They are solutions for jobs.
The most common JTBD implementation error in UX teams is trying to replace personas with JTBD. They answer different questions.
NNGroup's personas vs JTBD comparison frames it correctly: personas answer "who," JTBD answers "why." Using one to replace the other loses what the other provides. Personas without JTBD produce vivid characters with unclear motivations. JTBD without personas loses segment-level nuance when your product serves meaningfully different user groups.
Where JTBD beats personas: when you need to understand why users switch, stay, or churn. Personas don't have a built-in mechanism for capturing the decision architecture around behavior change. JTBD does, through the four forces.
McDonald's wanted to increase milkshake sales. Market research identified the demographic profile of milkshake buyers and tested flavors. Nothing worked.
Christensen's team took a different approach: they asked when milkshakes were bought and why. Most were purchased in the morning by solo commuters doing a specific job: make the commute more enjoyable and filling.
The commuter needed something that lasted the drive (thick), was easy to hold and eat one-handed, and was more satisfying than a banana.
McDonald's was competing with bagels, bananas, and Starbucks lattes rather than other shakes. The fix was structural: thicker shake, smaller straw, faster morning service.
The milkshake story is the canonical JTBD example. It shows what happens when you stop asking "what features should we improve?" and start asking "what job are customers hiring this product to do?"
The most common error: teams run JTBD workshops and produce statements like schedule a meeting or review a pull request. Those are activities: solutions to underlying jobs.
The job behind scheduling meetings is ensuring stakeholders are aligned before a critical decision gets made without them. That distinction changes product strategy completely.
Alan Klement states this consistently: "Activities are not jobs. They are solutions for jobs." A job that depends on a specific technology is a solution description, not a job.
Teams typically surface the functional job and stop. Social and emotional dimensions explain why users switch, and why products that solve the functional job still fail to gain traction. A product that makes you faster but makes you look less sophisticated to your peers will face persistent resistance even when the functional case is clear.
On r/ProductManagement, multiple practitioners describe a guiding-principle approach rather than a step-by-step script:
In truth I don't use it as a framework, more as a guiding principle that we need to be thinking of our customers as people with a specific job to do.
Forcing JTBD into rigid workshop templates produces formulaic job statements that sound right but don't reflect actual user motivation.
JTBD works at the strategy and execution layer. u/nikstep in r/ProductManagement named the boundary precisely:
JTBD should not define the 5-year vision (where true disruption happens). JTBD is closer to strategy and execution.
Technology-push disruption (inventing a category that doesn't exist yet) requires a different toolkit. JTBD explains the demand that already exists; predicting what people will want after a technology they've never seen becomes available requires a different lens.
47 UX statistics covering ROI, accessibility, mobile experience, page speed, and the state of UX research.
Discover the top 10 UX research tools for 2026. Compare features, pricing, and capabilities to find the perfect platform for your team's user research needs.
