Jobs-to-be-Done
Jobs-to-be-Done (JTBD) is the foundational product framework for understanding why customers buy anything. Coined by Clayton Christensen in 2005, its central claim is deceptively simple: “People don’t buy products, they hire them to do a job.” Customers don’t belong to demographic segments — they hire products to make progress in specific circumstances. This reframe is upstream of positioning, niche-selection, PMF, feature prioritization, and competitor analysis. Every other product framework in this wiki is stronger when layered on top of JTBD thinking.
The framework is famously illustrated by the milkshake story: McDonald’s couldn’t improve milkshake sales through panel research or flavor tweaks. When Bob Moesta interviewed buyers at the moment of purchase, he discovered ~40% of milkshakes were bought before 8:30am by solo commuters whose job was “help me stay awake and occupied on my boring commute.” The competitors weren’t other milkshakes — they were bananas, bagels, donuts, and Snickers. Demographics were useless; context was everything.
The Core Insight
Products are hired to make progress. Three implications change how you build:
-
Jobs are durable; solutions churn. People have wanted to kill time on commutes for a century. The solution changed from newspapers to radio to podcasts to milkshakes to AirPods — but the job is stable. Great products map to durable jobs, not trending solutions.
-
Competitors are anything that does the same job. Netflix doesn’t compete with HBO — it competes with sleep (Reed Hastings’ own words). Your real competitive set is defined by the job, not by the product category. Most founders dramatically underestimate their competition by thinking category-first.
-
Demographics tell you who, not why. A 38-year-old working mom has dozens of jobs across a single day and hires completely different products for each. “Who” bought the product is a correlation; “why they hired it” is causation. JTBD is the switch from correlation to causation.
The Three Dimensions of a Job
Every job has three dimensions, and missing any one is a common failure mode:
| Dimension | Milkshake Example | Snickers Example |
|---|---|---|
| Functional | Fuel for the commute | Hunger |
| Emotional | Feel productive, not bored | Not feel “hangry” |
| Social | Be a “responsible adult,” not the bagel-crumbs guy | The “you’re not you when you’re hungry” public reframe |
The #1 reason functionally-equivalent products lose: they missed the emotional or social dimension. A tool that works better but makes users feel ashamed using it will lose to a worse tool that users feel proud of. Linear vs Jira has strong emotional/social dimensions (engineers feel respected by Linear, insulted by Jira).
The Four Forces of Progress
Bob Moesta’s diagnostic diagram — the tug-of-war that precedes every switch:
PUSH of the situation
(current frustration)
│
▼
┌──────────────────────┐
│ DECISION TO SWITCH │
└──────────────────────┘
▲
│
PULL of the new solution
(attraction of alternative)
Against:
ANXIETY about the new
("what if it's worse?")
│
▼
┌──────────────────────┐
│ INERTIA │
└──────────────────────┘
▲
│
HABIT of the present
(comfort, sunk cost)
A switch only happens when Push + Pull > Anxiety + Habit.
This reframes product strategy. Most founders obsess over increasing Pull (new features, better design). But often the faster win is:
- Reduce Anxiety — free trials, money-back guarantees, guided onboarding, imported data from the old tool, a public customer list to signal safety
- Break Habit — trigger events (a new hire, a failed audit, a quarterly planning cycle), friction-reducers that make the switch effortless
Kit’s turnaround (case study) is a perfect Four Forces example: Nathan Barry’s “I’ll migrate your data for free” offer removed all of the Anxiety and Habit — bloggers who were stuck on bad email tools could switch with zero effort. The Push (Infusionsoft/AWeber were bad) and Pull (Kit was designed for them) were already there; removing the friction won the deals.
The Job Story Format
Invented by Paul Adams at Intercom, formalized by Alan Klement:
“When [situation], I want to [motivation], so I can [expected outcome].”
Good job stories are specific about the circumstance. Bad ones are about the user:
| Bad | Good |
|---|---|
| ”As a marketing manager, I want a dashboard" | "When I’m preparing for my Monday standup, I want to see last week’s top metrics in one place, so I can tell a coherent story to my boss" |
| "As a developer, I want fast builds" | "When I’m debugging a production issue at 11pm, I want my test suite to finish in under 30 seconds, so I can iterate fast while I’m still thinking about the bug" |
| "As a small business owner, I need invoicing" | "When a client finally approves a project after weeks of back-and-forth, I want to send an invoice before I forget, so I can get paid before they change their mind” |
Notice the difference: the bad version specifies who; the good version specifies when and why. The “when” is the job’s trigger. The “why” is the progress they’re making.
The Switch Interview
The JTBD interview is fundamentally different from the Mom Test or traditional customer development. Bob Moesta’s Switch Interview technique:
- Find people who just switched — ideally within 2 weeks of purchase, while the context is fresh
- Walk backwards through the timeline:
- First thought (“when did you first realize your old solution wasn’t working?“)
- Passive looking (“when did you start noticing alternatives?“)
- Active looking (“when did you start actively shopping?“)
- Deciding event (“what happened the day you decided?“)
- First use (“what was it like the first time you used it?“)
- Habit (“when did it become normal?“)
- Probe each step for the Four Forces — push, pull, anxiety, habit
- Reconstruct the “Big Hire” and “Little Hire” — the purchase moment vs the actual usage moment (often different)
What you’re looking for: the deciding event. The specific moment when the old solution became untenable. That moment is almost never “I ran a feature comparison” — it’s something specific, concrete, and circumstantial (“my coffee maker broke again on a Tuesday morning and I was already late for a meeting”).
Do not interview happy existing customers — they can’t tell you why they switched, only why they stay. Interview switchers.
JTBD vs Personas
JTBD practitioners reject demographic personas. Paul Adams (Intercom): “Personas are imaginary customers defined by attributes that don’t acknowledge causality.”
Why personas fail:
- A single person has dozens of jobs per day and hires different products for each
- “38-year-old working mom with a minivan” tells you nothing about why she’d buy
- Personas freeze static identities; jobs are situational
- Personas anchor teams on the who when the actionable insight is the when
Replace persona documents with job story documents. Instead of “meet Sarah, a 38-year-old marketing manager at a mid-size B2B SaaS company,” write “when a marketing manager is preparing the weekly metrics review and realizes the reporting tool is broken again, she wants a clean dashboard that just works, so she can stop explaining tool failures to her boss.”
Three Schools of JTBD
JTBD has three practitioner schools that overlap but emphasize different things:
| School | Leader | Core Contribution | Best For |
|---|---|---|---|
| Christensen/Classical | Clayton Christensen | Origin theory, milkshake story, “jobs are hired” | Strategy, category definition |
| Moesta/Progress | Bob Moesta | Switch Interview, Four Forces, Big Hire/Little Hire | Sales, pricing, onboarding |
| Ulwick/ODI | Tony Ulwick (Strategyn) | Outcome-Driven Innovation, Desired Outcome Statements, quantitative opportunity scoring | Feature prioritization, roadmaps |
And the practitioner hub:
- Intercom (Des Traynor, Paul Adams) — the SaaS application playbook
- Alan Klement (When Coffee and Kale Compete) — reframed around “progress” rather than “job,” runs jtbd.info
Most founders should start with Christensen for theory, then Moesta for interviewing, then Intercom for applying to SaaS. Ulwick’s ODI is the formal quantitative version — powerful but heavy.
JTBD Applied to the Wiki’s Case Studies
- Job: “When I’m managing my team’s engineering work, I want a tool that feels fast and opinionated, so I can focus on shipping instead of configuring the tool.”
- Emotional: feel respected as a professional engineer
- Social: identify as “the team that ships”
- Competitors: Jira (the anti-hero), GitHub Issues, Notion, spreadsheets
Kit:
- Job: “When I’m a blogger with a growing audience, I want to send email sequences and sell digital products, so I can turn my audience into income without learning complex software.”
- Emotional: feel like a real business, not a hobbyist
- Social: be seen as a professional creator
- Competitors: Mailchimp (generic), Infusionsoft (overkill), AWeber (dated)
- Job: “When I have an idea for an app but can’t code, I want to describe what I want and get a working app, so I can ship without hiring a developer.”
- Emotional: feel like a builder, not a gatekeeper’s victim
- Social: be a person “who ships things” on Twitter
- Competitors: hiring a developer, WordPress templates, doing nothing
- Job: “When my small team has a project with many moving parts, I want one place for everything, so I can stop losing track of decisions in email chains.”
- Emotional: feel calm, not frantic
- Social: run a sane workplace
- Competitors: email, Slack + Notion + spreadsheets, Jira (overkill)
In each case, the job is the circumstance + progress, not the feature list. Every successful product in this wiki is secretly a good JTBD answer.
Common Mistakes
- Too narrow: “hire a hammer to pound this nail” — feature-level, not a job
- Too broad: “be happy” — life goal, not actionable
- Confusing job with solution: “the job is to send an email” — email is the current solution, not the job
- Confusing “what” with “why”: observing behavior without asking about the circumstance and anxiety
- Ignoring emotional/social dimensions: building the functionally best product that nobody wants to be seen using
- Not interviewing switchers: asking happy current users yields no causality
- Treating JTBD as a template exercise: the real work is interviews and insight, not filling in blanks
- Writing the job from the company’s perspective instead of the customer’s
- Confusing personas with jobs: a persona ≠ a job statement
- Skipping the Four Forces diagnostic: most founders only optimize Pull and miss Anxiety/Habit
When to Use JTBD
- Ideation: find durable jobs in your space and identify weak current solutions
- Customer interviews: use Switch Interviews instead of the “what would you pay for” questions
- Feature prioritization: features that serve the core job ship; features that don’t get cut
- Positioning: Dunford’s “best-fit customers” map to “people with this specific job”
- Competitive analysis: list every solution that does the job, not just products in your category
- Pricing: price against the value of the progress, not the cost of your features
- Sales: reduce anxiety and break habit, don’t just push pull
- Product strategy: stop arguing about feature roadmaps; argue about which jobs to own
Relationship to Other Wiki Concepts
- customer-development: JTBD is the “why” layer; customer development is the broader practice
- mom-test: specific interview techniques for avoiding false positives; JTBD is the conceptual frame
- positioning: best-fit customers in Dunford’s canvas are defined by their job
- niche-selection: a niche is a group of people with a shared job
- product-market-fit: PMF happens when your product is the obvious hire for a specific job
- ideation: great ideas come from spotting unserved or badly-served jobs
- minimum-viable-product: the MVP tests whether your product can do the job at all
- competitive-strategy: JTBD expands your competitive set beyond your product category
- pricing-strategy: price against the progress, not the features
JTBD is genuinely upstream of all of these. Every other framework is sharper when you’ve identified the job.
Key Takeaways
- People hire products to make progress — products are instruments, not ends
- Jobs are durable; solutions churn — map to jobs, not trends
- Competitors are anything that does the same job — across product categories
- Every job has functional, emotional, and social dimensions — missing any one is a common loss
- Demographics describe who, not why — personas are causally empty
- The Four Forces predict switching — Push + Pull must beat Anxiety + Habit
- Interview switchers, not happy users — switch interviews reveal causation
- Job stories beat user stories — “when [circumstance]” beats “as a [persona]”
- Reducing Anxiety often beats adding Pull — free trials, data migration, onboarding
- JTBD is upstream of positioning, niche, PMF, and roadmap — start here
See Also
- customer-development
- mom-test
- positioning
- niche-selection
- product-market-fit
- ideation
- minimum-viable-product
- competitive-strategy
- pricing-strategy
- case-study-linear
- case-study-kit
Sources
- Competing Against Luck — Clayton Christensen
- The Mom Test — Rob Fitzpatrick
- Customer Development — Steve Blank