Lesson 6: Jobs To Be Done

Two lessons ago, in the Reflection Exercise, a VP of Sales told you: "Three of our biggest enterprise prospects said they won't sign unless we add offline mode. Build it immediately." Last lesson, a workplace analytics company's customers all demanded a compliance dashboard. In both cases, this curriculum told you to pause before treating the request as a decision — but it did not yet give you a structured method for doing that pausing well. This lesson is that method.

Jobs to Be Done (JTBD) is the discipline of asking what underlying task, goal, or change a person is actually trying to accomplish, of which their stated request is only one possible, and often imperfect, solution. The core insight, most closely associated with the late Harvard Business School professor Clayton Christensen, is deceptively simple: people don't want products; they "hire" products to make progress on a specific job in their life or work. A person doesn't want a quarter-inch drill bit — they want a quarter-inch hole, and in some tellings of this idea, they don't really want the hole either; they want to hang a shelf, or fix something broken, or make a room feel finished.

This matters urgently for a PM because nearly every stakeholder request you will ever receive — from users, from customers, from your own leadership — arrives pre-packaged as a proposed solution rather than as a stated problem. "We need offline mode." "We need a compliance dashboard." "We need dark mode." "We need an export button." JTBD is the discipline that lets you decompose any of these requests back into the underlying job, so that you can evaluate whether the proposed solution is actually the best available answer — or whether a cheaper, faster, or more effective solution exists that the requester simply didn't think to propose, because proposing solutions isn't their job. It's yours.

Learning Objectives

1
Define a "job to be done" and distinguish it from a feature request, a solution, and a demographic persona.
2
Apply the "Five Whys"–style laddering technique to decompose a stated request into its underlying functional, social, and emotional dimensions.
3
Distinguish functional, social, and emotional jobs, and explain why solutions that address only the functional dimension often underperform.
4
Identify the "competing against non-consumption" trap and explain why a product's true competitors are often not the obvious rival products.
5
Apply JTBD thinking to a stakeholder request from either a user or a customer (per the Stakeholder Ledger, Lesson 5), and propose at least one alternative solution to the same underlying job.

Lesson 1 (What is Product Management?) and Lesson 5 (Users vs. Customers). This lesson assumes familiarity with the three core questions (what problem, what solution, how do we know), the Decision Chain, and the Stakeholder Ledger habit of naming whose interest a request represents before evaluating it. JTBD is the method that fills in exactly the step this curriculum has, until now, only told you to perform without showing you how.

The Core Definition

A job to be done is the progress a person is trying to make in a particular circumstance — the underlying task, goal, or change they are trying to achieve — independent of any specific product or feature. The person "hires" a product, service, or even an informal workaround to get that job done, and will "fire" it (switch away, stop using it, or never adopt it in the first place) if something else does the job better, cheaper, or more conveniently.

The classic formulation, drawn from Clayton Christensen's writing and popularized further by consultants such as Bob Moesta and Tony Ulwick, uses a specific structure:

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

Notice what this structure deliberately omits: it says nothing about a product, a feature, or a company. It describes a person's situation and their desired outcome only. This is intentional — a job statement written correctly should be just as true before your product existed as after, and should remain true even if a competitor's product, or no product at all, ends up being hired to do it.

Why "The Customer Wants X" Is Usually the Wrong Level of Analysis

Recall from Lesson 1's Common Beginner Mistake 4 and this lesson's opening example: stakeholders overwhelmingly express their needs as proposed solutions, not as jobs. This isn't a character flaw in stakeholders — it's a natural consequence of the fact that solving problems for a living is a specialized skill, and most people, most of the time, reach for the first plausible solution they can imagine rather than doing the harder work of naming the underlying problem precisely.

The risk is that a PM who takes stated solutions at face value inherits whatever blind spots the requester had. A sales VP who hears "we need offline mode" from prospects has correctly identified that something is blocking a sale, but has no particular expertise in solution design — that is the PM's job, and it is exactly the value a PM adds that a simple order-taker does not.

The Three Dimensions of a Job: Functional, Social, Emotional

A job to be done is rarely purely practical. JTBD theory distinguishes three overlapping dimensions:

Functional dimension — the practical task itself. ("I need to get my team's quarterly numbers reviewed before the board meeting.")
Emotional dimension — how the person wants to feel, or wants to avoid feeling, while getting the job done. ("I don't want to feel embarrassed presenting incomplete data.")
Social dimension — how the person wants to be perceived by others while getting the job done. ("I want my peers to see me as someone who runs a data-driven team.")

A product that satisfies only the functional dimension while ignoring the emotional and social dimensions frequently underperforms a functionally weaker competitor that better addresses all three. This is one of the most common reasons "objectively better" products lose to seemingly inferior ones: the losing product solved the practical task but ignored how the person wanted to feel, or be seen, while doing it.

