When you're about to add a feature and aren't sure if anyone wants it. When your buyer's stated needs don't match their behavior. When you're competing on features and losing to a product that has fewer features but wins anyway.
How to apply Jobs to be Done (JTBD)
- 1
Identify the 'hire' moment. The switch
The job starts the moment a customer decides to switch from their current way of doing something. Find the trigger: what happened that made them say 'enough, I'm going to try something else'? The trigger is the job in disguise. Example: people didn't 'buy a milkshake,' they hired the milkshake to 'make my commute less boring and keep my hands full.'
- 2
Articulate the job as a verb phrase, not a feature
Jobs are actions: 'get my commute done without getting hungry,' 'look like I've got my life together to my in-laws,' 'avoid the awkward conversation about pricing.' Jobs are NOT: 'use a CRM,' 'have a beautiful dashboard,' 'integrate with Slack.' Those are features. Features change. Jobs are stable.
- 3
Map the four forces of progress
Every hire decision has four forces: (1) **Push**. The pain of the current situation. (2) **Pull**. The attraction of the new solution. (3) **Anxiety**. Fear of switching (will it work? will I look dumb?). (4) **Habit**. Inertia of the current solution. For anyone to hire your product, Push + Pull must exceed Anxiety + Habit. If your product is struggling, one of those four is broken.
- 4
Interview for the job (Moesta's 'switch interview')
Find 10 customers who recently hired your product (or a competitor's). Walk them through the entire decision: when did you first think about this? What were you doing? What did you try first? What didn't work? When did you decide? What were you worried about? The answers reveal the job. You'll hear the same 3–5 phrases over and over. That's the job statement in their words.
- 5
Design for the job, not the feature list
Once you know the job, every product decision re-routes through it. Does this feature serve the hire moment? Does this copy describe the job or the software? Does this onboarding help them make progress on the job in the first 5 minutes? If no, cut it. Ruthlessly.
Why JTBD keeps getting rediscovered
Every generation of product people reinvents some version of JTBD because the underlying insight is permanent: people don’t buy products, they hire them to do a job, and they fire them when they stop doing that job well. Once you see it, you can’t unsee it. Your feature list stops feeling strategic. The question becomes “what are we being hired for?”
The milkshake story in one paragraph
McDonald’s wanted to sell more milkshakes. They surveyed customers about thickness, sweetness, size. Sales stayed flat. Christensen’s team observed buyers instead and noticed something odd: 40% of milkshakes were sold before 8am, usually to solo men driving to work. The job? Make my long commute less boring and keep my hand busy without making a mess on my tie. The milkshake was competing with boredom, not with other desserts. The right improvements were: thicker (lasts longer), smaller (fits in a car cup holder), faster to buy (pre-grab line). That’s strategy. “Add more sugar” isn’t.
The four forces in plain English
For anyone to switch TO your product, two forces have to exceed two other forces:
- Push (away from their current situation): their current tool is annoying, slow, missing something.
- Pull (toward your product): you promise something better.
- Anxiety (about switching): will it work? What if my data breaks? What if I look stupid picking the wrong tool?
- Habit (keeping them on the current solution): I already know how to use the existing thing.
Push + Pull > Anxiety + Habit → they switch. Otherwise they stay.
Most founders obsess over Pull (“our features are so good!”). The stuck-in-place founders are usually the ones who can’t articulate the Push or reduce the Anxiety. If your conversion is bad, 4 times out of 5 it’s Anxiety (the landing page feels risky to commit to) or Habit (they’re not pushed enough to change).
Writing a job statement that doesn’t suck
The canonical format:
When [context / triggering moment], I want to [motivation / job], so I can [outcome].
Good examples:
- “When I’m closing out a messy quarter on Sunday night, I want to drop my CRM data into a report template and get a board-ready deck, so I can enjoy my Sunday and not fake a smile Monday morning.”
- “When I’m pitching a prospect who’s skeptical about AI, I want to show them concrete case studies from their industry, so I can turn the call from ‘selling’ to ‘comparing notes.’”
Bad examples (features pretending to be jobs):
- “I want to use a beautiful dashboard”. That’s a feature.
- “I want faster reporting”. That’s a benefit.
- “I want JTBD-based tooling”. That’s marketing speak.
If your job statement doesn’t make you feel a specific person in a specific moment, rewrite it.
ShipFit and JTBD
ShipFit’s Stage 3 (What Hurts?) frames the problem as a hire statement, not a feature benefit. That statement anchors every downstream decision — who pays (Stage 2), what wins (Stage 4), what ships in V1 (Stage 5) — so the buyer’s actual job stays in view instead of getting buried under a feature list. Jobs framed as features produce different — and usually bigger — V1s than the same problem framed as a job.
Further reading
- Clayton Christensen & Bob Moesta, Competing Against Luck (2016). The canonical JTBD book
- Bob Moesta, Demand-Side Sales 101 (2020). JTBD applied to sales conversations
- The Mom Test. How to run the switch interviews without contaminating them
- Van Westendorp. Pairs with JTBD: JTBD tells you what job you’re winning, Van Westendorp tells you what to charge for it
Common mistakes
- Writing jobs as benefits or outcomes. 'save time' is not a job, it's a benefit. 'Get the monthly board report done by Friday without last-minute scrambling' is a job.
- Confusing jobs with personas. A persona is 'who.' A job is 'what they're hiring your product to do.' Same person has different jobs in different moments (buying coffee at 7am vs. at 3pm).
- Asking 'what do you want?'. Customers describe features (faster horse). Ask about past switches and the forces of progress instead.
- Over-scoping the job. 'run my business' is not a job, it's a life. Scope to something where progress is measurable in a session.
- Skipping the switch interviews. JTBD without talking to 10 recent switchers is a word game, not a framework.
- Treating JTBD as a replacement for Mom Test customer interviews. They're the same muscle. JTBD just sharpens the questions.
How ShipFit operationalizes this
ShipFit's Stage 3 (What Hurts?) uses JTBD to reframe the problem statement as a hire statement — 'when [context], the buyer wants to [job], so they can [outcome]' — rather than a feature list. The job statement then anchors every downstream stage: Stage 2's buyer economics, Stage 4's solution approaches, Stage 5's MVP feature scoring. A job framed as a feature ('help users manage their calendar') produces a different — and usually worse — V1 than the same problem framed as a job ('get to my next meeting on time without forgetting the prep').
ShipFit runs 55 frameworks across 9 decision stages
Jobs to be Done (JTBD) is one tool in a bigger toolkit. The full library covers market sizing, buyer discovery, MVP scoping, pricing, and launch.
The Mom Test
Q3Rob Fitzpatrick
Validation question methodology — real interviews, not theater
Jobs-to-be-Done
Q2-Q4Clayton Christensen
Functional, social, and emotional jobs your product fulfills
7 Powers
Q4Hamilton Helmer
Strategic moats: Scale, Network, Counter-positioning, Switching, Brand, Cornered Resource, Process
Van Westendorp PSM
Q6Feature-weighted price sensitivity analysis without guessing
Blue Ocean Strategy
Q4Kim & Mauborgne
ERRC framework: Eliminate, Reduce, Raise, Create
Fake Door Testing
Q7Pre-build behavioral validation with landing pages and apology modals
+ 49 more: TAM/SAM/SOM Analysis, Porter's Five Forces, Market Timing Analysis, Unit Economics (LTV/CAC)...
Frequently asked questions
What's the difference between a job, a persona, and a use case?
Clayton Christensen's milkshake example. What's the one-line summary?
How is JTBD different from user stories?
Can JTBD apply to B2B SaaS?
How many switch interviews is enough?
Is JTBD just a rebranded Theory of Use or Design Thinking?
Keep exploring
The 9-step playbook from market verdict to ship-ready spec.
The Mom Test is Rob Fitzpatrick's framework for customer interviews that generate real signal. Not praise. Three rules, applied step-by-step, with examples.
The Van Westendorp framework uses 4 questions to surface a defensible price range for any product. Here's how to run it, interpret results, and avoid the cheapest mistakes.
Most founder market research is a TAM slide that nobody believes. The numbers that actually matter are smaller, harder to defend, and tell you whether the market exists for the ten-customer version of your business.
Most founders confuse idea validation with idea-receiving-encouragement. The two have nothing in common. Here's what real validation looks like, and the four methods that actually produce it.
Does each customer make you money? Or cost you money?
Run nine framework-backed decisions in order before writing code: define the buyer, prove the pain is painful, name the winning angle, scope V1 to the smallest test of the hypothesis, get behavioral evidence (paid pre-orders, signed letters of intent, or credit cards on file from a Fake Door Test), then ship. Most failed startups skipped at least three of those nine. Plan to spend two to four weeks on this. It saves six to nine months of building the wrong thing.
For indie hackers who've wasted months on dead ideas. ShipFit forces 9 decisions before you write a line of code. Proven frameworks, exports to Cursor.
If you want a conversation partner, Buildpad. If you want to stop researching and ship, ShipFit. Both solve different problems for different founders. Don't pick on hype.
Ready to make your next product a success?
9 decisions between your idea and a product worth building.