A framework that frames user needs in terms of the underlying progress a person is trying to make in a specific circumstance, rather than their demographics or stated preferences. For example: 'When I'm commuting, I want to catch up on news so I feel informed when I arrive.'
Common contexts
- Reframing a feature brief away from 'users aged 25–34 want notifications' toward the circumstance that drives the need
- Running switch interviews with churned users to understand what job the product failed to do
- Aligning a product roadmap by mapping proposed features to distinct jobs rather than user demographics
Use when
Use JTBD when your persona-based research keeps producing features that test well but don't move retention — it often surfaces that the product is solving the wrong version of the right problem.
Avoid when
Don't use it as a replacement for usability research — it explains what people are trying to accomplish but tells you nothing about whether your interface lets them accomplish it.
The most revealing JTBD insight rarely comes from asking what users want — it comes from asking what they were doing before they found your product and why that stopped working.
Real-world examples
- McDonald's JTBD research revealed that morning commuters 'hire' milkshakes to keep one hand occupied and feel satiated on long drives — not for taste — leading to a thicker, straw-free redesign.
- Intercom restructured its entire product roadmap around customer jobs ('onboard new users', 're-engage churned customers') rather than features, which they credit for doubling ARR in two years.
- Basecamp discovered through JTBD interviews that project managers' primary job was 'knowing where things stand at a glance', not 'managing tasks' — a distinction that shaped their entire information hierarchy.