Jobs-to-be-Done (JTBD) Framework: A Product Manager's Complete Guide
Jobs-to-be-Done (JTBD) is a framework that reframes product decisions around the underlying task a customer is trying to accomplish, not the product itself. A product manager uses JTBD to uncover the functional job, map each step of that job, write measurable desired outcome statements, and identify where current solutions fall short. This reveals precisely where new features or products will create the most value.
Overview
Most product teams organize their work around features, personas, or competitor benchmarks. The Jobs-to-be-Done framework asks a different question entirely: what is the customer actually trying to accomplish, and how well are existing solutions helping them do it? That shift in framing, from "what should we build" to "what job is the customer hiring a product to do," is the core intellectual move behind JTBD. It sounds simple, but it restructures nearly every downstream decision a product manager makes, from roadmap prioritization to competitive analysis to market segmentation.
The framework's modern form traces primarily to Tony Ulwick, who began developing what he calls Outcome-Driven Innovation (ODI) in the early 1990s while consulting for companies like Cordis Corporation and Microsoft. Ulwick published his foundational ideas in a 2002 Harvard Business Review article titled "Turn Customer Input into Innovation," and later expanded them into the book "What Customers Want" (2005). Clayton Christensen, the Harvard Business School professor best known for disruption theory, popularized a complementary version of JTBD through his "milkshake marketing" example and the book "Competing Against Luck" (2016). The two schools share a core premise, customers "hire" products to get jobs done, but differ in emphasis. Ulwick's ODI tradition is quantitative and process-heavy, centered on desired outcome statements and opportunity scoring. Christensen's tradition is more narrative and qualitative, focused on the broader context of why customers switch between solutions. A working product manager benefits from understanding both lineages, because the quantitative and qualitative lenses complement each other in practice.
The mental model underneath JTBD is that jobs are stable even when products change rapidly. People have been "trying to pass time during a commute" for centuries. The horse, the newspaper, the Walkman, the smartphone, and the podcast all got hired for overlapping versions of that job. When a product manager anchors strategy to the job rather than the current product category, they gain two advantages. First, they see competitive threats that category-level thinking misses, because competition is defined by the job, not the shelf. Second, they can identify unmet needs with much greater precision, because the job can be decomposed into discrete steps, and each step can be evaluated against measurable outcomes the customer cares about.
JTBD sits in a broader landscape alongside frameworks like Design Thinking, Lean Startup, and Kano analysis. Design Thinking shares JTBD's empathy orientation but tends to be more divergent and less structured in how it captures needs. Lean Startup's build-measure-learn loop is a complementary execution method, but it assumes you already know the problem space well enough to form a hypothesis. Kano analysis classifies features by satisfaction impact, but it starts from features rather than from the customer's job. JTBD is distinguished by its insistence on decomposing the job into steps and outcomes before any solution ideation begins. This discipline prevents the premature convergence that plagues many product teams.
Since its introduction, JTBD has evolved significantly. Ulwick's ODI methodology has been applied across more than 1,000 innovation projects and refined into a detailed quantitative process, complete with opportunity algorithms and market segmentation by unmet need. Meanwhile, practitioners like Bob Moesta (Ulwick's former collaborator and co-architect of many early JTBD concepts) have developed "demand-side" JTBD interview techniques that focus on the switching moment, the push, pull, anxiety, and habit forces that cause a customer to hire or fire a product. The framework has also been adopted heavily in B2B SaaS, where product managers use job maps and outcome statements to structure discovery, align cross-functional teams, and defend roadmap decisions with evidence rather than opinion.
The product manager who benefits most from JTBD is one operating in a complex, multi-segment market where customer needs are poorly understood or where the team keeps shipping features that don't move adoption metrics. If your team regularly debates whether to build feature X or feature Y without a shared language for "what does the customer actually need," JTBD provides that language. It is especially powerful for teams at the growth stage, where the initial product-market fit is proven but the path to expanding into adjacent segments or deepening value in the core segment is unclear. Hamster is one workspace where teams can run JTBD-informed discovery alongside their AI agents, keeping job maps, outcome statements, and opportunity scores connected to the rest of their product workflow.
How It Works
Step 1: Define the Core Functional Job
Start by articulating the core functional job the customer is trying to accomplish, written from the customer's perspective and stripped of any solution language. A well-defined job statement follows the format: verb + object + contextual clarifier. " The job should be neither so broad that it becomes meaningless ("live a good life") nor so narrow that it describes a step within a larger job ("enter a transaction into a ledger"). A good test is stability: would this job have existed 20 years ago and will it exist 20 years from now? If yes, you're at the right level of abstraction. A common mistake is embedding a solution in the job statement. "Create a spreadsheet to track expenses" is a solution, not a job. " Getting this definition right is foundational because every subsequent step depends on it. For a detailed walkthrough, see [Defining the Customer's Core Functional Job](/skills/defining-core-functional-jobs).
Step 2: Map the Job into Steps
Decompose the core functional job into a sequence of discrete process steps. Ulwick's canonical job map uses a universal structure: define, locate, prepare, confirm, execute, monitor, modify, and conclude. Not every job includes all eight steps, but this structure provides a scaffold for ensuring completeness. Each step should describe what the customer is doing, not what the product is doing. " The goal is to produce a comprehensive map of the entire job before any consideration of solutions. " Watch out for merging distinct steps into one, which hides important outcome distinctions. Also watch for including steps that belong to an adjacent job rather than the core job you defined. For more on this step, see [Creating Job Maps to Visualize Customer Processes](/skills/creating-job-maps).
Step 3: Write Desired Outcome Statements for Each Step
For each step in the job map, write 5 to 15 desired outcome statements that describe the metrics the customer uses to judge success. Each statement follows a precise format: direction of improvement (minimize, increase) + unit of measurement (time, likelihood, number) + object of control (what's being measured) + contextual clarifier (when or where). " Precision is the point. Vague outcomes like "make it easier to find ingredients" give your team no actionable information. A well-written set of outcomes for a single job typically produces 80 to 150 statements across all steps. This volume feels excessive at first but is critical for the quantitative analysis that follows. Common mistakes include writing outcome statements that describe solutions ("have a checklist feature"), mixing multiple outcomes into one statement, or using subjective language that can't be measured. See [Writing Desired Outcome Statements](/skills/writing-desired-outcome-statements) for templates and common patterns.
Step 4: Conduct Customer Research to Validate and Score Outcomes
With your draft job map and outcome statements in hand, conduct structured interviews with 15 to 30 customers to validate the job steps and refine the outcome language. ). Both scales typically use a 1-to-5 or 1-to-10 range. You need a statistically meaningful sample, usually 180 or more respondents for B2B and larger for B2C. The qualitative interviews reveal whether your job map is complete and whether your outcome statements use the customer's language. The quantitative survey produces the data you need for opportunity scoring. A frequent mistake is skipping the quantitative step and relying solely on interviews. Interviews reveal the landscape but cannot tell you reliably which outcomes are most underserved at scale. For interview techniques and guide templates, see [Conducting JTBD Customer Interviews](/skills/conducting-jtbd-customer-interviews).
Step 5: Calculate Opportunity Scores and Identify Underserved Outcomes
Apply the opportunity algorithm to each outcome: opportunity score = importance + max(importance - satisfaction, 0). Outcomes with scores above 10 (on a 10-point scale) represent underserved needs, the areas where customers care deeply but current solutions fall short. Outcomes with low importance, regardless of satisfaction, are table stakes or irrelevant. Sort all outcomes by opportunity score. The top 10 to 15 represent your highest-leverage innovation targets. Visualize the results on an opportunity landscape (importance on one axis, satisfaction on the other) to see clusters. Watch for outcomes that score high on both importance and satisfaction. These are "appropriately served" and adding more value here yields diminishing returns, a trap many product teams fall into by over-investing in their strongest features. For detailed scoring techniques, see [Identifying Underserved Outcome Opportunities](/skills/identifying-underserved-outcome-opportunities).
Step 6: Segment Customers by Patterns of Unmet Need
Run cluster analysis on the survey data to identify groups of customers who share similar patterns of underserved outcomes. You'll typically find 3 to 6 meaningful segments. Unlike demographic segments, these need-based segments often cut across traditional categories. You might discover that mid-market marketing directors and enterprise operations managers share nearly identical unmet outcomes on a particular job step, while two marketing directors at similar companies have completely different need profiles. Label each segment descriptively based on its dominant unmet needs. This segmentation directly informs product strategy: you can now decide which segment to target first, knowing exactly which outcomes to address and how large each opportunity is. The mistake to avoid is forcing the data into your existing persona framework. Let the clusters emerge from the data. For clustering techniques, see [Segmenting Customers by Unmet Needs](/skills/segmenting-customers-by-unmet-needs).
Step 7: Translate JTBD Insights into Product Strategy and Roadmap
With underserved outcomes identified and segments defined, translate findings into concrete product strategy decisions. For each high-opportunity outcome, brainstorm solution concepts that could address it. Evaluate each concept against the full set of underserved outcomes to find solutions with the broadest impact. A single feature that addresses three high-scoring outcomes is almost always more valuable than three features that each address one. Feed these priorities into your roadmap, using the opportunity scores as evidence in stakeholder conversations. This is where JTBD pays its biggest dividend: roadmap debates shift from opinion-based to evidence-based. Instead of arguing whether to build feature A or feature B, the team can reference quantified customer needs. A common failure mode is completing the JTBD research but then reverting to old prioritization habits because the organization's planning process doesn't accommodate outcome-driven input. Embedding JTBD artifacts into your existing planning cadence is essential. For integration patterns, see [Applying JTBD Insights to Product Strategy and Roadmaps](/skills/applying-jtbd-to-product-strategy).
When to Use
- When your team has 20 or more competing feature requests from different customer segments and no shared vocabulary for comparing them. JTBD gives you a common unit of analysis, the desired outcome, that lets you evaluate requests on equal footing rather than defaulting to the loudest stakeholder or the largest account.
- When you've achieved initial product-market fit but growth has stalled and you suspect you're building for the wrong needs. JTBD's quantitative opportunity scoring reveals whether your roadmap aligns with the outcomes customers actually care about, or whether you've been optimizing dimensions that are already good enough.
- When entering an adjacent market or launching a new product line and you need to understand what jobs potential customers are hiring current solutions to do. Rather than guessing based on competitor feature sets, JTBD maps the entire job and identifies where current solutions create the most friction.
- When your team is trapped in a cycle of building features that customers requested but that don't move retention or satisfaction metrics after launch. This pattern usually means you're hearing requests at the solution level rather than understanding the underlying outcome. JTBD reframes the conversation around what the customer is actually trying to achieve.
- When you need to align a cross-functional team, engineering, design, marketing, sales, around a shared understanding of the customer. Job maps and desired outcome statements create a concrete, externalized artifact that prevents each function from optimizing for its own interpretation of the customer's need.
- When competitive threats are emerging from outside your traditional product category and you need a broader lens. JTBD's job-level competitive analysis surfaces non-obvious competitors that feature-by-feature benchmarking would miss entirely.
When Not to Use
- When you're a very early stage startup still searching for any repeatable value proposition and you have fewer than 20 customers. JTBD's full methodology, particularly quantitative outcome surveys, requires a large enough customer base to produce statistically meaningful results. At this stage, lightweight qualitative discovery and rapid experimentation will teach you more per unit of effort. You risk over-engineering your research process when you don't yet have the data density to support it.
- When the problem you're solving is a known, well-documented process with a clear regulatory or compliance-driven specification. If the "job" is "file a tax return correctly according to IRS rules," the steps and outcomes are essentially defined by the regulation, not by customer discovery. JTBD adds overhead without revealing non-obvious insights in domains where the job is already exhaustively specified by an external authority.
- When your product operates in a fast-moving, trend-driven market where customer behavior shifts faster than a JTBD study can complete. For example, viral social features or meme-driven consumer apps often succeed based on timing and cultural resonance, not on systematically underserved functional outcomes. JTBD's assumption of stable, enduring jobs doesn't hold well when the "job" is itself ephemeral.
- When the team needs a solution shipped within days or weeks and the job has already been validated through prior research. Running a full JTBD study when you have strong existing evidence of the unmet need is a form of analysis paralysis. JTBD is a discovery framework, not an execution framework. If discovery is done, move to building.
- When you're optimizing an existing, mature feature where the job and outcomes are well understood and the work is primarily about UX polish, performance, or technical debt. JTBD is most valuable when there's genuine uncertainty about what the customer needs. If the need is clear and the challenge is implementation quality, usability testing and engineering metrics are more directly useful.
Examples
Example: B2B SaaS Onboarding Redesign at a 200-Person Company
A project management SaaS company with 3,000 customers noticed that 45% of new accounts became inactive within 30 days. The product team initially assumed the onboarding flow was confusing and planned a UI redesign. " The job map revealed that the critical early step wasn't learning the tool's interface. It was "determine which existing work items and processes need to migrate into the new system," a step where current solutions provided almost no help. 4 out of 20, well above the significance threshold. The team shifted their roadmap away from onboarding UI polish and instead built an import and migration assistant that helped new users audit their existing workflows and bring them into the tool. Within two quarters, 30-day activation rose from 55% to 71%. In retrospect, the team realized they would have spent three months redesigning tooltips and welcome screens that addressed a symptom, not the root cause.
Example: Consumer Fitness App Entering a Saturated Market
A startup building a fitness app faced a market with hundreds of competitors, all offering workout tracking, calorie counting, and social features. Rather than trying to out-feature established players, the three-person team ran a lightweight JTBD study with 18 interviews. " Every existing app assumed users would follow a preset plan. None helped users dynamically adjust when they had 15 minutes instead of 45 or were in a hotel room instead of a gym. The startup built their entire MVP around this single underserved outcome. They couldn't run a full quantitative survey with so few users, so they validated the opportunity through landing page experiments that described the job in the customer's language. 2x, confirming the opportunity before they wrote a line of product code.
Example: Enterprise Healthcare Platform Segmentation
A healthcare data analytics company sold to hospitals and assumed their market had two segments: large academic medical centers and small community hospitals. Their roadmap was split accordingly, with a "premium" feature set for large hospitals and a "lite" set for small ones. " Cluster analysis on the outcome data revealed three segments that had nothing to do with hospital size. Segment A (35% of respondents, found across all hospital sizes) was underserved on outcomes related to data integration, merging quality metrics from disparate EHR systems. Segment B (40%) was underserved on outcomes related to translating data into staff-level action plans. Segment C (25%) was overserved on almost everything, happy power users who didn't need new features. The company realized their "premium vs. lite" strategy had been giving Segment C features it didn't need while neglecting Segment B's core pain point. They reoriented their roadmap around the two underserved segments, reducing feature scope by 30% while increasing relevance. The next year's NPS improved by 18 points in the targeted segments.
Example: Financial Services Platform Team Applying JTBD to Internal Tooling
An internal platform team at a 500-person fintech company was fielding constant complaints from product engineers about the deployment pipeline. " Rather than tackling requests by loudest voice, the platform lead ran a JTBD study treating product engineers as customers. " The backlog requests for faster builds (a "prepare" step outcome) scored high on importance but also high on satisfaction, meaning the current pipeline was already good enough there. The platform team deprioritized build speed work, which had been consuming 40% of their capacity, and instead invested in automated canary deployments and production-mirrored staging environments. Incident rates dropped by 35% in the first quarter, and internal satisfaction surveys showed the platform team's credibility with product engineering reached an all-time high.
Skills in This Method
Conducting JTBD Customer Interviews
How to run switch interviews and timeline interviews that uncover the real jobs, hiring criteria, and switching triggers behind customer decisions.
Identifying Underserved Outcome Opportunities
How to use opportunity scoring (importance vs. satisfaction) to quantify which desired outcomes are most underserved and represent the best innovation targets.
Applying JTBD Insights to Product Strategy and Roadmaps
How to translate job maps, outcome scores, and opportunity landscapes into actionable product roadmaps, feature priorities, and go-to-market positioning.
Defining the Customer's Core Functional Job
How to identify and articulate the fundamental job a customer is trying to accomplish, using proper job statement syntax and structure.
Writing Desired Outcome Statements
How to craft properly structured outcome statements (direction + metric + object of control + context) that capture measurable customer success criteria at each job step.
Creating Job Maps to Visualize Customer Processes
How to break down a core functional job into its universal process steps (define, locate, prepare, confirm, execute, monitor, modify, conclude) to map the full customer journey.
Segmenting Customers by Unmet Needs
How to create outcome-based customer segments that group people by shared underserved outcomes rather than demographics, enabling more targeted product strategies.