As a Product Manager, your primary directive is to build products customers will actually buy and use. The Jobs to be Done (JTBD) framework is the most reliable system for achieving this. It operates on a simple premise: customers don't buy products; they hire them to make progress in their lives. They have a specific "job" to get done.
This guide provides an actionable, step-by-step process for implementing JTBD, moving you from abstract theory to a concrete roadmap within 48 hours. We'll cover the core concepts, a script for user interviews, and a template for turning insights into action, including specific AI prompts to accelerate your workflow.
The Actionable JTBD Framework: From Insight to Roadmap
Here is the end-to-end workflow we will unpack in this guide. This is the system PMs at fast-growing startups and innovative FAANG teams use to de-risk product development.
- Identify the "Struggling Moment": Pinpoint the event that forces a customer to look for a new solution.
- Conduct JTBD Interviews: Use targeted, past-focused questions to uncover the real story behind a purchase decision.
- Synthesize with AI: Use LLMs like ChatGPT or Claude to rapidly extract core jobs, forces, and outcomes from interview transcripts.
- Define the Job Story: Articulate the customer's need using the "When… I want to… so I can…" format.
- Prioritize & Strategize: Map jobs by customer struggle and market opportunity to build a data-backed roadmap.
This process transforms your focus from building features to solving high-value customer problems.
Why Your Feature-Packed Product Is Failing
Ever been in this situation? Your team at a high-growth SaaS company just shipped a beautiful new feature set. You spent months in development, nailed the product discovery process, and the engineers delivered a masterpiece. An entry-level PM might celebrate the launch, but a seasoned PM knows the real test is what happens next.
After launch… crickets. Engagement is flat. No one is using those shiny new tools, and the metrics you've been obsessing over refuse to budge. This isn't a technical failure; it's a failure of understanding.
It's a story I’ve seen play out countless times. We get so focused on what the product does that we forget why a customer would ever care enough to pull it into their life. We build what we assume people want—more features, faster speeds, a slicker UI—without ever digging into the real struggle they're trying to overcome.
Jobs to be Done gives you a way out of this feature-factory cycle. It forces you to stop obsessing over your solution and start obsessing over your customer's problem. What progress are they trying to make? What's holding them back?
The Famous Milkshake Example
Pioneered by thinkers like Clayton Christensen back in the late 1980s, JTBD gained fame through a classic study for a fast-food chain trying to sell more milkshakes. They tried everything—asking customers about flavors, thickness, price—but nothing moved the needle.
Then, they looked at the situation through the JTBD lens. They discovered something wild: 40% of milkshakes were sold before 8:30 AM to commuters. These customers weren't hiring a milkshake to be a sweet treat. They were hiring it for a completely different job.
They needed something that could:
- Keep them busy during a long, boring drive to work.
- Be consumed easily with just one hand on the wheel.
- Feel substantial enough to quiet a rumbling stomach until lunchtime.
Suddenly, the milkshake wasn't competing with other milkshakes. It was competing with bananas, bagels, and lukewarm coffee. This insight was a game-changer. The company could now optimize the milkshake to do that specific job better, like making it thicker to last the whole commute or creating a grab-and-go purchasing experience.
From Building Features to Solving Problems
This mindset shift is at the heart of Jobs to be Done. It's not just some abstract theory; it's a practical framework that reorients your entire product strategy. It’s the difference between asking, "What features should we add?" versus "What job is our customer trying to accomplish?"
This table breaks down the fundamental shift in thinking.
Traditional Product Thinking vs Jobs To Be Done Thinking
| Focus Area | Traditional Product Thinking (Feature-First) | Jobs To Be Done Thinking (Problem-First) |
|---|---|---|
| Primary Question | "What features should we add to the product?" | "What progress is the customer trying to make?" |
| Unit of Analysis | The User Persona or The Product Itself | The "Job" the customer is trying to accomplish. |
| Competition View | Direct competitors with similar features. | Any solution the customer uses to get the job done. |
| Innovation Goal | Add more features or improve existing ones. | Help the customer get the job done better or cheaper. |
Moving from the left column to the right is how you de-risk your roadmap and build products people actually want and need. It’s about anchoring every decision not in what you can build, but in what they need to achieve.
Understanding The Core JTBD Concepts
To stop building features and start solving real problems, you need a different way of thinking—and a different vocabulary to go with it. Let's break down the essential building blocks of the Jobs to be Done framework. Think of these not as academic terms, but as lenses to see your customers' world with stunning new clarity.
At its core, a "Job" isn't a task or an activity. It's the progress a person is trying to make in a particular circumstance.
When customers buy a product, they are essentially "hiring" it to get a job done. A busy parent doesn't just buy a frozen pizza; they hire it to "provide a quick, satisfying meal for the family on a chaotic weeknight." Getting this distinction right is the first real step toward building things people actually want.
The Forces of Progress
So why does someone switch from one solution to another? It’s almost never a single event. It’s a messy, internal tug-of-war between four key psychological forces that shape every decision. If you want to know why customers buy—or more importantly, why they don't—you have to understand these forces.
This diagram perfectly illustrates the push-and-pull dynamic that drives customer choice.
These forces lay bare the internal debate a customer has before making a change. They show us that any new solution has to overcome not just the anxiety of the new, but the powerful inertia of the old.
Let's break them down:
- Push of the Situation: This is the pain. It's the struggle with the current solution that gets so bad, a person is forced to look for something new. For a small business owner, this might be the sheer number of hours torched manually reconciling receipts in a spreadsheet.
- Pull of the New Idea: This is the magnetic appeal of your solution. That same business owner sees an ad for accounting software that promises automated reconciliation and instant financial reports, painting a picture of a much better future.
- Anxiety of the New Solution: These are all the "what ifs" that pop up. "Will this new software be a nightmare to learn? What if I mess up migrating my data? Can I really trust it with my company's finances?"
- Habit of the Present: This is the powerful, invisible gravity of the status quo. Even if the spreadsheet is a total pain, it's familiar. It's predictable. The comfort of "the way we've always done it" is a massive force that fights against any change.
Key Takeaway: For a customer to make the switch, the combined forces of Push and Pull must be stronger than the combined forces of Anxiety and Habit. Your job as a PM is to dial up the pull of your solution while systematically dialing down the anxiety of switching.
This model is a powerful reminder of why just having a "better" product is never enough. You have to get into the messy context of the struggle. For instance, in-depth research on how students choose colleges revealed the complex emotional, social, and functional forces pulling them in different directions—insights that traditional surveys completely miss. You can dig deeper into these findings and the JTBD lens on the Christensen Institute's website.
Desired Outcomes
Finally, how do you know if you're actually getting the job done well? This is where Desired Outcomes come into play. These are the solution-free metrics customers use, whether they realize it or not, to judge success.
They are not features; they are measures of progress. For that business owner hiring accounting software, the desired outcomes might sound like this:
- Minimize the time it takes to prepare for tax season.
- Increase the confidence I have in the accuracy of my financial data.
- Reduce the likelihood of making a costly accounting error.
By focusing on these stable, measurable outcomes, you can innovate with a real purpose. Instead of just guessing at features, you can systematically pinpoint the outcomes where customers are most underserved and point your entire product strategy in that direction. This gives you a clear, customer-centered roadmap for creating real value.
How To Uncover Customer Jobs With Effective Interviews
Theory is great, but the real breakthroughs happen in conversation. If you want to truly understand the jobs to be done driving your customers, you need to master a specific interview style. It feels more like investigative journalism than your typical user research.
Standard user interviews tend to zero in on feature feedback, usability testing, or hazy future needs. They ask questions like, "What would you like this product to do?" or "How would you rate this feature?" These questions are fine for optimization, but they're terrible for uncovering the fundamental why.
JTBD interviews are a different beast entirely. Think of them as archaeological digs into a customer's recent purchasing decision. You're not interested in their opinions about your product; you're obsessed with the real story of the struggle that sent them looking for a new solution in the first place.
The Power Of The "Struggling Moment"
The single most critical thing to uncover in a JTBD interview is the "struggling moment." This is the precise point in time when the customer's old way of doing things finally fell apart. It's the "first thought" that kicked off their search for something better.
Your job is to reconstruct the entire timeline of events, like a documentary director. Start from that moment of frustration and follow it all the way to their purchase of a new solution (which, by the way, may or may not be your product).
This process is all about piecing together the core concepts of the framework: the job itself, the forces pushing and pulling the customer, and the outcomes they're hoping for.
As you can see, figuring out the "job" is just the start. The real gold is in dissecting the forces that drive a customer toward something new and the specific outcomes they use to measure success.
Key Differences From Traditional User Interviews
Getting this right means adapting your interview style. A PM at Google running a usability test asks very different questions than a PM at a startup trying to find product-market fit using JTBD. The focus shifts completely from your product to the customer's story.
To get a better sense of this shift, it's helpful to see a side-by-side comparison of the two approaches.
Key Differences JTBD Interviews vs Traditional User Interviews
| Interview Aspect | Traditional User Interview | Jobs To Be Done Interview |
|---|---|---|
| Time Focus | The future ("What would you like?") or present ("How does this work for you?"). | The past ("Tell me about the last time you…"). |
| Core Question | "What do you want?" or "Is this usable?" | "What progress were you trying to make?" |
| Subject | The product, its features, and the user's opinions about them. | The customer's story, their context, and their decision-making process. |
| Desired Output | A list of feature requests, usability issues, or validation of an idea. | A detailed timeline of the struggle, the forces of progress, and desired outcomes. |
Mastering this interview style is a skill. It's worth digging into broader guides on how to conduct effective user interviews and then layering the JTBD methodology on top of those foundational principles.
A Practical Script Template To Get Started
You can't just ask, "What is your Job to be Done?" People don't think that way. You have to coax the story out of them with open-ended, backward-looking questions. The goal is simple: get them to relive the experience for you.
Here are some powerful, non-leading questions to build your script around:
1. Opening the Story:
- "Take me back to the day you first decided you needed to find a solution for [problem space]. What was happening?"
- "When did you first realize that your old way of doing things wasn't working anymore? What was the trigger?"
2. Exploring the Struggle:
- "What was the most frustrating part about that situation?"
- "What else did you try to solve this problem before you found a real solution? What did you like or dislike about those attempts?"
3. Mapping the Timeline:
- "After you started looking for a solution, what were the next steps you took?"
- "Who else was involved in making this decision? What were their concerns?"
4. Uncovering the Forces:
- "What was the biggest concern or anxiety you had about switching to a new solution?"
- "What was the moment you thought, 'Okay, this new way is actually going to work for me'?"
By focusing on these narrative prompts, you get past surface-level feedback. You unearth the rich, contextual data needed to define a clear, actionable Job Story—the true foundation for building products customers will eagerly hire.
Translating Research into an Actionable Job Story
You've finished your JTBD interviews. Now what? You're sitting on a goldmine of customer stories, frustrations, and goals. This is the moment where many teams stumble—turning all that rich, messy, qualitative data into something clear and actionable for your product strategy.
This is exactly where the Job Story comes in. It's your most powerful tool for bridging that gap.
A Job Story is a simple, elegant way to capture the core job your customer is trying to do. It pulls the focus away from fuzzy personas and anchors your entire team in the real-world context and desired outcome of your customer.
This format forces you to be crystal clear. It's the connective tissue between discovery and delivery, ensuring every feature on your roadmap is tied directly back to a real customer struggle.
How Job Stories Are Different From User Stories
If you’re a PM, you’re probably very familiar with the classic User Story format: "As a [type of user], I want to [action], so that [benefit]." It's a useful tool, but it has one major flaw: it starts with a persona. This often leads teams to build features based on assumptions about a group, not the specific circumstance driving the need.
Job Stories are different. They intentionally leave out the persona. Instead, they focus entirely on the situation that triggers the need and the outcome the person is trying to achieve. It’s a subtle shift, but it’s profound. It stops your team from jumping to solutions too early and keeps everyone focused on the actual problem.
Key Takeaway: A User Story describes an action. A Job Story describes progress. That distinction is the difference between just building another feature and actually solving a customer's problem.
For PMs looking to really level up, understanding this is critical. It's worth exploring a deeper dive into writing a great user story to see how the two formats can work together once you've nailed down the core job.
The Job Story Template and Real-World Examples
The magic of the Job Story is its simple, repeatable structure. It forces you to define the situation, the motivation, and the expected outcome—the three essential ingredients of any job to be done.
Here's the template:
When [Situation] , I want to [Motivation] , so I can [Expected Outcome] .
Let’s see it in action. We'll take a vague, unhelpful user story and transform it into a powerful Job Story.
- Vague User Story: "As a sales manager, I want a better dashboard."
- Actionable Job Story: "When I'm preparing for my weekly team meeting, I want to see which deals are at risk of slipping, so I can proactively coach my reps on the highest-impact opportunities."
See the difference? The Job Story has zero mention of charts, graphs, or UI. Instead, it gives the design and engineering teams a crystal-clear picture of the problem they need to solve. This unleashes their creativity to build the best solution, not just the most obvious one.
Here are a few more examples from different industries:
- SaaS (Project Management): "When a new project is assigned to my team, I want to quickly assign tasks and set deadlines, so I can ensure everyone knows their responsibilities from day one."
- Consumer Tech (Fitness App): "When I finish a workout, I want to log my activity in under 30 seconds, so I can get on with my day without losing momentum."
Prioritizing Jobs to Build Your Roadmap
Okay, so you have a collection of well-defined Job Stories. Great. But not all jobs are created equal. The next step is to figure out which ones to tackle first. Two of the most effective ways to prioritize are by looking at customer struggle and market opportunity.
- Customer Struggle: How much pain is the customer really in? Is their current workaround a minor annoyance or a major bottleneck that costs them time and money? Jobs with a high degree of struggle are ripe for innovation.
- Market Opportunity: How many people are dealing with this? Is it a niche problem for a handful of power users, or is it a widespread issue affecting a huge chunk of your target market?
By mapping your Job Stories on a simple matrix of Struggle vs. Opportunity, you can move from a messy backlog of ideas to a strategic, evidence-backed roadmap. This ensures you’re not just solving any problem—you're solving the right problems that will drive real growth for the business.
Applying JTBD to Drive Product Strategy and Innovation
So, you've done the interviews and understand your customer's job. That's a huge step. But the real magic happens when you translate those insights into a product strategy that actually drives the business forward. This is what separates the top-tier PMs from the rest.
Jobs to be Done isn't just a research method; it's a powerful engine for growth. It’s how you move from just knowing the problem to systematically building the solution that wins.
The bridge from research to strategy is a quantitative methodology called Outcome-Driven Innovation (ODI). Think of ODI as a way to turn the desired outcomes you’ve identified into measurable KPIs. This lets you rank and prioritize them based on what customers find important versus how satisfied they are today. Suddenly, that messy qualitative data snaps into a clear, defensible roadmap.
Building an Opportunity Landscape
The core output of ODI is an Opportunity Landscape. It’s a simple but powerful visual map. On it, you plot every customer outcome, revealing exactly where your product is over-serving, under-serving, or completely missing the mark.
For any senior PM or product leader, this tool is gold. It pulls the guesswork and endless stakeholder debates out of your roadmap meetings. In their place, you have data-backed evidence showing the biggest opportunities for growth.
By spotting clusters of outcomes that are both highly important and poorly satisfied, you can pinpoint exactly where to focus your team's precious time and resources for the biggest impact. This is how you find your wedge into a crowded market or defend your spot against newcomers. Our guide on building a strong product strategy framework can help you plug these insights right into your bigger-picture planning.
This quantitative approach isn't just theory—it has a proven track record.
Take the job of "cutting wood in a straight line" for tradespeople. An ODI analysis uncovered a 30% market segment with 14 distinct unmet outcomes, from minimizing blade wander to reducing splintering. A circular saw redesigned specifically to nail these outcomes went on to dominate the market.
This data-driven process is especially crucial in complex markets like healthcare, where missing the true customer need is a key reason why a staggering 86% of new launches fail. You can dig deeper into how ODI quantifies market needs on gopractice.io.
Key Takeaway: An Opportunity Landscape doesn't just show you what to build next. It shows you which customer problems are most valuable to solve, giving you a clear, data-driven justification for your entire product strategy.
Ultimately, applying JTBD at a strategic level elevates you from a feature manager to a genuine business driver. It provides a repeatable system for finding underserved needs, sizing up market opportunities, and building products that people don't just use, but eagerly hire to make progress in their lives. This is the path to sustainable product-market fit.
Integrating JTBD With AI For Smarter Product Decisions
Think of the Jobs to be Done framework as a detailed map of your customer's world. It shows you their motivations, their struggles, and where they want to go. Now, what if you had an intelligent assistant who could read that map faster and more accurately than you ever could alone?
That’s exactly what happens when you weave AI into your JTBD workflow.
For today's Product Manager, AI isn't here to replace your strategic thinking. It’s here to supercharge it. Tools like ChatGPT and Claude can tear through mountains of qualitative data—interview transcripts, support tickets, app store reviews—and pull out the core JTBD components with stunning speed.
This shift means you spend less time bogged down in manual synthesis and more time focused on strategic action. Instead of losing days sifting through notes, you can pinpoint the core job, the struggling moment, and the desired outcomes in a matter of minutes.
Supercharging Interview Analysis With AI
Customer interviews are a goldmine, but analyzing hours of transcripts is a tedious slog that’s often riddled with personal bias. AI can act as your tireless research assistant, spotting patterns and synthesizing insights using structured, repeatable prompts.
The trick is to be specific. Don't just ask an AI to "summarize" a conversation. Treat it like a junior product strategist. Give it a clear role and a JTBD-focused lens to look through.
Here’s a powerful, copy-paste-ready prompt I use with ChatGPT 4 or Claude 3 to break down interview transcripts:
Act as a senior product strategist specializing in the Jobs to be Done framework. I am providing you with a customer interview transcript. Your task is to analyze it and provide a structured breakdown.
Please extract the following components based only on the information in the transcript:
- The Core Job: What is the primary progress this person is trying to make?
- The Struggling Moment: Identify the specific trigger or event that caused them to seek a new solution.
- The Forces of Progress: List the Pushes, Pulls, Anxieties, and Habits you can identify.
- Desired Outcomes: Create a list of 5-7 solution-agnostic outcome statements (e.g., "Minimize the time it takes to…") that the customer uses to measure success.
Here is the transcript:
[Paste your full interview transcript here]
This simple prompt turns a wall of text into an organized, actionable analysis, giving you the perfect foundation for crafting clear Job Stories.
From Raw Notes To Refined Job Stories
AI also shines as a partner in the creative process of writing and refining Job Stories. Once you've extracted the core components from your analysis, you can feed them right back into the AI to help draft concise statements that your whole team can rally around.
This back-and-forth helps strip out ambiguity and ensures your Job Stories are consistently formatted and laser-focused on the situation, motivation, and outcome. For a deeper dive into how AI is reshaping the PM role, check out our guide on AI in Product Management.
Try this follow-up prompt to take it a step further:
- Prompt: "Using the JTBD analysis you just created, generate three distinct Job Stories in the format: 'When [Situation], I want to [Motivation], so I can [Expected Outcome].' Ensure each story focuses on a different angle of the core job."
This technique doesn't just save time; it pushes you to explore different facets of the customer's problem. You can even run a competitive analysis through a JTBD lens by feeding the AI a competitor's customer reviews and asking it to identify the jobs those customers are hiring that product for.
By combining the deep human empathy of JTBD with the analytical speed of AI, you gain a massive edge in building products that people truly need.
Common Questions About The Jobs To Be Done Framework
Even after getting the core concepts down, product managers I talk to still have questions when it’s time to actually put the Jobs to be Done framework into practice. It’s one thing to understand the theory, but another to use it confidently.
Let's clear up some of the most common hurdles.
How Is Jobs To Be Done Different From Personas?
This is probably the question I hear the most. It's a good one.
Personas try to describe who the user is. Think "Marketing Mary, 35, lives in the suburbs." It’s all about demographic and psychographic traits. Jobs to be Done, on the other hand, zeroes in on why a user acts—the specific situation, their underlying motivation, and what they're trying to achieve.
The big difference? JTBD is way more stable. While a person's attributes change over time, the core "job" they need to get done often stays the same. For example, the job of "prepare a healthy meal for my family quickly" has been around for decades.
This makes JTBD a much more reliable foundation for innovation. You're building for a timeless, specific struggle, not a fictional character sketch that might be irrelevant next year.
Can I Use JTBD For An Existing Product?
Absolutely. JTBD is incredibly powerful for both new and existing products, though you'll use it in slightly different ways.
For brand-new products, it's your best tool for finding unmet needs and killing bad ideas before you spend a dime on development. It's all about de-risking the concept.
For products already in the market, JTBD becomes a killer tool for optimization and growth. By running JTBD interviews with your current customers, you can pinpoint the exact moment they decided to "hire" your product. You'll uncover what progress they're actually making and, more importantly, where they still get stuck. This kind of insight is gold—it can directly point you to your next big feature or a simple tweak to onboarding that slashes churn.
How Many Customer Interviews Do I Need To Find The Job?
There isn't a magic number, but you'll be surprised how quickly patterns emerge. You can often see the core job taking shape after just 5-10 solid interviews, provided they are laser-focused on a specific "hiring" moment (the moment of purchase or adoption).
The goal here isn’t statistical significance. You’re not running a survey. You're digging for deep, qualitative insights.
The rule of thumb is to keep interviewing until you hit saturation—that point where you can reliably predict what the next customer is going to say. A great way to start is with a batch of five interviews. Then, pause and assess. Do you have a clear, consistent story of the job and the forces at play? If not, do a few more.
At Aakash Gupta, my goal is to give you the frameworks, insights, and career guidance you need to become a top-tier product leader. For more actionable advice from an experienced PM leader delivered right to your inbox, check out my newsletter at https://www.aakashg.com.
