JTBD Interview: Map the Job, Ignore the Persona

WHY IT EXISTS: Traditional user research often sorts people into personas or asks them to predict future behavior, which produces unreliable wishlists. JTBD theory assumes that people do not buy products; they hire them to make progress in specific circumstances. The interview exists to uncover that causal story so teams build for the job instead of the demographic.

THE MENTAL MODEL: Think of a JTBD interview as a crime-scene reconstruction rather than a preference survey. You are not asking what someone likes; you are asking what changed in their life that caused them to stop using one solution and start using another. The job is the progress they were trying to make, not the tool they used.

HOW IT WORKS: The interviewer maps a switching timeline. Start with the purchase or adoption moment, then work backward to the first thought that something was wrong with the old way. Probe for the struggling moment, the criteria they used to evaluate alternatives, and the anxieties that almost blocked them. Keep questions concrete and focused on the story, not hypotheticals. If the participant starts predicting what they might do in the future, redirect to what they actually did.

WHEN TO USE IT: Use this method when you are exploring a new market, diagnosing why a product is not gaining traction, or understanding the true competitor set, which often includes DIY spreadsheets and manual workarounds rather than direct rivals. It is especially powerful for innovation work where existing category boundaries are misleading.

WHEN NOT TO USE IT: Do not use a JTBD interview when you need usability feedback on an existing interface, quick validation of a color scheme, or quantitative proof of market size. It is also a poor fit if your team is not ready to act on qualitative narratives, because the output is a set of forces and timelines, not a prioritized feature list.

ONE CANONICAL EXAMPLE: A team building project management software might interview a user who recently switched from a spreadsheet to their tool. Instead of asking about the user's role or desired features, they reconstruct the day a deadline was missed because the spreadsheet version was overwritten. That struggling moment reveals the job was not organizing tasks; it was maintaining a single source of truth under time pressure. The team realizes their real competition is not other PM tools but the inertia of shared documents.