Laddering: Getting From a Stated Request to the Real Job

The core technique for uncovering a job is laddering — repeatedly asking "why" or "what would that let you do" in response to a stated request, until you reach a level of explanation that would remain true regardless of which specific solution is chosen.

A worked example, continuing this lesson's opening scenario:

Stakeholder request: "We need offline mode." Why? "Because our enterprise prospects work in facilities with unreliable Wi-Fi — warehouses, factory floors, field sites." Why does unreliable connectivity block a sale? "Because if the app doesn't work, their staff can't log safety inspections in real time, and inspections are a regulatory requirement." What would solve that, fundamentally? "A way to guarantee that a safety inspection gets recorded and eventually synced, regardless of connectivity at the moment it happens."

Notice what happened during this ladder: the request moved from a specific technical implementation ("offline mode," which could mean full local data caching, conflict resolution, background sync, and a meaningful engineering investment) to a more precise underlying job ("guarantee an inspection gets recorded and eventually synced regardless of momentary connectivity"). The second framing opens up a wider solution space — a much lighter-weight "save now, sync automatically when reconnected" queuing mechanism might satisfy the actual job at a fraction of the engineering cost of a full offline mode, and might even be delivered faster, which also helps the sales timeline that motivated the original request.

This is the payoff of laddering: it is not merely an academic exercise — it routinely reveals solutions that are cheaper, faster to ship, or more broadly useful than the one originally proposed, without sacrificing the underlying need the stakeholder actually cares about.

Jobs, Not Personas, Segment Real Markets

A common early instinct is to segment users by demographic persona — age, job title, industry. JTBD theory argues this is often the wrong segmentation axis, because two people with identical demographics can be trying to accomplish completely different jobs in a given moment, while two people with wildly different demographics can be trying to accomplish the exact same job.

The canonical illustration from Christensen's own research: a fast-food chain wanted to improve milkshake sales and initially segmented by traditional demographics (age, income) with little success. When researchers instead asked what job people were "hiring" a milkshake to do, they discovered a large, unexpected segment: commuters buying milkshakes alone, in the early morning, to make a long, boring commute more bearable and to stave off hunger until lunch — a job with almost nothing to do with dessert, indulgence, or the demographic profile the company had assumed. This job (a long, one-handed, slow-to-consume companion for a boring commute) suggested completely different product improvements — a thicker shake that lasts longer, a more convenient dispensing process for commuters in a hurry — than a demographic-based analysis ever would have.

Competing Against Non-Consumption

One of JTBD's most useful and counterintuitive ideas is that a product's real competition is often not the obvious rival product, but non-consumption — the alternative of not solving the job at all, or solving it with an improvised, non-product workaround.

A project management tool doesn't only compete with other project management tools; it competes with a shared spreadsheet, a whiteboard, a series of Slack messages, or simply the team's memory. A meal-kit delivery service doesn't only compete with other meal-kit companies; it competes with takeout, with skipping the meal, and with a jar of pasta sauce and whatever's already in the fridge. Understanding the true "job competitor" — frequently an informal workaround rather than a branded rival — reframes what "winning" actually requires: not necessarily being better than the nearest named competitor, but being clearly better than doing nothing, or doing it the old, unglamorous way.

This reframing matters directly for prioritization: a feature that only makes sense in a world where you're racing a specific named competitor may be far less valuable than a feature that converts non-consumers — people currently solving the job badly, informally, or not at all — into users.

Common Mistakes to Avoid

Treating the first stated request as the job itself

"We need offline mode" is a solution, not a job. Stopping the analysis at the first sentence a stakeholder says is the single most common JTBD failure, and it is precisely the failure this lesson's laddering technique exists to prevent.

Confusing a persona with a job

"Our user is a 35-year-old marketing manager" describes a demographic, not a job. The same marketing manager may be hiring your product for entirely different jobs on a Monday morning (planning a campaign calendar) versus a Friday afternoon (quickly checking whether a report is ready before a client call) — and a single persona description flattens this into one undifferentiated profile.

Assuming the job is purely functional

Ignoring the emotional and social dimensions of a job (how the person wants to feel or be perceived) frequently produces a functionally competent but commercially underperforming solution, especially in categories where status, confidence, or belonging matter alongside the practical task.

Benchmarking only against named competitors

Focusing exclusively on feature parity with a known rival product, while ignoring the much larger population of people solving the job through an informal workaround or not solving it at all, causes teams to miss the biggest available growth opportunity — converting non-consumption.

Laddering endlessly until the "why" becomes meaningless

It is possible to ladder too far — asking "why" so many times that you arrive at something so abstract ("I want to be happy") that it no longer usefully constrains solution design. The correct stopping point is the most specific level of explanation that would remain stable across multiple possible solutions, not the most abstract level imaginable.

Jobs To Be Done