Jobs to Be Done (JTBD)
Jobs to Be Done (JTBD) is a way of describing demand by the progress a customer is trying to make, rather than by who they are or which features they ask for. The unit of analysis is the job — the situation someone is in, the struggle that pushes them to look for something new, and the outcome they want — which is why two buyers with identical firmographics routinely hire completely different products for the same job.
What counts as a job
A job is not a task and it is not a feature request. It is the progress someone is trying to make in a particular circumstance, described so that it would still be true if your product had never existed. "Get the weekly numbers in front of my co-founder before Monday" is a job. "Export to CSV" is a feature that might serve it. The distinction is not pedantry — features are cheap to copy, and the job is the thing people keep paying for after the novelty wears off.
The frame comes with its own vocabulary: customers hire a product to do a job and fire it when something does the job better. That sounds like a gimmick until you notice what it forces you to admit. Your real competition is whatever they are hiring today, which is usually a spreadsheet, a freelancer, or doing nothing at all. A product losing to inaction is not losing on features, and no comparison table will fix it.
Where it differs from a persona
An ideal customer profile describes who the buyer is. A job describes what is happening to them. The two get confused constantly, almost always in the direction of the persona, because demographics and firmographics are far easier to collect than circumstances.
The practical test is which one changes a decision. "A 30-person B2B SaaS with a technical founder" does not tell you when to send an email or what the first line of the homepage should say. "Just inherited marketing, has no budget, and needs something to show at the next board meeting" tells you both. An ICP narrows who you talk to; a job tells you what to say to them, which is why it feeds positioning more directly. You want both, and typically only one of them is written down anywhere.
The switching interview is the useful part
Most JTBD material is framework: job statements, forces diagrams, outcome hierarchies. The part that reliably produces something you did not already believe is much smaller — interview people who recently switched to you, and reconstruct the timeline backwards from the moment they paid. What you are listening for:
- The first thought. When did this stop being tolerable? There is nearly always a triggering event, and it is rarely the day they signed up.
- What they tried first. The workaround that preceded you is your actual competitor, and it is usually free and already installed.
- The moment of shopping. What did they type into a search box? That vocabulary is your keyword list and your headline, and it is almost never the words your team uses internally.
- What nearly stopped them. Anxiety about switching and loyalty to the old habit push back against the purchase. Naming those two forces is how you write objection-handling that lands instead of arguing with a benefit.
- What "done" looked like. The outcome they used to decide it had worked — which is precisely the moment your onboarding should be sprinting toward.
How to use it without turning it into theatre
JTBD earns its keep as an interviewing discipline and loses it as a template. The failure mode is a workshop that produces a beautifully formatted job statement, generated from the team's existing assumptions rather than from customers, which nobody ever consults again. If the output of your JTBD exercise is a document, you did the version that does not work. If it is a changed headline, a re-ordered onboarding, or a decision not to build something, you did the version that does.
One observation from running AgentCeres — the AI Growth Officer at agentceres.com. We publish in eight languages and have run paid search in several markets, and the variable that best predicted whether someone came back on a later day was not company size, industry, or country. It was whether they arrived with a job already in motion — a specific piece of work in hand — rather than arriving curious. Same landing page, same product, and the behaviour sorted almost entirely on that. The corollary was just as useful: our clearest evidence that a market's job was shaped differently came from the search terms people used to find us, not from anything they told us afterwards. See which market should I launch in first.
FAQ
- Is Jobs to Be Done the same as a user story?
- No, though they look similar on the page. A user story is a unit of development work written from inside your product: as a user, I want to do X. A job is written from outside it and stays true whether or not you build anything — it describes the progress someone wants in a situation, including the workarounds and the emotional stakes. User stories are downstream: the job tells you which stories are worth writing.
- How many switching interviews do I need before it is useful?
- Fewer than most people expect. Five to ten conversations with people who recently switched usually surface the repeating triggers and the same two or three anxieties, and the returns fall off quickly after that. What matters far more than volume is recency and specificity: someone who bought last week and can walk you through the timeline is worth more than twenty people describing what they generally look for in a tool.
- Does JTBD replace an ICP?
- No. They answer different questions and you need both. The ICP is your targeting filter — who to advertise to, who to let into a beta, who to disqualify on a sales call. The job is your message — what to actually say once you have their attention. A common pattern is a correct ICP paired with a guessed job, which produces well-targeted traffic that does not convert.
- What if customers cannot articulate the job?
- That is the normal case, and it is why the method is a timeline reconstruction rather than a questionnaire. People are unreliable at explaining motivation and reliable at recalling sequence. Ask what happened, in order, from the first moment they noticed a problem to the moment they paid — what they searched, who they asked, what they tried and abandoned. The job is what you infer from the story, not what they hand you.
- Where does the framework come from?
- It has several parallel lineages rather than one author. Clayton Christensen popularised the framing in innovation research and made the milkshake example famous; Tony Ulwick's outcome-driven innovation formalised jobs into measurable outcome statements; and Bob Moesta's switch interview is where the practical timeline-reconstruction method comes from. They disagree on formalism, and it does not much matter for a small team — the interview is the part that transfers.
An AI growth team that runs this for you
AgentCeres is a managed AI marketing team — you approve what ships. 14-day free trial, from $39/month.