The framework is sound. The standard method assumes a research function you do not have — so here is the version that runs on eight interviews.
Jobs to be Done says people do not buy products, they hire them to make progress in a situation. The framework is sound. The standard method for applying it assumes dozens of interviews and a research function, which is why most solo founders read about it and never use it.
The output is one sentence. If you cannot write it, you do not have the job yet.
The central idea is that customers are not defined by demographics or firmographics but by the situation they are in. Two founders with identical companies can hire completely different products because their circumstances differ.
The practical consequence is that your competition is not who you think. A founder hiring your invoicing tool is choosing between you, a spreadsheet, their accountant, and doing nothing for another month. That set is the real competitive field, and three of those four are not software.
This connects directly to positioning, where the first component is naming the alternative you replace. JTBD is the research method that produces that name.
One sentence, three parts, and the discipline is in keeping it specific.
When [situation], I want to [motivation], so I can [outcome].
A weak version: "When I run my business, I want to send invoices, so I can get paid." That is a feature description wearing the format.
A useful version: "When a project wraps and I am already onto the next one, I want invoicing to take under two minutes, so I do not lose a week of cash flow to my own admin." That sentence tells you what to build, what to cut, and what the headline should say.
The difference is the situation. Vague situations produce vague products.
Standard JTBD research uses long switch interviews across a substantial sample. You can get most of the value from eight, if you choose the eight carefully.
Interview recent switchers only. People who started using you in the last three months, or who cancelled in the last three. Both remember the decision. People who have used you for two years have rewritten their own history.
Ask about the timeline, not the product. When did you first realise this was a problem? What did you try first? What made you look again? What nearly stopped you signing up? None of those questions mention features.
Listen for the trigger event. Almost every purchase has one — a bad month, a lost client, a new requirement, a system that broke. The trigger is the most actionable thing in the interview because it tells you when to reach people.
The customer interview guide covers the mechanics of running these without leading the witness.
JTBD models a purchase decision as four competing forces. Mapping yours explains most stalled trials.
| Force | What it is | Where you see it |
|---|---|---|
| Push | The problem with their current situation | Complaints, workarounds, spreadsheets |
| Pull | The appeal of your product | What they mention first when describing you |
| Habit | Comfort with what they already do | "It works fine, mostly" |
| Anxiety | Fear about switching | Migration questions, "does it export?" |
Most solo founders spend all their effort on pull — more features, better copy. Anxiety is usually the larger blocker and it is cheaper to fix: a clear export path, a migration guide, and a visible cancellation policy remove more friction than another feature does.
Three concrete changes, in order of impact.
Rewrite the headline in the customer's situation. Not what your product is, but the moment it matters. The situation clause of your job statement is usually the headline.
Redesign onboarding around the job, not the feature tour. If the job is invoicing in under two minutes, first-run should produce an invoice — see the onboarding framework.
Use it to refuse work. Feature requests that do not serve the job get declined. That is the main practical benefit of having written the sentence down, and it matters more the smaller your team is — prioritisation for one person covers the mechanics.
If eight interviews produce eight different jobs, you do not have a research problem — you have a segment problem. Pick the job that appeared among the customers who stayed longest and build for that one.
It tells you what people are trying to achieve. It does not tell you whether enough of them will pay, what to charge, or whether you can reach them. Those are separate questions — see the validation checklist for the ones that gate a build decision.
It also does not survive being run on prospects rather than customers. Hypothetical buyers describe hypothetical jobs, and the resulting sentence will be tidy and wrong.
Jobs to be Done holds that customers hire a product to make progress in a specific situation, rather than buying based on demographics or features. For SaaS it reframes your competition as everything the customer might do instead, including spreadsheets, freelancers and doing nothing.
Use the format: when [situation], I want to [motivation], so I can [outcome]. The discipline is in the situation clause — vague situations produce vague products. If the sentence reads like a feature description, the situation is not specific enough yet.
Eight is enough if you choose them carefully. Interview people who switched to you or away from you in the last ninety days, because recent switchers remember the trigger event. Long-term customers have rewritten their own history.
Push (the problem with their current situation), pull (the appeal of your product), habit (comfort with what they already do) and anxiety (fear about switching). Most founders over-invest in pull, when anxiety is usually the larger and cheaper blocker to remove.
That is a segment problem rather than a research problem. Pick the job that appeared among the customers who stayed longest and build for that one. Trying to serve several jobs at once is what produces a product that fits nobody particularly well.
Bring what your recent customers told you. Marcus writes the job statement and names what to change first.
Try GhostCoach free →14-day free trial · cancel anytime · 30-day money-back on Lifetime