Jobs to Be Done (JTBD)

Definition

Jobs to Be Done (JTBD) is a theory popularized by Clayton Christensen asserting that customers "hire" products to accomplish specific jobs in their lives. A job is defined by the progress a person is trying to make in a particular circumstance, not by demographics or product features. PMs use JTBD to reframe competitive analysis, uncover hidden demand, and design solutions anchored in real motivations rather than assumed preferences.

The framework has two major branches. Christensen's "Jobs-as-Progress" school focuses on the circumstances and motivations behind switching behavior. Tony Ulwick's Outcome-Driven Innovation (ODI) provides a quantitative methodology for identifying underserved outcomes within a job. Both are useful. The right choice depends on whether you need qualitative insight into why customers switch or quantitative data on where to improve.

The Product Discovery Handbook covers how to run JTBD interviews as part of continuous discovery. The JTBD Builder helps teams structure job statements interactively. The complete guide to product discovery covers the broader research context.

Why It Matters for Product Managers

JTBD changes how you think about three fundamental product questions: what to build, who you compete with, and how to position your product.

What to build. Feature requests tell you what customers think they want. JTBD tells you what they are actually trying to accomplish. A customer might request "add a Gantt chart view." The job behind the request might be "show my exec team that our timeline accounts for dependencies in a format they can scan in under 30 seconds." That job could be solved by a Gantt chart, a timeline view, a status dashboard, or a 1-page summary. JTBD opens the solution space instead of anchoring you to the first solution the customer names.

Who you compete with. Traditional competitive analysis looks at products in the same category. JTBD reveals the full competitive set: everything the customer currently hires to get the job done, including spreadsheets, manual processes, internal tools, and doing nothing. When Slack launched, its competition was not other chat apps. It was email threads, hallway conversations, and meetings. Understanding the true competitive set changes your positioning, pricing, and go-to-market strategy.

How to position. Products positioned around features ("We have 47 chart types") attract comparison shoppers who evaluate on specs. Products positioned around jobs ("Show your stakeholders exactly where the project stands in 10 seconds") attract buyers who recognize the situation and care about the outcome. Job-based positioning resonates because it mirrors the language customers use internally when deciding to buy.

The Milkshake Story: JTBD in 60 Seconds

The most famous JTBD example comes from Christensen's consulting work with a fast-food chain trying to sell more milkshakes. Traditional market research segmented customers by demographics (age, income) and ran focus groups asking "How can we improve the milkshake?" Results were inconclusive.

The JTBD team took a different approach. They stood in the restaurant and watched who bought milkshakes, when, and what they did with them. They discovered two distinct jobs:

Job 1: Morning commuters. Nearly half of milkshakes were sold before 8:30 AM to solo drivers. These customers needed something to make a long, boring commute more interesting while keeping one hand free. The milkshake's thickness (takes 20 minutes to finish through a straw) was a feature, not a flaw. The competition was not other milkshakes. It was bagels, bananas, and boredom.

Job 2: Afternoon parents. Parents bought milkshakes for their kids after school as a treat. For this job, the thick milkshake was too slow (kids got frustrated), too large (dinner was coming), and too messy. The competition was ice cream, cookies, and saying "no."

Same product, two completely different jobs, two different competitive sets, two different improvement paths. Demographics told the team nothing useful. The job told them everything.

This is the core insight of JTBD: customers do not buy products. They hire them to make progress in specific situations. Understanding the situation and the desired progress reveals opportunities that product-centric thinking misses entirely.

The JTBD Statement Format

A well-formed JTBD statement captures three elements: the situation (trigger context), the motivation (what the person wants to accomplish), and the desired outcome (the end state they are trying to reach).

Format. "When [situation], I want to [motivation], so I can [expected outcome]."

Examples:

• "When I have 15 minutes between meetings, I want to review my team's sprint progress, so I can prepare informed questions for our standup."
• "When a customer escalation lands in my inbox, I want to quickly see their full account history, so I can respond with context instead of asking them to repeat themselves."
• "When I'm preparing a board presentation, I want to visualize our roadmap against strategic themes, so I can show the board we're investing in the right areas."

The situation is the most underrated element. The same person in different situations has different jobs. A PM reviewing sprint progress at their desk has a different job than a PM reviewing sprint progress while walking to a meeting on their phone. The situation shapes the constraints, which shapes the solution.

Use the JTBD Builder to structure and refine job statements with your team.

JTBD vs. Personas: Complementary, Not Competing

A common misconception is that JTBD replaces personas. It does not. The two frameworks answer different questions and work best together.

The strongest teams use both. Personas tell you who your users are and what their world looks like. JTBD tells you what they are trying to accomplish in specific moments and what they would hire your product to do. A persona document might describe "Sarah, a Series B PM with 3 engineers." A JTBD statement for Sarah might be "When I need to justify a roadmap change to my CEO, I want a one-page visual that shows strategic alignment, so I can get approval without a 30-minute meeting."

Conducting JTBD Interviews: 5 Key Questions

JTBD interviews are different from standard user interviews. Instead of asking about the product, you ask about the circumstances around the decision to start (or stop) using a product. The goal is to reconstruct the "timeline" of the job.

1. "When did you first realize you needed something to help with [job]?"

This surfaces the first thought, the trigger event. Was it a specific frustration, a conversation, a business change? The trigger reveals when the job becomes urgent enough to act on.

2. "What were you using before? How did you solve this problem before you found [product]?"

This uncovers the actual competitive set, which is almost never what you expect. For a project management tool, the competition might be spreadsheets, Slack threads, or ignoring the problem entirely.

3. "What made you start looking for something different?"

This reveals the "push" away from the current solution. The push is usually not a missing feature. It is a situation where the current solution failed badly enough to justify the switching cost.

