Jobs to Be Done (JTBD) is a framework that reframes the fundamental question of product design. Instead of asking, "who is my user?" it asks, "why is my user 'hiring' a product?" The difference is subtle, but it radically changes how you design.
The framework was popularized by Clayton Christensen, a Harvard professor and author of "The Innovator's Dilemma." He famously used an analogy to explain the core idea: "People don't want to buy a quarter-inch drill. They want a quarter-inch hole." This simple insight has changed how product teams at companies like Intercom, Notion, and Slack think about their work.
In this guide, I'll explain what the JTBD framework is in practical terms, how to write a useful job statement, the difference between JTBD and user personas, and how to apply it with real-world examples.
What you'll learn in this guide:
- What a "job" is in the JTBD sense (and it's not a profession)
- The structure of a job statement and how to write one correctly
- The difference between JTBD and user personas (they're complementary, not alternatives)
- The three types of jobs: functional, emotional, and social
- How to conduct "job interviews" (which differ from classic user interviews)
- 5 real-world examples of products that used JTBD for strategic decisions
What is a "Job" in the JTBD Framework
A job in the JTBD framework isn't an occupation. It's the progress a person is trying to make in a particular circumstance. The full name, "Job to be Done," emphasizes that there's something to do, not someone to be.
A more rigorous definition comes from Tony Ulwick of Strategyn, another pioneer of the framework:
"A job is a fundamental goal that people are trying to achieve, independent of any solutions available on the market at a given time."
Three characteristics distinguish a job from a "need" or a "feature":
- It's solution-agnostic. "Listen to music while I run" is a job. "Buy AirPods" is not—AirPods are a possible solution to the job.
- It's stable over time. Jobs remain constant for decades. Solutions change: from cassettes to MP3s to streaming. The job "listen to music on the go" has been the same since the Walkman in 1979.
- It's contextual. The same user has different jobs in different circumstances. The person who wants to "get to work without stress" in the morning is the same person who wants to "relax with a TV show" in the evening.
The Classic Milkshake Example
Christensen famously told the story of a fast-food chain that wanted to increase its milkshake sales. They studied customer personas (age, gender, income) but found nothing useful. Then, someone asked: "What job are customers hiring the milkshake for?"
By observing customers in context, they discovered that 40% of milkshakes were sold at 7:30 AM. The typical customer was a commuter driving to work. Why a milkshake?
The "job" was this: "I need something to keep me engaged during my 30-minute commute, to make me feel less alone in traffic, that won't get my hands messy, isn't so heavy it makes me sleepy, and is satisfying enough to keep me full until 11 AM."
Once they understood the job, the solution changed: they made the milkshakes thicker (to last longer), added small fruit chunks (for an element of discovery), and served them in cups that fit car cup holders. Sales doubled.
No demographic persona would have led to that solution. Only understanding the job in its specific context could.
How to Write a Job Statement
A job statement is the written summary of a job to be done. While several formats exist, the most common one comes from Tony Ulwick (Strategyn):
Verb + Object of the verb + Contextual clarifier
Examples:
- "Minimize the time spent organizing meeting notes" (for a knowledge worker's productivity tool)
- "Feel less isolated during work breaks" (for a messaging app)
- "Find a nearby restaurant to eat with friends without spending hours searching" (for a food delivery app)
- "Keep my team aligned on quarterly goals" (for a B2B project management tool)
The 3 Golden Rules of a Job Statement
- Use an action verb (minimize, find, feel, understand, avoid). Not vague adjectives like "be productive."
- No references to the solution. "Use Slack to communicate" is wrong. "Communicate with colleagues without interrupting their focus" is correct.
- Stable over time. If the job sounds like something that will change in 10 years, it's too specific. Abstract it.
The "When... I want... So I can..." Format
Alan Klement proposed a narrative variation that is useful when you need richer context:
When [situation/trigger], I want to [motivation], so I can [expected outcome]
Example: "When I'm on the subway heading to the office, I want to feel caught up on the day's news, so I can participate in conversations with colleagues without feeling uninformed."
This format better captures the emotional why behind the job and is more effective in workshops with non-technical teams.
The 3 Types of Jobs
A job is rarely just functional. It's almost always a mix of three dimensions:
1. Functional Jobs
The practical, observable, and measurable task. "Transfer money to a friend," "Print a document," "Remember an appointment."
This is the easiest part to understand and measure. But it's rarely the only thing that matters.
2. Emotional Jobs
How the user wants to feel during and after completing the job. "Feel secure," "Feel organized," "Feel knowledgeable in front of colleagues."
Emotional jobs are why "functionally identical" products win or lose. Notion and Evernote do (roughly) the same things, but Notion makes users feel "modern and creative," while Evernote makes them feel like a "diligent archivist." Two different emotional jobs.
3. Social Jobs
How the user wants to be perceived by others when doing the job. "Be seen as an innovator," "Appear attentive to my family," "Avoid looking cheap."
Social jobs are powerful in markets with a status component: fashion, cars, consumer tech. A person doesn't buy an iPhone just for the functional job of "making calls"—there's also the social job of "being perceived as someone who keeps up with technology."
A good job statement captures all three levels when relevant, not just the functional one.
JTBD vs. User Personas: A Complementary Pair
Many articles pit these two frameworks against each other. In reality, they are complementary:
| User Persona | Jobs to Be Done | |
|---|---|---|
| Answers | Who is the user? | What are they trying to do? |
| Focus | Identity, context, demographics | Goal, motivation, circumstance |
| Output | Narrative profile | Job statement |
| Risk of | Creating stereotypes | Ignoring the human context |
| Strong for | Marketing, team alignment | Product decisions, opportunity discovery |
The most sophisticated teams use both:
- User personas to understand who their user segments are (for marketing, copy, and visual direction).
- Jobs to Be Done to understand why they use the product (for feature prioritization, messaging, and product strategy).
To learn more about user personas, read our complete guide to personas.
How to Conduct a Job Interview
JTBD interviews are different from classic UX interviews. They focus less on opinions and more on stories of actual use. The most widely used technique comes from Bob Moesta and Chris Spiek of The Rewired Group:
Step 1: Find People Who Recently Hired a Solution
Don't look for "people interested in..." Find people who have taken concrete action in the last 2-4 weeks: bought a product, started using an app, made a decision. A fresh memory is critical.
Step 2: Uncover the "First Thought"
Ask, "When did the idea of [taking this action] first cross your mind? Where were you? What was happening?" Reconstruct the physical and emotional context. Don't let the interviewee give you rationalized, after-the-fact opinions.
Step 3: Trace the Decision-Making Journey
"What did you do next? Did you talk to anyone? Did you search online? What alternatives did you consider?" Reconstruct every step leading up to the adoption of the solution.
Step 4: Dig into the Forces of Progress
JTBD identifies 4 forces that act on every decision:
- Push (what pushes the user away from their current situation)
- Pull (what attracts them to a new solution)
- Habit (what holds them in their current routine)
- Anxiety (what worries them about the new solution)
A switch happens when Push + Pull > Habit + Anxiety. The interviews aim to identify these four forces in each case.
Step 5: Synthesize into a Job Statement
After 5-10 interviews, look for patterns. Jobs emerge from repetition, not from single instances.
5 Real-World Examples of JTBD in Action
1. Intercom
Intercom is famous for publishing one of the first open-source books on the topic, "Intercom on Jobs-to-be-Done" (2016). They used the framework to decide which features to build based on recurring jobs, such as: "When a user signs up, I want to know who they are and what they do in the product, so I can provide contextual support."
2. Basecamp
Basecamp (formerly 37signals) uses JTBD as a core mindset for all product decisions. Their book "Shape Up" describes a process where every new feature starts with a pitch that explicitly includes the job to be done, not user stories.
3. Spotify Discovery
Spotify reframed its Discover Weekly playlist around a precise JTBD: "When I'm at work and want some background music without being distracted, I want new music I know I'll like without having to choose." The result was a playlist that requires zero decision-making and has generated billions of listening hours.
4. Snickers ("You're not you when you're hungry")
This isn't UX, but it's a perfect example. For years, Snickers marketed itself as a "tasty chocolate bar." Then they identified the emotional job: "When I'm hungry and can't eat a real meal, I want something that will fix me up without making me feel guilty for eating junk food." The "You're not you when you're hungry" campaign (2010) was born from that job statement, increasing global sales by 15% in its first year.
5. IKEA — Täby Store
IKEA studied the jobs of customers at its Täby store in Sweden and discovered that 30% of visitors had the job: "Spend a Sunday afternoon with the family visiting an interesting place, then eat together." It wasn't the job of "buy furniture." They redesigned the store layout with more rest areas, a larger restaurant, and more entertainment for children. Sales increased even as the average visit time doubled.
Common Mistakes When Using JTBD
- Confusing the job with the solution. "Use WhatsApp" is not a job. "Stay in touch with loved ones in an immediate and personal way" is a job.
- Making jobs too generic. "Be happy" is not a useful job. Too much abstraction is useless.
- Ignoring the context. The same user has different jobs in different contexts. Don't treat them as a single entity.
- Skipping the interviews. A job statement created by the team in a workshop is often the opposite of what users are actually trying to do.
- Using it only for incremental features. JTBD is most powerful for disruptive innovation: understanding jobs that are not yet served by the market.
JTBD Tools and Templates
- Job Statement Template (Strategyn) — Available in Tony Ulwick's book "Jobs to Be Done: Theory to Practice."
- Forces of Progress Canvas (The Rewired Group) — A free FigJam template for mapping push, pull, habit, and anxiety.
- The Jobs to Be Done Playbook — An open-source book by Jim Kalbach, one of the most comprehensive guides to applying the framework.
- FigJam Templates — Search for "Jobs to Be Done" in the Figma Community to find dozens of free templates.
- CorsoUX Internal Template — Our complete course provides our own framework with practical examples.
Frequently Asked Questions
Should I replace user personas with JTBD?
No, the two frameworks are complementary. Personas describe who your users are (useful for marketing, visuals, and team alignment). JTBD explains why they use your product (useful for product decisions, features, and strategy). Senior teams use both.
How do I convince my team to use JTBD?
Start with a pilot case. Choose a feature your team is discussing and conduct five job interviews with real users. Present your findings in a 30-minute meeting. The team will see the difference between decisions based on internal opinions and those based on users' real jobs. From there, adoption is often organic.
Does JTBD work for B2B products?
Yes, with a few adjustments. In B2B, "jobs" are often tied to company roles ("As an HR manager, when I need to onboard a new hire, I want to avoid setup errors") and frequently involve multiple stakeholders with slightly different jobs. The framework is still highly applicable.
What's the best book to get started?
"Competing Against Luck" by Clayton Christensen is the classic text on the framework. For a more hands-on approach, "The Jobs to be Done Playbook" by Jim Kalbach is more practical and actionable. Both are featured in our selection of top UX books.
How do I connect JTBD to a product roadmap?
Every feature on the roadmap should explicitly answer the question, "What job are we helping the user with?" If a product team can't answer this, the feature likely lacks a solid foundation and can be deprioritized. Many teams use this as a gate: no feature gets on the roadmap without an associated job statement.
Next Steps
Jobs to Be Done is one of the most cited but least correctly applied frameworks. Designers who can conduct job interviews, write solid job statements, and use them to guide product decisions are among the most sought-after in product-led companies in 2026.
The complete UX Design course by CorsoUX includes a module on JTBD with hands-on exercises: analyzing real cases, simulating job interviews, and running job statement workshops. You'll graduate with an ability to see products through the JTBD lens—a skill that sets junior designers apart in the job market.
To learn more:
- Design Thinking: The 5 Phases — Where JTBD fits into the Empathize phase
- A Guide to User Research — Interview techniques also applicable to JTBD
- User Personas: A Practical Guide — The natural complement to JTBD
- Customer Journey Mapping — Visualize how the job unfolds over time
