Have you ever launched a product packed with features that users specifically asked for, only to see it met with a deafening silence? You built what they said they wanted, but they didn’t buy, and they didn’t switch. As a product manager, this is one of the most frustrating puzzles to solve. The problem often isn’t in your execution, but in your premise. You focused on what the customer wanted to have, not why they needed to make progress in their life. This is where the Jobs To Be Done (JTBD) framework changes everything.
Jobs To Be Done is more than just another product development buzzword; it’s a fundamental shift in perspective. It provides a lens to understand the deep, underlying motivations that cause customers to choose one product over another. This guide will take you from a beginner’s curiosity about JTBD to a professional’s ability to apply it. You’ll learn the theory, the famous milkshake story, and the practical steps to start uncovering the “jobs” your customers are trying to get done, so you can build products they will actually hire.
Definition & Origin: The Famous Milkshake Problem
The theory of Jobs To Be Done was pioneered by innovators like Tony Ulwick in the 1990s through his Outcome-Driven Innovation (ODI) process. However, it was popularized by the late Harvard Business School professor Clayton Christensen, who famously used a milkshake to explain the concept.
Christensen’s team was hired by a fast-food chain to improve milkshake sales. The company had already tried making them chocolatier, cheaper, and chunkier, based on customer feedback, but nothing worked. Instead of focusing on the product, Christensen’s team asked a different question: “What job do people hire a milkshake to do?”
After observing and interviewing customers, they discovered two very different jobs:
- The Morning Job: Commuters were “hiring” the milkshake for their long, boring drive to work. It was easy to consume with one hand, it was thick and took a long time to drink (relieving boredom), and it was filling enough to stave off hunger until lunch. The competition wasn’t other milkshakes; it was bananas (too messy), donuts (sticky fingers), and bagels (hard to eat while driving).
- The Afternoon Job: Parents were “hiring” the milkshake as a treat for their kids. Here, the job was to be a fun, quick way to say “yes” to a child and feel like a good parent. The competition was other treats or simply saying “no.”
By understanding the “job,” the fast-food chain could improve the product to better serve that need. For the morning commuters, they could make the shake even thicker to last longer and create a self-service kiosk for a quicker getaway. For the afternoon parents, they could offer smaller, less-filling sizes. The lesson was profound: focus on the customer’s context and goal, not their demographic or the product’s attributes.
Core Benefits & Strategic Use-Cases of JTBD
Adopting a JTBD mindset provides a clear and powerful roadmap for innovation. Here’s why it matters:
- Uncovers True Competition: Your competition is rarely who you think it is. For the morning milkshake, the competition was a bagel, not another milkshake. JTBD reveals the diverse set of solutions customers use to get a job done.
- Predicts Customer Behavior: By focusing on the underlying motivation (the “job”), you can better predict why customers will switch to your product or stick with their current solution.
- Creates Better Marketing: When you understand the job, you can create marketing messages that resonate with the customer’s struggle and desired progress, rather than just listing product features.
- Aligns the Entire Team: JTBD provides a shared language and a north star for product, marketing, sales, and design. Everyone becomes focused on helping the customer make progress.
- Identifies Opportunities for Innovation: By deconstructing a job into its steps and desired outcomes, you can pinpoint exactly where customers are struggling and where the biggest opportunities for innovation lie.
How It Works: A 5-Step Guide to Applying JTBD
Jobs To Be Done is not just a theory; it’s an actionable process. Here’s a practical guide to putting it to work.
Step 1: Define the “Job” You’re Studying
Start by defining the scope. Are you trying to understand a broad job like “maintain a healthy lifestyle” or a more specific one like “get a healthy meal on the table on a busy weeknight”? Be clear about the area you are investigating.
Step 2: Conduct JTBD Interviews
This is the heart of the framework. A JTBD interview is not a typical user feedback session. You aren’t asking about features. Instead, you are digging into the story of a recent purchase.
- Find the “Struggling Moment”: What pushed the customer to look for a new solution?
- Map the Timeline: Reconstruct the entire journey, from the first thought about making a change to the actual purchase and beyond.
- Listen for the “Forces of Progress”: As articulated by JTBD experts Bob Moesta and Chris Spiek, four forces are at play in any decision to switch:
- Push: The problem with the current situation (“My current spreadsheet is too clunky.”)
- Pull: The appeal of the new solution (“This new app looks so much easier.”)
- Anxiety: The fears about the new solution (“What if it’s hard to learn? What if I lose my data?”)
- Habit: The inertia of the current situation (“I’m just used to my old spreadsheet.”) A switch only happens when the Push and Pull are stronger than the Anxiety and Habit.
Interlinking Prompt: Link to a detailed guide on conducting customer interviews and usability testing.
Step 3: Craft “Job Stories”
Once you understand the job, capture it in a “Job Story.” This format is a powerful alternative to user stories because it focuses on context and motivation.
- The Format: When
<situation>
, I want to<motivation>
, so I can<expected outcome>
. - Example: When
I'm on my morning commute
, I want tohave a simple, filling snack
, so I canarrive at work feeling satisfied and not hungry
. This is far more insightful than a user story like, “As a commuter, I want a milkshake.”
Visual Asset Prompt: An infographic showing the anatomy of a Job Story (
When [Context] + I want to [Motivation] + so I can [Outcome]
) with 2-3 clear examples.
Step 4: Deconstruct the Job & Identify Desired Outcomes
For a more rigorous analysis, as championed by Tony Ulwick, you can break the core job down into steps. For each step, identify the customer’s desired outcomes—the metrics they use to judge how well the job is getting done. For the job of “getting a healthy meal on the table,” outcomes might include:
- Minimize the time it takes to clean up.
- Minimize the likelihood of using an unhealthy ingredient.
- Increase the likelihood that the whole family enjoys the meal.
Step 5: Analyze the Real Competition
Armed with a deep understanding of the job and desired outcomes, you can now see the competitive landscape with new eyes. You’ll see that a customer trying to “unwind after a stressful day” might hire a glass of wine, a video game, a yoga app, or a conversation with a friend. These are all competing solutions for the same job. This insight opens up entirely new strategic possibilities.
Jobs To Be Done (JTBD) vs. User Personas
A common question is how JTBD relates to user personas. They are not mutually exclusive; they are complementary tools that answer different questions.
Feature | User Personas | Jobs To Be Done (JTBD) |
Core Question | Who are the users? | Why do users do what they do? |
Focus | User attributes, demographics, behaviors, and goals. (e.g., “Marketing Mary, 35”). | The user’s situation, motivation, and desired outcome. The progress they want to make. |
Primary Use | Building empathy, guiding design decisions, and segmentation. | Uncovering innovation opportunities, defining the value proposition, and understanding competition. |
Limitation | Correlation is not causation. Knowing a user’s demographic doesn’t explain why they buy. | Can be too abstract if not grounded in rigorous interviews and real-world context. |
In short: Personas help you understand who you are designing for. JTBD helps you understand what problem you are solving for them. A 35-year-old marketing manager and a 65-year-old retiree might both hire a financial planning app for the exact same job: “feel secure about my financial future.”
Common Mistakes to Avoid
As you adopt JTBD, steer clear of these common pitfalls:
- Confusing a Job with a Task: “Create a spreadsheet” is a task. “Organize and share financial data to secure a business loan” is a job. Jobs have emotional and social dimensions that tasks lack.
- Making the Job About Your Product: The job should be solution-agnostic. “Create a presentation with our software” is not a job. “Effectively communicate a business case to my executives” is the real job.
- Ignoring the Emotional & Social Dimensions: Jobs are rarely just functional. The parent buying the milkshake has an emotional job: “feel like a good dad.” The person buying a luxury car has a social job: “signal my success and status.”
- Conducting Poor Interviews: Asking leading questions or focusing on product features will not uncover the true job. The interview technique requires practice and discipline.
Conclusion
Jobs To Be Done is more than a framework; it’s a profound mindset shift. It forces you to lift your head up from the feature backlog and look at the world through your customer’s eyes. It pushes you to understand their context, their struggles, and their definition of progress. When you stop asking “What features should we build?” and start asking “What job is our customer trying to get done?”, you unlock a more reliable and predictable path to innovation.
Building a successful product is not about having the longest feature list or the most detailed user persona. It’s about deeply understanding the progress your customer is trying to make and designing a solution that they are thrilled to “hire” for that job. Start by looking for the struggling moments. Talk to your customers about their journey. Listen for the job. It’s the most valuable product specification you will ever find.
Jobs To Be Done is a theory that customers don’t buy products, they “hire” them to make progress in their lives. Instead of focusing on who the customer is (demographics), JTBD focuses on what they are trying to accomplish (their “job”). For example, you don’t buy a drill because you want a drill; you buy it because you want a hole in the wall. The hole is the job.
The framework was pioneered by multiple innovators. Tony Ulwick developed a rigorous, process-oriented version called Outcome-Driven Innovation in the 1990s. Clayton Christensen, a Harvard Business School professor, popularized the concept and its application to marketing and innovation, most famously with his “milkshake” case study.
A User Story focuses on a user type and a desired action, often tied to a solution (As a <user>, I want <action>, so that <benefit>
). A Job Story focuses on a situation and a core motivation, remaining solution-agnostic (When <situation>, I want to <motivation>, so I can <outcome>
). Job Stories are better for defining the problem, while User Stories are better for defining the solution.
No, they are complementary. A User Persona describes who the customer is (their attributes and characteristics). JTBD describes the why behind their actions (their situation and motivation). You can use personas to better understand the people who have a particular “job,” but the job itself is often independent of their demographic profile.
You find the job by talking to your customers, but not in a typical feedback session. You conduct specific “JTBD interviews” where you ask customers to tell you the story of how and why they recently purchased your product (or a competitor’s). The goal is to uncover the “struggling moment” that pushed them to seek a new solution.
Learn better with active recall quiz
How well do you know What Is Jobs To Be Done (JTBD)? Let’s find out with this quick quiz! (just 10 questions)