4. "What almost stopped you from switching?"

This surfaces the anxieties and frictions that block adoption. Fear of data migration, learning curves, team resistance, contractual lock-in. Understanding these barriers is as important as understanding the appeal.

5. "When you first used [product], what was the moment you knew it was working for you?"

This identifies the "aha moment." The specific experience where the user felt the new product doing the job better than the old solution. This moment should be the focus of your onboarding design.

Interview 10-15 recent customers (both new signups and recent churns) to build a reliable job map. The Product Discovery Handbook covers the full interview methodology, including how to recruit participants and analyze transcripts.

Outcome-Driven Innovation (ODI)

Tony Ulwick's ODI method turns JTBD from a qualitative lens into a quantitative prioritization engine. The process works in four steps.

Step 1: Define the core job. Map the functional job the customer is trying to do, broken into steps. For example, the job "prepare a quarterly product roadmap" breaks into: gather inputs, identify themes, estimate effort, sequence items, communicate the plan.

Step 2: Identify desired outcomes. For each step, list 10-20 desired outcomes in the format: "Minimize the time it takes to [action]" or "Minimize the likelihood of [negative outcome]." Example: "Minimize the time it takes to gather stakeholder input for roadmap planning."

Step 3: Survey to find importance and satisfaction. Ask a large sample (100+) to rate each outcome on two scales: how important is this outcome (1-5), and how satisfied are you with current solutions for this outcome (1-5).

Step 4: Calculate opportunity scores. The opportunity score formula is: Importance + (Importance - Satisfaction). Outcomes with high importance and low satisfaction are underserved. These are your biggest product opportunities. Outcomes with high importance and high satisfaction are table stakes. Do not cut them, but do not invest heavily. Outcomes with low importance are noise.

ODI is data-heavy but produces prioritization inputs that are directly tied to customer needs. It pairs well with frameworks like RICE at the feature level: ODI identifies the right outcomes to target, and RICE ranks the specific features that address those outcomes. Use the RICE Calculator to score features once ODI has identified the underserved outcomes.

Applying JTBD to Prioritization and Roadmapping

JTBD reframes prioritization conversations from "Which features should we build?" to "Which jobs are we hired to do, and where are we doing them poorly?" This shift has three practical implications.

1. It changes your competitive frame. If you build a project management tool and think your competition is other project management tools, you will optimize for feature parity. If you understand the job ("When I need to coordinate a cross-functional team on a tight deadline, I want a single view of who is doing what and when"), your competition includes spreadsheets, Slack channels, and standing meetings. The solution space expands.

2. It prioritizes by underserved outcomes. Instead of building features because competitors have them, you build features because your customers have unmet needs. ODI opportunity scores give you a numeric basis for these decisions. Features addressing high-opportunity outcomes go to the top of the backlog.

3. It aligns the team around the customer's progress. When a designer, an engineer, and a PM all understand the job the customer is hiring the product to do, they make better independent decisions. The engineer chooses an architecture that supports the job's core workflow. The designer optimizes the flow for the job's most common circumstance. The PM prioritizes the features that move the job from "partially done" to "done well."

For roadmap formats that organize work by customer jobs rather than features or timelines, see the persona roadmap template.

Implementation Checklist

• ☐ Pick one product area or customer segment to apply JTBD to first
• ☐ Conduct 10-15 JTBD interviews with recent customers (new signups + churns)
• ☐ Map 3-5 core jobs your product is hired to do using the "When/I want/So I can" format
• ☐ Identify the actual competitive set for each job (beyond direct product competitors)
• ☐ Use the JTBD Builder to structure and share job statements with the team
• ☐ For each job, list 10-15 desired outcomes and run an importance/satisfaction survey
• ☐ Calculate opportunity scores to identify underserved outcomes
• ☐ Validate the top 3 underserved outcomes with follow-up interviews
• ☐ Feed underserved outcomes into your prioritization framework as impact inputs
• ☐ Share job statements with design and engineering so they inform solution decisions
• ☐ Revisit the job map quarterly as market conditions and customer needs evolve

Common Mistakes

1. Writing jobs that are too broad

"Manage my business" is not a job. It is a life goal. Jobs should be specific enough to inform product decisions. "When I need to update my team on project status without scheduling a meeting" is actionable. Broad jobs produce vague roadmaps.

2. Confusing jobs with solutions

"I want to use a Gantt chart" is a solution preference, not a job. The job behind it might be "When I need to show my executive team that our release timeline accounts for all dependencies, I want a visual format they can understand in under 30 seconds." Dig past the solution to find the progress the person is trying to make.

3. Ignoring the emotional and social dimensions

Jobs have functional, emotional, and social components. A PM hiring a presentation tool has a functional job (create slides), an emotional job (feel confident presenting), and a social job (look competent in front of executives). Products that address all three dimensions are harder to displace.

4. Running too few interviews

JTBD interviews reveal patterns, but only with sufficient sample size. Three interviews might surface one job. Ten interviews surface the top 3-5 jobs with enough detail to act on. Fewer than 8 interviews risks building on anecdotes rather than patterns.

5. Treating JTBD as a one-time exercise

Jobs evolve as markets change, technology shifts, and customer expectations increase. A job map created two years ago may not reflect current circumstances. Revisit JTBD research quarterly and update the job map when new patterns emerge.

Related Concepts

Customer Development is Steve Blank's methodology for validating business hypotheses, which complements JTBD's focus on customer progress. Persona describes who the user is, while JTBD describes what they are trying to accomplish. Use both together. Value Proposition is the promise your product makes to customers. JTBD informs what that promise should be by revealing the job customers are hiring you to do. The Product Discovery Handbook covers the full research workflow, including JTBD interviews, persona development, and opportunity assessment.