Skip to main content
← All guides
Guide · Updated May 2026 · 12 min read

Jobs to Be Done: a founder's guide

Clayton Christensen's framework for understanding why customers buy. The milkshake story, the 4 forces of switch, the interview format that surfaces real motivation, and the mistakes that turn JTBD into vocabulary instead of insight.

The Jobs to Be Done framework was formalized by Clayton Christensen at Harvard Business School and developed further by Bob Moesta and Tony Ulwick. This guide is a primer; the books are the real source.

What is Jobs to Be Done?

Jobs to Be Done is a way of understanding why customers buy. The premise is simple: customers don\'t buy products — they hire products to do a job. When the job changes, the hiring decision changes. When a better product comes along, the old one gets fired.

The phrase comes from Clayton Christensen, who wanted a sharper alternative to demographic segmentation. Two 35-year-old executives might look identical on a marketing dashboard, but one is hiring a milkshake to make his commute less boring while the other is hiring it to celebrate his daughter's soccer game. Same demographic, totally different jobs, totally different products.

The shift in framing — from "who is the customer?" to "what is the customer trying to accomplish?" — turns out to be one of the most useful lenses in product strategy.

The milkshake story

The story Christensen tells in every JTBD talk: McDonald\'s wanted to grow milkshake sales. The marketing team did everything traditional segmentation suggested — flavors, consistency, price, container shape. Sales barely moved.

A team using JTBD asked a different question: when do people actually buy milkshakes, and what are they doing in that moment? The data showed two big spikes: morning commute (one customer, drive-through, weekday) and afternoon with kids (multiple customers, dine-in, weekend).

The morning customer wasn\'t hiring the milkshake to be a milkshake. They were hiring it to fix a long, boring commute. They needed: one-handed, slow to drink, filling enough to last until lunch, and entertaining (chunks of fruit gave the straw something to do).

The afternoon job was completely different — a quick treat to please a kid before the next errand. Different size, different speed, different price sensitivity.

Once the team understood that there were two different jobs, they could improve milkshakes for each one — and stopped trying to design one product for both. Sales jumped.

The 4 forces of switch

Bob Moesta refined the framework into the "forces of progress" — the four pressures that act on every switch decision. To understand why a customer hired your product, you need to understand all four.

1

Push of the current situation

What about the customer's current state is bad enough to make them consider change? Frustration with the existing tool, a missed deadline, a costly mistake, growing pain that crossed a threshold.

Example:"My spreadsheet broke when the team grew past 10 people."

2

Pull of the new solution

What about the new solution is attractive enough to outweigh the cost of switching? A specific feature, a vivid promise, a peer's recommendation, a story of someone like them succeeding.

Example:"My friend's startup uses [tool] and went from chaos to organized in a week."

3

Anxiety about the new

What worries the customer about adopting the new solution? Will it work? Will it integrate? Will the team adopt it? Will I look bad if it fails? Anxiety is a real force — most "no decisions" are driven by it.

Example:"What if we set it up and the team refuses to use it?"

4

Habit of the current

