What Are Jobs to Be Done? A Primer for Product Leaders

The Question Your Product Team Is Not Asking

Every product team asks some version of “what do customers want?” It is the default question. It drives surveys, focus groups, advisory boards, and roadmap meetings. And it is the wrong question.

Customers do not want products. They want progress. They want to move from a current state — marked by frustration, inefficiency, risk, or dissatisfaction — to a better state. Products are just the means. When your product team focuses on what customers want in a product, they get a list of feature requests filtered through the customer’s limited awareness of what is technically possible. When they focus on what progress customers are trying to make, they get a durable understanding of the market that outlasts any single product generation.

This is the foundational insight of Jobs to Be Done (JTBD). And while the concept sounds simple, its implications for how you build products, segment markets, define competition, and prioritize R&D investment are profound.

This article is a working introduction to JTBD for senior product managers and VPs who need to decide whether — and how — to adopt the framework. For the comprehensive treatment, see our Complete Guide to Jobs to Be Done.

The Origin Story, Retold Honestly

You have probably heard the milkshake example. Clayton Christensen and his colleagues studied a fast-food chain trying to improve milkshake sales. Traditional market research — asking customers what they wanted in a milkshake (thicker? more chocolate? cheaper?) — produced incremental changes that did not move sales. When the team instead studied what job customers were hiring the milkshake to do, they discovered that morning commuters were hiring it as a convenient, engaging breakfast companion for a boring drive.

It is a great story. It is also from 2005, and it has been retold so many times that it has become a cliche that obscures the deeper point.

Here is what the milkshake story actually teaches, and what most retellings miss:

The milkshake was competing with bananas, bagels, and boredom — not with other milkshakes. The competitive frame shifted entirely when the team moved from a product lens (milkshake vs. milkshake) to a job lens (morning sustenance + engagement vs. all alternatives). This reframing is the operational power of JTBD. It does not just help you understand what customers want. It redefines who your competitors are.

Now apply this to industrial markets. A loader crane manufacturer thinks its competition is other loader crane manufacturers. But from the operator’s perspective, the job is “move heavy materials from ground level to an elevated work position on a construction site.” The competition includes telehandlers, boom lifts, and even manual labor with block and tackle. When you see competition through the job lens, you find opportunities that product-centric thinking misses entirely.

What Exactly Is a “Job”?

A job is a goal that a person or organization is trying to achieve in a specific circumstance. In Tony Ulwick’s Outcome-Driven Innovation (ODI) framework — the quantitative methodology that operationalizes JTBD — a job is defined as a process: a series of steps someone goes through to accomplish a goal.

Three properties distinguish a well-defined job:

1. Jobs Are Solution-Agnostic

A job statement never references a specific product, technology, or solution. “Use our software to track project milestones” is not a job — it embeds a solution. “Track project milestones across teams and timelines” is a job. The distinction matters because solution-agnostic job statements open the innovation space. They allow you to consider solutions that your current product category might not encompass.

2. Jobs Are Stable Over Time

The job of “restoring blood flow to a blocked coronary artery” has existed since the first human had a heart attack. What has changed, dramatically, is how we accomplish it: from nothing, to open-heart surgery, to balloon angioplasty, to drug-eluting stents, to bioresorbable scaffolds. A product strategy anchored to the job rather than the current product generation is inherently more durable.

3. Jobs Have Measurable Outcomes

This is Ulwick’s critical contribution, and it separates ODI from vaguer applications of JTBD. At each step of the job, customers have desired outcomes — specific, measurable criteria they use to judge success. These outcomes follow a strict syntax: [direction of improvement] + [metric] + [object of control] + [contextual clarifier].

For example: “Minimize the time it takes to confirm that the equipment is properly calibrated before use.” This is not a feature request. It is a measurable statement of what matters to the customer. When you survey 300 customers on the importance and satisfaction of 120 such outcomes, you get a quantitative map of opportunity.

The Three Job Dimensions

Every job has functional, emotional, and social dimensions. Most product teams address only the functional dimension and wonder why customers choose competitors with inferior specs.

Functional jobs are the practical tasks: cut, assemble, monitor, transport, diagnose. They are what engineers focus on, and they are necessary but not sufficient.

Emotional jobs are about how the person wants to feel: confident, in control, relieved, unworried. A field technician using a diagnostic device has a functional job (identify the fault) and emotional jobs (feel confident the diagnosis is correct, avoid the embarrassment of a misdiagnosis in front of the customer).

Social jobs are about how the person wants to be perceived: competent, forward-thinking, reliable. The VP who champions a new manufacturing system is not just buying throughput. She is buying professional credibility.

In our work with MedTech and industrial clients, we consistently find that 30-40% of the highest-opportunity outcomes relate to emotional and social dimensions. Companies that address only functional needs leave significant value on the table. We explore this in depth in Functional, Emotional, and Social Jobs: Understanding the Full Picture.

