Jobs to Be Done Method: A Guide for Product Managers

Why a Forty-Year-Old Insight Is Still Misunderstood

“Jobs to Be Done” sounds like an MBA buzzword. And yes, the framework comes from Harvard — developed by Clayton Christensen, then operationalized into a rigorous methodology by Tony Ulwick. But the reason it persists, decades after its introduction, is not because consultants like selling it. It is because the core insight keeps proving itself correct.

The insight: People do not buy products. They hire products to do a job in their lives.

Theodore Levitt, the Harvard marketing professor, put it this way in the 1960s: “People don’t want a quarter-inch drill. They want a quarter-inch hole.” Christensen pushed further: the hole is not the job either. The job might be “secure a shelf to the wall.” Or, more accurately: “create organized storage in a living space.” Depending on how you define the job, your competitors, your target segment, and your product strategy all shift fundamentally.

That is not a semantic game. It is the operational logic of the Jobs to Be Done method — and it changes how product managers make every consequential decision.

This article is a working guide to the JTBD method for product managers who need to understand it deeply enough to apply it, advocate for it, and avoid the common implementation mistakes. For the foundational primer, see What Are Jobs to Be Done?.

The Core Idea: What a “Job” Actually Is

A job, in JTBD terms, is a goal that a person or organization is trying to achieve in a specific circumstance. Not a task. Not a feature request. Not a pain point. A goal — with a beginning state, an end state, and measurable criteria for success.

Three properties define a well-specified job:

Jobs Are Solution-Agnostic

A proper job statement contains no reference to a specific product, technology, or solution. “Use our CNC machine to cut a workpiece” is not a job — it describes an interaction with your product. “Produce a dimensionally accurate component from raw material” is the job. The distinction matters because solution-agnostic job statements open the innovation space to possibilities that product-centric framing forecloses.

An Austrian agricultural equipment company spent years innovating around “tractor attachment usability.” When they reframed the job as “prepare soil for optimal seeding conditions,” the competitive set expanded — and so did the opportunity space. Solutions they had never considered suddenly became relevant.

Jobs Are Stable Over Time

The job of “safely ventilate a patient during a minimally invasive procedure” has existed since surgeons first operated under general anesthesia. What has changed dramatically is the solution: from rudimentary bellows systems, to mechanical ventilators, to today’s electronically controlled devices with real-time monitoring. A product strategy anchored to the job rather than the current generation of solutions is inherently more durable.

This stability is one reason the JTBD method produces strategy that outlasts product cycles. The job does not change when your technology changes.

Jobs Have Measurable Desired Outcomes

This is Tony Ulwick’s critical contribution. At each step of the job, customers have desired outcomes — specific, measurable criteria they use to evaluate success. These are not opinions or preferences. They follow strict syntax: direction of improvement + metric + object of control + contextual clarifier.

Example: “Minimize the time required to switch machine parameters when soil conditions change mid-field.” This is not a feature request. It is a stable statement of what matters to the customer, independent of any solution. When you survey 300 customers on importance and satisfaction for 120 such outcomes, you get a quantitative map of the opportunity space.

The Three Dimensions Every Product Manager Must Understand

Every job has functional, emotional, and social dimensions. Most product teams address only the functional layer and then wonder why technically superior products lose to inferior ones.

Functional Jobs

Functional jobs are the practical tasks: cut, assemble, monitor, transport, diagnose, document. These are what engineering teams naturally focus on. They are necessary — but they are not sufficient.

Emotional Jobs

Emotional jobs describe how the person wants to feel while executing the functional job. A field service technician using a diagnostic device has a functional job (identify the fault accurately) and emotional jobs (feel confident the diagnosis is correct, avoid the embarrassment of a misdiagnosis in front of the customer).

In B2B markets — where most DACH industrial companies operate — emotional jobs are systematically underestimated. The VP Engineering selecting a new manufacturing platform is not making a purely rational calculation. He is also weighing: “What happens to my career if this goes wrong?” That is an emotional job. Ignoring it means designing to functional specs while losing deals to competitors who address the confidence question.

Social Jobs

Social jobs are about how the person wants to be perceived: competent, forward-thinking, reliable. The procurement manager who champions an expensive new system is not just buying functionality. She is buying professional credibility with her peers and leadership.