What inertia keeps the customer in the current state? Sunk costs (data, training), social inertia (everyone uses X), or just habit (we've always done it this way).

Example:"We've had 3 years of data in Trello. Nobody wants to migrate."

The math of switch: Push + Pull must outweigh Anxiety + Habit. Most teams obsess over Pull (their product) and ignore Anxiety (the customer\'s fears) and Habit (sunk costs). That's why great products lose to mediocre incumbents.

Functional, emotional, and social jobs

Most teams stop at functional jobs ("get my taxes done"). The customers who buy and stay are responding to all three layers — and the social job is often the loudest of the three for B2B and prosumer products.

Functional job

The practical task the customer is trying to accomplish.

Example:"Get my team aligned on this week's priorities."

Emotional job

How the customer wants to feel after accomplishing the functional job.

Example:"Feel in control instead of overwhelmed."

Social job

How the customer wants to be perceived by others.

Example:"Look like the kind of leader who runs a tight ship."

The switch interview

The signature JTBD format. You walk a customer backwards through the moment they fired their old solution and hired yours. The structure is six phases — each surfaces a specific force.

1

First thought

"Take me back to the moment you first realized your old way of doing this wasn't working. What happened that day?"

Why:Identifies the trigger event. Customers rarely switch because of a slow buildup — there's usually a specific incident.

2

Active looking

"What did you do next? What did you search for, who did you ask, what did you read?"

Why:Maps the consideration set. Where they looked tells you which channels matter and which competitors they evaluated.

3

Decision moment

"Walk me through the moment you decided to try [your product]. What were you thinking?"

Why:Surfaces the pull. The specific phrase or promise that landed becomes the foundation of your messaging.

4

Anxieties before signup

"What worried you about switching? What might have stopped you?"

Why:Identifies the anxieties you need to address in your onboarding, sales pages, and trust signals.

5

First use

"Walk me through the first time you actually used it. What did you expect? What surprised you?"

Why:Reveals onboarding friction. The gap between expectation and reality is where churn risk lives.

6

New normal

"How is your life or work different now compared to before? What's the new normal?"

Why:Confirms whether the job got done. If they can't articulate a specific change, the value isn't landing.

Run 8–12 switch interviews on the same job before drawing conclusions. Patterns emerge in the aggregate, not the individual.

5 common JTBD mistakes

The patterns that turn JTBD into a vocabulary exercise instead of a decision tool.

Confusing the job with the product

"The job is to use my SaaS." No — the customer doesn't want to use software, they want progress in their life. The product is the means; the job is the end.

✓ Instead: Frame the job as a goal, not an action. Not "use accounting software" — "feel confident the books are right."

Skipping the emotional and social jobs

Most teams stop at functional. But customers rarely buy on functional alone — they buy on the emotional and social jobs that the functional one enables.

✓ Instead: For each functional job, ask: how do they want to feel? How do they want to be seen? Those answers become positioning gold.

Doing JTBD without a real switch event

JTBD interviews need a specific switch — fired old, hired new. Without that, you're just doing generic customer interviews dressed up in JTBD vocabulary.

✓ Instead: Recruit customers who switched in the last 30–90 days. Memory decay matters. Older switches produce reconstructed narratives, not real evidence.

Treating JTBD as a replacement for personas

Personas and JTBD answer different questions. Personas: who buys. JTBD: why they switch. Both are needed for different decisions.

✓ Instead: Use personas for marketing channels and tone. Use JTBD for messaging, positioning, and product roadmap.

Not validating the job across enough interviews

One interview gives you a hypothesis. Two interviews give you a coincidence. Real JTBD insights emerge across 8–12 switch interviews on the same job.

✓ Instead: Plan JTBD research as cohorts: 8–12 interviews per job hypothesis, synthesized together. Single-interview insights are unreliable.

Practice the JTBD question rhythm

JTBD switch interviews are hard to run well. The instinct is to ask "what do you want?" instead of walking back to the trigger event. The skill is real-time — catching yourself when you slip into hypotheticals.

We built GoNoGo as a way to drill JTBD-style and Mom Test–style questions before your real interviews. A 30-minute voice session where Alex (an AI strategist) asks switch-event and past-behavior questions — and gives you a transcript showing where you fell into the traps. Free, runs in your browser.

Not a replacement for real customer interviews. A way to practice.

Practice for free →

30 min · No credit card · Then go talk to humans

Frequently asked questions

What's the difference between JTBD and user personas?+
Personas describe who the customer is (demographics, role, psychographics). JTBD describes what they're trying to accomplish (the job). Personas are static — JTBD is contextual: the same person hires different solutions for different jobs at different times. JTBD is more useful for product decisions because it explains "why now?" rather than just "who?"
How is JTBD different from user stories?+
User stories ("As a X, I want Y, so that Z") are about features. JTBD is about progress — what life-state is the customer trying to move from and to? User stories are tactical (sprint planning). JTBD is strategic (positioning, segmentation, roadmap). The two work together: JTBD informs which user stories matter, user stories implement them.
What's a "switch interview"?+
A switch interview is a JTBD-specific format that reconstructs the moment a customer fired their old solution and hired yours. You walk backwards through the customer's timeline: when did they realize the old solution wasn't working? What pushed them to look? What pulled them toward you? What anxieties did they have about switching? It's the most actionable single research format in JTBD.
Do I need to memorize Christensen's milkshake story?+
No, but understanding it helps. The story: McDonald's tried to improve milkshake sales by tweaking flavors and consistency, but sales didn't budge. JTBD research found customers were "hiring" milkshakes for the morning commute — they needed something one-handed, slow to drink, and filling. The job wasn't "be a tastier milkshake," it was "make my boring commute less boring." That insight reframed the product. Read Christensen's book "Competing Against Luck" for the full version.
Can I use JTBD for early-stage validation?+
Yes, but use it as a complement to other validation, not a replacement. JTBD is strongest when you have at least some users to interview about a specific switch event. For pre-product validation, combine JTBD-style "tell me about the last time you tried to solve X" questions (which work without existing users) with traditional Mom Test questions about past behavior.

The original sources

Read JTBD from the source

This guide is a primer. The books go far deeper. Three are essential:

Competing Against Luck

Clayton Christensen — the original framing, the milkshake story in full, integration vs modular.

Demand-Side Sales 101

Bob Moesta — the 4 forces of progress, switch interview methodology in practice.

Jobs To Be Done: Theory to Practice

Tony Ulwick — Outcome-Driven Innovation, the more rigorous quantitative branch of JTBD.

JTBD deep dives

Related guides