jobs-to-be-done

name	jobs-to-be-done
description	Use when the user wants to understand why customers buy or use a product, define what job a feature is solving, or design features around customer outcomes rather than feature requests. Also use when the user mentions 'JTBD,' 'jobs to be done,' 'what job does this solve,' 'customer motivation,' 'why do customers hire us,' or 'outcome-driven.'

Jobs to Be Done

Customers don't buy products. They hire them to make progress in their lives. The job is the unit of analysis — not the customer, not the feature.

The Three Job Layers

Functional job — The practical task: "track my ad spend across channels." Emotional job — How they want to feel: "confident I'm not wasting budget." Social job — How they want to appear: "look data-driven in front of my boss."

All three matter. Products that address only functional jobs get commoditized. Products that nail emotional and social jobs create loyalty.

The Four Forces

When a customer switches to a new product, four forces are at play:

Push forces (away from old):

1. Frustration with the current situation
2. Anxiety about the future if nothing changes

Pull forces (toward new): 3. Attraction to the new solution 4. Attachment to the old way (inertia) — the hidden force that kills adoption

The switch only happens when push + pull > inertia + anxiety about the new.

If customers aren't switching, map the forces. The block is almost always inertia or new-solution anxiety — not lack of pull.

Job Stories (Not User Stories)

User story: "As a [persona], I want [feature] so that [benefit]." Job story: "When [situation], I want to [motivation], so I can [expected outcome]."

Job stories are better because they center context and motivation, not persona labels.

Example:

• User story: "As a marketing manager, I want a dashboard so I can see my data."
• Job story: "When my weekly team meeting starts, I want to know immediately which campaigns are underperforming, so I can redirect budget before the week is wasted."

Conducting a JTBD Interview

Focus on the last time they made a purchase decision or switched tools.

1. "Walk me through the first time you thought about changing [old solution]."
2. "What was happening in your life at that point?"
3. "What did you look at first? Why that?"
4. "What almost made you not switch?"
5. "What was the moment you decided to go with [new solution]?"

Never ask: "What features do you want?" You get feature requests, not jobs.

Outcome-Driven Innovation (ODI) — Ulwick

Customers hire products to get jobs done. They evaluate success by outcomes:

Outcome statement format: "Minimize the time it takes to [action] when [context]." "Increase the likelihood of [positive outcome] when [context]."

Rank outcomes by:

• Importance (how important is this outcome to achieve?)
• Satisfaction (how satisfied are you with current solutions?)

Opportunity score = Importance + max(Importance − Satisfaction, 0)

High importance + low satisfaction = underserved opportunity.

Common Rationalizations

Rationalization	Reality
"We know what job our product solves"	Name it. If it takes more than one sentence, you don't know it yet.
"JTBD is just rebranded user stories"	Job stories center context and motivation. User stories center persona labels and feature wishes.
"Our product solves many jobs"	Products that solve many jobs dilute positioning. Name the primary job.
"Inertia isn't our problem"	Inertia is almost always the problem. Map the four forces before optimizing pull.

Verification

• Primary job stated in one sentence (functional layer)
• Emotional and social job layers named
• Four forces mapped for primary customer switch scenario
• At least one job story written per major feature (not user story)
• Outcome statements defined and ranked by importance × satisfaction gap