What it is
Jobs to Be Done (JTBD) reframes discovery around the progress a customer is trying to make in a specific circumstance, rather than who they are demographically. The core idea: people don’t buy products, they “hire” them to get a job done — and that product competes against every other way the job could get done, including doing nothing at all, using a workaround, or hiring a competitor.
A job statement usually follows a simple structure: “When [situation], I want to [motivation], so I can [expected outcome].” For example: “When I’m switching tools mid-project, I want to migrate my data without losing history, so I can keep my team’s trust in the new system.”
When to use it
JTBD interviews are most valuable early in discovery, when you’re trying to understand why customers switched to your product, stuck with an old one, or churned. It’s especially useful for finding the real trigger behind a purchase decision — the moment of friction or frustration that made someone start looking for a new solution — which persona-based research often misses because it segments by who the customer is, not what they’re struggling to accomplish.
Common pitfalls
- Job statements that are really feature requests in disguise. “I want a dashboard” is a solution, not a job — the underlying job might be “I want to know if I’m on track without asking my manager.”
- Skipping the forces of progress. JTBD interviews are built to surface the push (dissatisfaction with the old way), pull (appeal of the new way), and anxieties/habits holding someone back — skip these and you’re left with a vague need statement instead of an actionable insight.
- Treating JTBD as a replacement for all other research. It’s a strong lens for switching behavior and motivation, not a substitute for usability testing or quantitative validation.