Jobs to Be Done (JTBD) Framework: The Complete Guide for Product Teams

Quick Answer (TL;DR)

Jobs to Be Done (JTBD) is a framework that shifts focus from what your product does to what your customer is trying to accomplish. Instead of asking "What features do users want?" you ask "What job is the user hiring our product to do?" Pioneered by Clayton Christensen at Harvard Business School, JTBD reveals the underlying motivations behind customer behavior. A "job" is defined as the progress a person is trying to make in a particular circumstance. When you understand the job, you can build solutions that customers genuinely need -- not just features they say they want.

What Is the Jobs to Be Done Framework?

The Jobs to Be Done framework is a theory of customer behavior rooted in a simple idea: people don't buy products -- they hire products to make progress in their lives. A customer doesn't buy a drill because they want a drill. They don't even buy it because they want a hole. They buy it because they want to hang a shelf, which makes their home more organized, which makes them feel in control.

The theory was developed primarily by Clayton Christensen (The Innovator's Dilemma, Competing Against Luck) and further refined by practitioners like Tony Ulwick (Outcome-Driven Innovation), Bob Moesta (The Jobs to Be Done Playbook), and Alan Klement (When Coffee and Kale Compete).

There are two primary schools of JTBD thinking:

Both approaches are valuable and can be used together. This guide covers both.

The Core Concepts of JTBD

Jobs Are Stable, Solutions Change

The job of "getting from point A to point B quickly" has existed for centuries. The solutions have evolved from horses to trains to cars to rideshares. When you anchor your product strategy to the job rather than the current solution, you become resilient to technological shifts.

Spotify understood this. The job wasn't "buy music" or "download MP3s." The job was "listen to the music I want, when I want, with minimal effort." By focusing on the job, Spotify leapfrogged iTunes rather than trying to be a better music store.

Functional, Emotional, and Social Dimensions

Every job has three dimensions:

Products that address all three dimensions create significantly stronger customer loyalty than those that only address the functional job. Slack succeeded not just because it made team communication faster (functional) but because it reduced email anxiety (emotional) and made teams feel connected and modern (social).

The Forces of Progress

When a customer switches from one solution to another, four forces are at play:

Forces pushing toward a new solution:

Forces pushing against switching:

For a customer to switch, the combined push and pull forces must overcome the combined anxiety and habit forces. Understanding these forces helps you design your product, messaging, and onboarding to tip the balance.

How to Write Job Statements

A well-formed job statement follows a specific structure that keeps the focus on the customer's desired outcome, not your solution.

The Basic Job Statement Formula

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

Examples:

Ulwick's Outcome-Driven Job Statement

Tony Ulwick's approach breaks jobs into more granular steps and measures desired outcomes:

[Direction of improvement] + [unit of measure] + [object of control] + [contextual clarifier]

Examples:

This format is particularly useful for quantitative research -- you can survey users on how important each outcome is and how satisfied they are with current solutions, revealing underserved needs.

JTBD Interview Techniques

The Switch Interview (Moesta Method)

The switch interview is the most powerful JTBD research technique. You interview customers who have recently switched to (or away from) your product and reconstruct their decision timeline.

Structure of a switch interview:

1. First Thought (10 minutes)

2. Passive Looking (10 minutes)

3. Active Looking (10 minutes)

4. Decision and Purchase (10 minutes)

5. Ongoing Use (10 minutes)

Interview Best Practices

Ask about past behavior, not future intentions. "Tell me about the last time you tried to prioritize your backlog" is far more valuable than "Would you use a prioritization tool?"

Follow the energy. When a participant's voice changes, they speed up, they lean forward, or they use emotional language -- that's where the real insight is. Probe deeper: "You mentioned that was really frustrating. Tell me more about that."

Get specific. Push past generalizations. When someone says "I just needed something easier," ask "Can you think of a specific moment when the old tool felt hard? Walk me through exactly what happened."

Don't pitch. The moment you start describing your product's features, the interview becomes a sales call. You're here to learn, not to sell.

Interview 10-12 people. You'll start seeing patterns by interview 5-6. By 10-12, you'll have a solid understanding of the 2-3 primary jobs your product is being hired for.

Real-World JTBD Examples

Airbnb's Job Discovery

When Airbnb analyzed why people used their platform, they discovered multiple jobs:

This insight led Airbnb to invest in "Experiences" (local activities) -- because the job wasn't about lodging, it was about authentic travel.

Slack's Job Understanding

Slack's founding insight was that the job wasn't "send messages to coworkers" (email already did that). The job was:

This multi-dimensional job understanding informed everything from Slack's channel structure to its playful tone to its emoji reactions.

Intercom's Job Mapping

Intercom explicitly uses JTBD to drive product strategy. They discovered that their customers had distinct jobs:

Rather than building one monolithic product, they created separate product modules for each job -- Acquire, Engage, and Support -- each designed around a specific job to be done.

Building a JTBD Job Map

A job map breaks a main job into sequential steps. This is particularly useful for finding innovation opportunities.

The 8-Step Universal Job Map (Ulwick)

Example: The Job of "Managing a Product Roadmap"

Each underserved need in the right column is a potential feature or product opportunity.

Outcome-Driven Innovation (ODI)

Tony Ulwick's Outcome-Driven Innovation process uses JTBD as the foundation for a quantitative innovation methodology:

Step 1: Define the Job

Identify the core functional job the customer is trying to accomplish.

Step 2: Map the Job Steps

Break the job into 8-15 steps using the universal job map.

Step 3: Identify Desired Outcomes

For each step, identify 5-15 desired outcomes using the format: [Direction] + [measure] + [object of control].

Step 4: Survey Customers

For each outcome, ask two questions:

Step 5: Calculate Opportunity Score

Opportunity Score = Importance + max(Importance - Satisfaction, 0)

Scores above 10 indicate underserved needs (high importance, low satisfaction) -- these are your best innovation opportunities.

Scores below 6 indicate overserved needs -- you can potentially simplify or remove features addressing these needs.

Common Mistakes and Pitfalls

1. Defining Jobs Too Broadly

"Get work done" is not a job -- it's a life purpose. Jobs should be specific enough to be actionable but broad enough to be solution-agnostic. "Manage my team's workload so projects ship on time" is a good level of specificity.

2. Confusing Jobs with Solutions

"I need a Gantt chart" is not a job. The job might be "When I'm planning a multi-team project, I want to visualize dependencies between workstreams, so I can identify scheduling conflicts early." A Gantt chart is one possible solution to that job.

3. Ignoring Emotional and Social Jobs

Teams that focus only on functional jobs miss the full picture. Trello succeeded partly because the satisfaction of dragging a card to "Done" (emotional job: feel accomplishment) was as powerful as the organizational utility.

4. Interviewing the Wrong People

For switch interviews, you must talk to people who have recently made a switch -- either to your product or away from it. Interviewing long-time, satisfied customers won't reveal the forces of progress that drive switching behavior.

5. Treating JTBD as a One-Time Exercise

Jobs evolve as circumstances change. Remote work created new jobs that didn't exist before 2020. Revisit your job definitions quarterly and validate that they still reflect reality.

6. Not Connecting Jobs to Product Decisions

JTBD insights are only valuable if they inform decisions. After your interviews, create a clear mapping: Job --> Underserved needs --> Specific feature opportunities --> Prioritized backlog items.

JTBD vs. Other Discovery Frameworks

Best Practices for JTBD Implementation

Start with Switch Interviews

If you're new to JTBD, start with 8-10 switch interviews. They're the fastest path to understanding your customers' jobs. Interview recent customers (signed up in the last 30-90 days) and recent churns.

Create a Job Atlas

Document all the jobs your product serves in a "Job Atlas" -- a living document that maps each job to its functional, emotional, and social dimensions, the current solutions customers use, and the underserved needs you've identified.

Use Jobs to Evaluate Feature Requests

When a customer or stakeholder requests a feature, translate it into a job: "What job would this feature help the customer accomplish?" If you can't articulate the job, the feature request might be a solution looking for a problem.

Map Competitors by Job, Not by Feature

Instead of comparing feature lists with competitors, compare how well each product serves each job. You might discover that your real competitor isn't the product that looks like yours -- it's the spreadsheet, the whiteboard, or the email thread that customers are currently using to get the job done.

Integrate JTBD with Your Roadmap

Structure your roadmap around jobs, not features. Instead of "Q2: Build reporting dashboard," frame it as "Q2: Help managers monitor team progress without manual check-ins." This keeps the team focused on outcomes and allows for creative solutions.

Combine with Opportunity Solution Trees

JTBD pairs powerfully with Teresa Torres' Opportunity Solution Tree. Use JTBD to identify the jobs and underserved needs (opportunities), then use the OST to brainstorm and test solutions for each opportunity.

Getting Started with JTBD

JTBD fundamentally changes how you think about your product. Instead of asking "What features should we build?" you start asking "What progress are our customers trying to make?" That shift in perspective is the foundation of products people love.