In our work with MedTech and industrial clients, 30 to 40 percent of the highest-opportunity outcomes consistently relate to emotional and social dimensions. Companies that address only functional needs leave a significant portion of the competitive advantage untouched.

I have watched technically superior products lose to inferior ones because the winner addressed the emotional and social jobs that the market research never captured. In B2B, we carry this bias that decisions are purely rational. They are not. They are made by humans with careers, reputations, and anxieties — and the product that acknowledges that wins more often than the one that ignores it.

The Job Map: The Framework’s Most Practical Tool

The Job Map is a functional decomposition of the job-to-be-done into its sequential steps. It follows a universal schema that Ulwick validated across hundreds of projects across radically different industries:

1. Define: What must be planned or defined before the job begins?
2. Locate: What inputs — materials, information, resources — must be found or gathered?
3. Prepare: How are those inputs configured for use?
4. Confirm: What must be verified before proceeding?
5. Execute: The core performance of the job.
6. Monitor: What must be tracked during execution?
7. Modify: What adjustments are required if conditions change?
8. Conclude: What happens when the job is finished?

Why the Job Map Is Not a Customer Journey Map

This is one of the most common confusions. A customer journey map documents how a customer interacts with your existing product or service today — it is a process description embedded in a specific solution. The Job Map describes the functional structure of the job itself, independent of any current solution.

A customer journey map shows how a construction site manager today works with a specific crane and its current control interface. The Job Map shows what functional steps are required to “position heavy loads safely at a construction site” — whether the solution is a crane, a telehandler, or a drone coordination system that does not yet exist.

This distinction is not pedantic. It determines whether your product development is anchored to the future or trapped in the present.

Desired Outcomes: The Language of Customer Needs

For each step of the Job Map, product teams formulate desired outcomes — concrete, measurable statements of what the customer wants to achieve at that step. A complete JTBD study typically generates 100 to 150 outcomes for an entire job.

The formulation rules are strict:

Direction + Metric + Object + Context

Examples from real projects:

• “Minimize the likelihood that the instrument obscures the surgical field during the procedure.”
• “Minimize the time required to reconfigure the machine for a new material type.”
• “Minimize the likelihood that relevant subsurface information is missed before excavation begins.”

The direction is always “minimize” — minimize time, likelihood, effort, variance. This ensures outcomes are measurable and comparable across different respondents.

Why Strict Formulation Matters

Two reasons make the syntax non-negotiable:

First, solution independence. A correctly formulated outcome describes the need, not the solution. “Minimize time for changeover” is solution-agnostic. “Provide a quick-change attachment system” is a solution. Only outcome statements can be fairly compared across different technologies and product categories.

Second, measurability. Every correctly formulated outcome can be rated in a customer survey on two dimensions: importance and satisfaction. That rating is the foundation for quantitative prioritization — the step that turns qualitative understanding into strategic direction.

Formulating outcomes is a craft that takes practice. In our projects, we invest significant time in the qualitative phase — because a poorly formulated outcome produces unusable data in the quantitative phase. It is exactly like survey design: garbage in, garbage out. The discipline of outcome formulation is what separates JTBD as a strategic methodology from JTBD as a conceptual framework.

JTBD in B2B Industrial Contexts

Product managers at DACH industrial companies often encounter a specific objection: “Our market is different. We have long-standing customer relationships. We know what they need.”

The objection is understandable. It is also, consistently, wrong.

What companies know from long customer relationships is what customers say they need, what they complain about, and what features they request. What they do not know — even after decades of customer contact — is the complete set of 100 to 150 outcomes that define the job, and which of those outcomes are genuinely underserved.

A Tier 1 supplier to the automotive industry we worked with had maintained key-account relationships for over twenty years. Their product managers attended every major trade show, hosted quarterly customer visits, and ran annual satisfaction surveys. They were confident they understood their customers.

The ODI study revealed that the three most underserved outcomes in the entire job — with opportunity scores above 14 — had never appeared in any customer feedback, any VOC program, or any account manager report. The customers were not hiding them; the questions that would have surfaced them were simply never asked.

That is the structural problem with relationship-based customer knowledge: it captures what customers articulate when asked the wrong questions. The JTBD method provides the right questions.

