Jobs to be done (JTBD) definition

JTBD holds that customers do not buy products: they hire them to make progress in a specific situation. The job is the progress a person is trying to make. The product is whatever they reach for to make that progress. Understanding this inverts the design process: instead of asking “what features does our product need?” you ask “what job is the user hiring this for, and does our solution fit the context in which that job arises?”

Tony Ulwick formalized the framework at Strategyn in the 1990s under the label Outcome Driven Innovation. Clayton Christensen at Harvard Business School popularized it through the milkshake story: McDonald’s found morning commuters were hiring milkshakes not because they wanted a milkshake, but to stave off hunger and fight boredom on a long drive alone. The job was “get through the commute.” The competitor was not Burger King. It was a banana and a bagel. That insight changed what the product team optimized for: thicker consistency and a faster dispenser at the drive-through window, not new flavors.

The job statement format

The standard format: “When [situation], I want to [motivation], so I can [expected outcome].”

A concrete example: “When I’m boarding a flight alone with a toddler, I want to know immediately if my gate changes, so I can re-plan without losing my place in the security line.”

That statement is more actionable than any persona. It specifies the situation that triggers the need, the motivation, and the outcome that defines success. From it you can derive that push notifications matter more than a beautiful departure board, and that the notification must arrive before the user has to make a physical move. You know what “better” means (no additional stopping, no losing your place), and you know what the competing solution is (standing and watching the board, hoping).

Three job dimensions

Every job has three layers. Designing for only one produces a product that feels incomplete even when it technically works.

Functional: the practical task the user is trying to complete (know the gate before committing to a direction).
Emotional: how the user wants to feel during and after the job (calm, not scrambling; in control, not reactive).
Social: how the user wants to be perceived (a capable parent who has it handled, not the person blocking the aisle in a panic).

The functional job is the easiest to name. The emotional and social jobs explain why users leave products that technically work: the job got done, but not in a way that felt right. A notification that arrives in a terse system tone at the wrong moment can complete the functional job while failing the emotional one entirely.

JTBD versus personas and user stories

Personas describe who the user is. JTBD describes what progress they are trying to make. A persona cannot tell you what to build; it can only tell you who to build for. A job statement gives you the situation, the motivation, and the desired outcome: the three inputs you need to make a product decision.

User stories (“as a traveler, I want gate alerts so I don’t miss my flight”) describe desired system behavior, but they do not require you to understand the situation that gives rise to the need. JTBD forces you to specify the “when” because the same person in a different situation has a different job. The parent boarding with a toddler and the solo business traveler lounging at the gate are the same persona category but have entirely different jobs, different emotional stakes, and different thresholds for what counts as a good alert.

The conflation is the most common JTBD error in interviews: candidates say “the job is to book a flight” when the job is “get to Chicago without disrupting the rest of my day.” The difference determines what you measure and what you build.

JTBD is stable; solutions are not

The job does not change when technology changes. Getting to work on time has been the same job for 150 years. The solution (horse, subway, car, self-driving car) has changed completely. This stability is why JTBD is useful for strategy: it keeps you anchored to the problem rather than the current solution, and it reveals when a new technology is serving the same job better rather than creating a new category. If you define your product by the solution, a technology shift makes you obsolete. If you define it by the job, the same shift is an upgrade opportunity.

The 2026 reframe: feasibility is free, JTBD is the primary filter

In 2026, most product teams can build nearly anything with AI. That eliminates the old constraint where feasibility was the hard question. The question is no longer “can we build it?” It is “is this actually the job the user needs done?”

Viable means the job is real, frequent, and painful enough that someone will pay to have it done. Lovable means your solution fits the user’s actual situation (the “when”) so precisely that the product disappears into the job itself.

For AI and agentic products, the job statement must extend further. Users are not just hiring a tool; they are delegating a task. The job now includes “without introducing new anxiety or oversight burden.” A well-formed job statement for an agentic product specifies delegation scope: what the agent handles fully (gate change alerts, rebooking options) versus what the user retains (final booking confirmation), and what acceptable error rate looks like.

The evidence that this matters at scale: 96% of C-suite leaders believe AI boosts productivity, yet 77% of employees report increased workloads. The gap is a JTBD failure: AI features were shipped around capability messaging rather than a clearly defined job. 90% of function-specific AI use cases remain stuck in pilots for the same reason. The product was built around what the model could do, not around the progress the user was trying to make.

Interview application

strong

"JTBD holds that customers don't buy products; they hire them to make progress in a specific situation. The job statement format is: when [situation], I want to [motivation], so I can [expected outcome]. For a travel app: 'When I'm boarding a flight alone with a toddler, I want to know immediately if my gate changes, so I can re-plan without losing my place in the security line.' That tells me push notifications matter more than a departure board redesign, and the notification must arrive before the user physically commits to moving. It also separates JTBD from a persona: a persona tells me who she is; the job tells me what progress she needs to make in a specific context. For an AI travel agent, the same job statement extends to delegation scope: what does the agent handle fully (rebooking) versus what does the user retain control of (confirming the new seat)? That distinction defines the product, the guardrails, and where the trust model sits."

weak

"JTBD means you focus on the user's job instead of the product's features." This is circular (what is the job?), never produces a job statement, conflates JTBD with generic user-centricity, and gives no basis for a product decision. Interviewers hear it and know the candidate read a blog post but never applied the framework. Without specifying situation, motivation, and desired outcome in a concrete statement, JTBD is just a vocabulary word.

What interviewers are actually testing

Product sense questions that invite JTBD are checking three things: whether you can write a specific job statement (not a vague “user need”), whether you can connect that statement to a concrete product decision, and whether you understand the limits of the framework (JTBD surfaces the job; it does not prioritize between competing jobs or size the market). Candidates who name-drop JTBD without a job statement have not cleared the bar. Candidates who produce a statement, derive a decision from it, and note where they go next (opportunity solution tree, viability sizing, delegation scope for an agent) have.

For the full framework treatment and step-by-step application, see jobs to be done. For how the framework extends to autonomous AI systems, see JTBD for agents. For the viable/lovable reframe in the AI era, see feasibility is free and lovable, not just usable.