CX Methods
Jobs-to-be-done still needs real research
JTBD tells you what customers hire you to do, but only real customer research can tell you that. Fund the interviews or the framework is fiction.
Jobs-to-be-Done is a powerful lens for understanding what customers are really trying to achieve. But some advocates sell it as a shortcut around customer research, and that claim is wrong. The framework runs on field evidence; without it, job statements are guesses with better branding.
Jobs-to-be-Done (JTBD) is a way of framing what customers really want: not your product, but the outcome they hire it to achieve. Some advocates pitch it as a replacement for customer research: skip the interviews, workshop the job statement, move fast. That claim is wrong. JTBD and task analysis are complementary methods that produce different artifacts. JTBD names the outcome a customer wants; task analysis maps the steps and context in which they pursue it. Both run on qualitative research with real customers. Remove the research and both collapse into guesswork.
Why it matters to the business
Companies are reliably wrong about what their customers experience and want. Bain's 'Closing the Delivery Gap' study found 80% of companies believed they delivered a superior experience, while only 8% of their customers agreed. That gap is what happens when internal belief substitutes for field evidence. A job statement invented in a conference room inherits the same distortion, and every roadmap decision built on it inherits it too.
The good news: the research JTBD needs is not expensive. Jakob Nielsen's Nielsen Norman Group research found that five users uncover about 85% of usability problems in qualitative testing. A handful of disciplined customer conversations per segment is usually enough to separate real jobs from imagined ones.
How to use it
- Budget research into every JTBD adoption. Treat a job statement without interviews behind it as a hypothesis, not a finding.
- Interview recent switchers first. Ask why they fired their old solution and what they hoped the new one would do.
- Probe goals, frustrations, and workarounds. A workaround is a job your product is failing at in plain sight.
- Pair JTBD with task analysis: the job names the destination, the task analysis maps the route and its friction.
- Cross-check job statements against behavioral data such as support logs, search queries, and drop-off analytics.
Where teams get it wrong
Research avoidance gets disguised as agility. A team workshops a job statement in an afternoon, ships against it for two quarters, then discovers in the market that customers were hiring the product for something else entirely. Speed without evidence is not fast; it just moves the cost of being wrong downstream, where it is largest.
Ask your team
- How many customers did we actually speak to before writing this job statement, and can I see the notes?
- When did we last watch a customer attempt this job end to end?
- Which of our current bets rest on validated jobs, and which on assumed ones?
Research avoidance is often disguised as agility.
Apply this
Reading about jobs-to-be-done still needs real research is one thing. Seeing where it applies in your journey is the useful part.