I have seen technically superior products lose to inferior ones because the winning product addressed the emotional and social jobs that the market research never captured. In B2B, we have this bias that decisions are purely rational. They are not. They are made by humans with careers, reputations, and anxieties.

Why JTBD Changes Product Management

1. It Redefines Your Market

When you define your market as the job rather than the product, your addressable market often expands dramatically. A company making enteral feeding pumps that defines its market as “enteral feeding pumps” sees a $2B market. The same company defining its market as “deliver precise nutritional support to patients who cannot eat orally” sees adjacent opportunities in monitoring, formula optimization, and patient compliance — a much larger space.

2. It Replaces Opinions with Data

The most contentious meetings in product management are prioritization debates. Everyone has a favorite feature. Everyone has an anecdote about a customer who “really needs” something. JTBD/ODI replaces these debates with quantified opportunity scores. When you can show that 78% of customers rate “minimize the time to switch between feeding modes” as highly important and only 23% are satisfied with current solutions, the prioritization argument becomes straightforward.

3. It Reveals Hidden Segments

Traditional segmentation — by industry, company size, geography, job title — assumes that customers who look alike have similar needs. JTBD segmentation groups customers by patterns of unmet needs. Two surgeons at the same hospital, with the same specialty, may have radically different patterns of underserved outcomes. One may be underserved on speed-related outcomes. The other may be underserved on precision-related outcomes. These are different segments that need different product configurations or messaging.

This is why personas often fail as segmentation tools — they group by surface attributes rather than by actual need patterns.

4. It Creates Durable Strategy

Because jobs are stable, a product strategy built around the job map and its outcomes survives technology transitions. When your strategy says “we help construction site managers minimize the time to confirm that heavy loads are properly secured before vertical transport,” that strategy is valid whether the solution is a hydraulic crane, an electric crane, or a drone. The product changes. The strategy holds.

How JTBD Works in Practice

Here is the practical sequence, stripped of jargon:

Step 1: Define the job. Work with your product team to articulate the job your customer is hiring your product to do. Use the syntax: verb + object + contextual clarifier. Keep it solution-agnostic.

Step 2: Map the job. Break the job into its process steps using the Universal Job Map (Define, Locate, Prepare, Confirm, Execute, Monitor, Modify, Conclude). This gives you the structure to identify outcomes at every stage, not just the core execution.

Step 3: Capture desired outcomes. Through qualitative interviews with 15-30 customers, identify the 50–150 outcomes customers use to measure success at each stage of the job. These interviews follow a specific protocol — see our JTBD interview guide for the complete process and question set.

Step 4: Quantify. Survey a representative sample (200-600 respondents) on each outcome: how important is it, and how satisfied are you with current solutions? Calculate opportunity scores.

Step 5: Segment and strategize. Cluster customers by patterns of unmet needs. Develop product concepts that address the most underserved outcomes in the most attractive segments.

This is the Outcome-Driven Innovation (ODI) process, developed by Tony Ulwick. MYLES, brings this methodology to industrial, MedTech, and B2B product teams. For the full methodology, see our Complete Guide to JTBD.

What JTBD Is Not

Clarifications for common misconceptions:

JTBD is not user story mapping. User stories describe interactions with a specific product. JTBD describes the goal that exists independently of any product.

JTBD is not a replacement for design thinking. JTBD defines the problem space with precision. Design thinking generates creative solutions. They are complementary, not competing.

JTBD is not just qualitative. The most impactful applications of JTBD pair qualitative discovery (interviews, observation) with quantitative validation (surveys, opportunity scoring). Stopping at the qualitative stage is the most common mistake teams make.

JTBD is not a one-time exercise. Jobs are stable, but customer satisfaction with current solutions shifts as competitors innovate. Revisit your outcome data regularly — annually at minimum for fast-moving markets.

Getting Started: Practical First Steps

If you are convinced that JTBD deserves a pilot in your organization, here is where to start:

1. Pick one product line. Choose a product where you suspect current market research is not capturing the full picture. Ideally, one where sales are flat despite feature improvements — a classic sign that you are optimizing the wrong outcomes.

2. Define the job. Gather your product team and draft a job statement. Debate it. Refine it. Make sure it is solution-agnostic and at the right level of abstraction.

3. Run 10 exploratory interviews. Before committing to a full ODI engagement, talk to 10 customers using JTBD interview techniques. Ask what they are trying to accomplish, not what they want in the product. The insights from even a small set of interviews can be revelatory.

4. Assess the gap. Compare what your JTBD interviews reveal to what your current product roadmap addresses. The gap between the two is the measure of how much value JTBD can add.

5. Build the case. Use the gap analysis to build a business case for a full JTBD/ODI initiative. Frame it in terms your leadership understands: reduced product failure risk, faster time-to-market for features that matter, and improved competitive positioning.

Frequently Asked Questions