Applying JTBD: The Five-Step Sequence

Here is the practical sequence, with the details that textbooks typically omit:

Step 1: Define the Job

Gather your product team — product management, engineering, sales — and ask: “What job do our customers hire our product to do?” Watch for abstraction-level errors:

• Too narrow: “Operate our laser cutter” — this describes product interaction, not customer goal.
• Too broad: “Run a manufacturing operation” — this encompasses too many sub-jobs to be actionable.
• Right level: “Produce precise components from sheet metal within specified tolerances” — this is the job.

The right level of abstraction is usually one step removed from the product interaction. Debate this in your team. The conversation itself is valuable; it surfaces assumptions that have been implicit for years.

Step 2: Map the Job

Conduct 10 to 15 qualitative interviews with actual job performers — not buyers, not decision-makers, but the people who do the job every day. Ask them to walk you through what they do, step by step, from planning to completion.

Do not ask: “What do you like about our product?” Ask: “Walk me through exactly what you do when you [the job]. Start at the very beginning — before you even touch the equipment.”

Code the responses against the Job Map schema. The output is a functional map of the job with 8 to 12 major steps.

Step 3: Capture Desired Outcomes

For each step of the Job Map, formulate desired outcomes using the direction-metric-object-context syntax. Target 8 to 15 outcomes per step, 100 to 150 total for the full job.

Test each outcome against two criteria: Is it solution-independent? Is it measurable? If it fails either test, reformulate.

Step 4: Quantify

Survey a representative sample — minimum 180 respondents for market-level insights, 300 to 600 if you plan segment analysis — rating each outcome on importance (1-5) and satisfaction with current solutions (1-5).

Calculate the opportunity score: Importance + (Importance − Satisfaction). Outcomes scoring above 10 on a 20-point scale are your growth opportunities. Outcomes scoring above 15 are rare, high-priority targets.

Step 5: Segment and Strategize

Run cluster analysis on the survey data. The clusters that emerge are not defined by company size, industry, or geography — they are defined by patterns of unmet needs. These need-based segments are strategically more actionable than any demographic segmentation.

Develop product concepts that address the highest-scoring outcomes in the most attractive segments. For each concept, calculate how many underserved outcomes it addresses and how much it would improve the aggregate opportunity score. This replaces subjective feature prioritization with a quantifiable decision criterion.

Common Mistakes and How to Avoid Them

Mistake 1: Defining the Job Too Close to the Solution

“Operate our CNC milling machine” is not a job. It is a product interaction description. The job is “produce a dimensionally accurate part from raw stock.” If your job statement mentions your product, your technology, or your current solution category, start over.

Mistake 2: Writing Outcomes as Feature Requests

“An intuitive user interface” is a feature wish, not an outcome. “Minimize the time required to input parameters for a new job order” is an outcome. The difference: the feature request embeds a solution assumption. The outcome is solution-agnostic and measurable.

Mistake 3: Shortcutting the Qualitative Phase

Some teams try to write outcomes at their desks without customer interviews. The result is a list of internal assumptions dressed up in outcome syntax. Outcomes must come from what customers say when asked the right questions — not from what the product team believes customers need.

Mistake 4: Treating JTBD as a One-Time Exercise

Jobs are stable. Competitive landscapes are not. As competitors innovate and customer satisfaction with existing solutions changes, the opportunity scores shift. JTBD studies should be revisited every two to three years in active markets.

When JTBD Is the Right Approach

The JTBD method is particularly well-suited when:

• Your market appears saturated and you suspect there are hidden growth opportunities your current research is not surfacing.
• Product development is driven by internal opinions rather than quantified customer data. The classic symptom: roadmap debates that turn on who has the most persuasive story.
• You are entering a new market and need to understand which needs are genuinely underserved by existing solutions.
• Your innovation rate is stagnating — many new features shipped, but measurable customer value is flat.
• You are developing a platform strategy and need to understand which job ties together multiple use cases.

JTBD is less valuable when the job is so simple it cannot be meaningfully decomposed, or when your business competes purely on price with no room for differentiation.

For a comparison with other common approaches, see Design Thinking vs. Jobs to Be Done: What Works Better? and Customer-Centric Innovation: Why Traditional Methods Fail.

Frequently Asked Questions