Jobs to Be Done UX is a research framework based on the insight that users don’t buy or use products for their features – they “hire” products to get a specific job done, and understanding that job more precisely than the user can articulate it is the key to building something they’ll actually choose.
Why It Matters
Most product teams define their users by who they are: demographics, psychographics, behavioral segments. A typical user persona describes a 32-year-old marketing manager who lives in London, uses Instagram, and values work-life balance. This tells you something. But it doesn’t tell you why she downloaded your app on a Tuesday morning, what she was trying to accomplish, and what alternative she was using before she tried yours.
Jobs to Be Done shifts the question from “who is the user?” to “what is the user trying to accomplish, and what’s preventing them from doing it efficiently?” The insight, developed by Harvard Business School professor Clayton Christensen, is that progress – not demographics – drives behavior. People make choices because they’re trying to move from a current situation to a better one. The product that gets hired is the one that makes that transition most effectively.
This framing has significant practical consequences. It helps teams identify competitors they’d otherwise miss (your real competition might not be a similar product – it might be a spreadsheet, a phone call, or doing nothing). It focuses innovation on the job itself rather than on feature parity with competitors. And it generates design decisions grounded in actual user motivation, not assumed preference.
How It Works / Types of Jobs
Every job has three layers. Understanding all three is what separates a complete JTBD analysis from a shallow one.
Functional jobs describe the practical task the user is trying to accomplish. “I need to transfer money to my landlord by Friday.” “I need to plan meals for the week.” “I need to find a plumber who’s available tomorrow.” These are the observable surface-level jobs.
Emotional jobs describe how the user wants to feel during or after the task. A parent booking a pediatrician appointment doesn’t just want to schedule a time slot – they want to feel like a responsible caregiver who’s handling things properly. A job seeker using a resume builder isn’t just formatting text – they want to feel confident and competitive. Emotional jobs are often more stable and durable than functional jobs, which change as technology evolves.
Social jobs describe how the user wants to be perceived by others. Buying a premium notebook at a creative agency meeting is partly about the functional job (writing notes) and partly about the social job (signaling that you take your craft seriously). Social jobs are underrated in product design and often explain why users choose a more expensive or less efficient option over a technically superior one.
Job Story Format
Lean UX and JTBD practitioners use job stories instead of – or alongside – traditional user stories. The format:
“When [situation], I want to [motivation], so I can [expected outcome].”
Compare:
- User story: “As a busy professional, I want to set recurring calendar reminders, so I can stay organized.”
- Job story: “When I’m juggling multiple deadlines and feel like things are slipping through the cracks, I want a single place where I can see everything I’m supposed to do today, so I can feel in control and stop worrying about what I’m forgetting.”
The job story captures the emotional context and the specific situational trigger that makes the job urgent. This is more actionable design input than a role-based feature request.
JTBD vs Persona – Not a Replacement
A common misreading of JTBD is that it replaces personas. It doesn’t – it complements them. Personas describe who your users are; JTBD describes what they’re trying to accomplish. Together, they give a fuller picture.
The practical difference: two people with identical personas (same age, profession, income, lifestyle) might hire your product for completely different jobs. A solo freelancer and an agency project manager might both use the same task management app, but one “hires” it to avoid missing client deadlines and the other “hires” it to delegate and track work across a team. The same product feature serves both, but the design emphasis and onboarding flow should be different.
JTBD is especially valuable when user personas aren’t generating useful design decisions – when the team can describe users precisely but still can’t agree on what to build.
How to Collect JTBD Data – Switch Interviews
The most reliable JTBD research method is the switch interview. Instead of asking users what they want or what features they like, you interview them about a specific decision they made: switching to your product (or away from a competitor).
The interview focuses on the exact moment of the switch: what was happening in their life at that time, what they were using before, what triggered them to look for an alternative, what else they considered, and what made them choose what they chose. This narrative reveals the job with high fidelity – because you’re not asking users to predict future behavior, you’re asking them to reconstruct a real past decision.
This complements other research methods like empathy maps and journey maps, which capture the broader experience, while switch interviews pinpoint the motivational core.
Real-World Example
Clayton Christensen’s most cited JTBD example is a fast food chain that wanted to increase milkshake sales. Traditional research – surveying customers about flavor preferences, asking what would make a better milkshake – produced incremental suggestions that didn’t move sales.
Christensen’s team studied the actual purchase behavior. They found that nearly half of all milkshakes were bought in the morning by solo commuters. These weren’t treat-seekers. They were hiring the milkshake to do a specific job: make the long commute less tedious, while being easy to consume one-handed and lasting through a boring meeting. The milkshake competed not with other desserts but with bananas (finished too fast, left a mess), bagels (needed two hands, required cream cheese), and boredom itself.
The insight reframed the entire product problem. A thicker, chunkier milkshake – harder to finish quickly – served the commuter job better. A thinner, faster version served the afternoon family treat job better. Same product category, two different jobs, two different design directions.
How to Apply
- Conduct switch interviews with recent new users. Ask specifically about the moment they decided to switch – what was happening, what they were using before, what they looked at and rejected, and what finally pushed them to choose your product. The narrative reveals the job.
- Document functional, emotional, and social dimensions of each job. If your job statement only describes the functional task, it’s incomplete. Probe for how users wanted to feel and how they wanted to be seen.
- Write job stories instead of user stories for complex features. The “When/I want/So I can” format preserves situational context that user stories strip out. Try both and compare which generates more useful design discussion.
- Use JTBD to audit your feature set. For each major feature, ask: which job does this serve? If nobody on the team can answer clearly, the feature may exist for internal reasons rather than user reasons.
- Map jobs to your journey map. Jobs are the motivation layer beneath the journey. Adding job annotations to a journey map shows not just what users are doing at each stage, but why they care about getting it done.
Common Mistakes
Treating JTBD as a replacement for personas. The two frameworks answer different questions. Abandoning personas entirely in favor of JTBD leaves the team without user context. Abandoning JTBD in favor of personas leaves the team without motivational insight. Use both.
Writing functional-only job statements. “When I need to save a file, I want cloud storage, so I can access it later” is a feature request disguised as a job statement. A real job statement includes the situational pressure and the emotional or social stakes.
Confusing the job with the solution. “I want to use a milkshake” is not a job – it’s a product preference. “I want something that keeps me occupied and feeling like I have a purpose during a boring commute” is a job. The distinction keeps product thinking at the level of motivation, not implementation.
Related Concepts
- User Persona – the who-based complement to JTBD’s why-based framework
- Empathy Map – captures the emotional context that emotional jobs surface
- Journey Map – the experience structure that jobs animate at each touchpoint
- Design Thinking – the broader process JTBD data feeds into for problem framing