The JTBD interview template used by top product teams.
21 battle-tested questions that surface the causal story behind why customers change — the struggling moment, the trigger, the hiring criteria. Structured across four phases: warm-up, core JTBD, follow-up probes, and closing.
“Thank you so much for taking the time today. I'm going to ask you about your experience making a specific purchase or change in your work — not a product survey, more like a story you'll walk me through. There are no right or wrong answers. I'd love for you to be as specific as possible. Is that okay?”
Warm-up questions
Build rapport and map context · 5 questions · ~10 min
Can you walk me through your role and what a typical week looks like for you?
Why ask this: Gets context on their world without asking leading product questions.
What are the top 2–3 problems you're focused on solving right now?
Why ask this: Reveals what they consider important — often misaligns with what you assumed.
How does your team make decisions about what to build next?
Why ask this: Uncovers the decision-making context your product needs to fit into.
What tools are you currently using for [product category] — and how long have you been using them?
Why ask this: Maps the competitive landscape and surfaces switching friction.
Is there anything about your current setup that you've thought about changing recently?
Why ask this: Opens the door to the progress narrative without leading them to it.
Core JTBD questions
Surface the causal story · 8 questions · ~25 min
Think back to the moment you first decided you needed to do something differently. What was happening at the time?
Why ask this: This is the inciting event — the "struggling moment" that preceded purchase. Everything flows from here.
What specifically triggered that decision — was it an event, a piece of feedback, a conversation, a number you saw?
Why ask this: Narrows the triggering mechanism. Event-triggered decisions are more specific and actionable than gradual ones.
Before you changed anything, what did you try first? Walk me through what you looked at or considered.
Why ask this: Surfaces the passive and active alternatives — your real competitors, including doing nothing.
What were you hoping to accomplish — what would 'done' look like, if everything went perfectly?
Why ask this: This is the Job: the progress they were trying to make, independent of any solution.
Were there other people involved in this decision? How did their perspective shape what you did?
Why ask this: Maps the buying committee and reveals social/political forces that shape adoption.
When you eventually made a change, what made you choose that option over the alternatives you considered?
Why ask this: The hiring criteria — what your product needs to have or do to get hired for this Job.
Looking back, what friction or frustration was the biggest barrier between where you were and where you wanted to be?
Why ask this: Reveals the forces opposing progress — the anxieties and inertia your product needs to reduce.
If you hadn't made this change, what would have happened? What was at stake?
Why ask this: Quantifies the consequence — the pain of staying put. High-consequence jobs drive higher WTP.
Follow-up probes
Deepen key answers · 5 probes · use when needed
You mentioned [X] — can you say more about what you meant by that?
What did that feel like in the moment?
How did your team react when [X happened]?
If you had to guess what the root cause was, what would you say?
How often does that kind of thing happen?
Closing questions
Meta-insights and referrals · 3 questions · ~5 min
Is there anything about your decision-making process that you wished I'd asked about?
Why ask this: Catches the things you didn't know to ask.
If you were advising a product team building something for people like you, what's the one thing you'd want them to understand?
Why ask this: Surfaces their most important insight — often the most quotable moment of the interview.
Who else on your team or in your network might have a similar perspective I could speak with?
Why ask this: Snowball sampling — the most efficient way to book your next five interviews.
Run these interviews on autopilot.
Alex sends and conducts JTBD interviews automatically — scheduling with customers, running the conversation, and synthesising findings into structured insights in your Product Graph. No PM time required for the first pass.
What is the Jobs to be Done (JTBD) framework?
Jobs to be Done is a theory of customer motivation developed by Clayton Christensen and refined by Bob Moesta. The central insight is that customers don't buy products — they hire products to help them make progress in their lives. When you buy a milkshake on the way to work, you're not hiring it for its nutritional value; you're hiring it to keep you occupied during a boring commute. Understanding the Job — the specific progress a customer is trying to make in a specific circumstance — gives you a far more accurate and stable unit of analysis than demographics or use cases. Demographics change. Jobs don't. A 32-year-old VP of Product and a 55-year-old founder hiring the same product for the same Job are the same customer for your purposes.
Why JTBD interviews are different from regular user research
Most user research focuses on what users do and what they like. JTBD interviews focus on why they changed — the causal mechanism behind a purchase or behaviour shift. This distinction matters enormously. Watching someone use your product tells you about their current behaviour. A JTBD interview tells you about the forces that caused them to change behaviour in the first place: the struggles that pushed them away from the status quo, the pull of a better vision, the anxieties about switching, and the habits that made them cling to what they had. This four-force model (push, pull, anxiety, habit) gives you actionable insight that usability testing never will. It tells you not just what to build, but what problem to solve and how to position it.
How many JTBD interviews do you need?
The standard guidance is 5–10 interviews per Job. In practice, you'll start hearing the same stories after 6–8 interviews with similar customers. The goal is pattern saturation — the point at which new interviews stop revealing new causal structures. The key constraint is customer segment: interviews across different Jobs or personas don't compound. Five interviews with enterprise buyers and five with self-serve users give you ten data points across two Jobs, not ten data points on one. If you're building for multiple segments, run dedicated interview sprints for each. Specky's AI research agent, Alex, can conduct JTBD interviews automatically at scale — synthesising patterns across dozens of conversations into structured insight without PM time.
Common JTBD interview mistakes to avoid
- Asking hypothetical questions ("What would you do if...?"). JTBD only works with specific past events.
- Steering toward your product or solution. Keep questions focused on their experience, not your offering.
- Accepting vague answers. Press for specifics: dates, events, conversations, numbers. "Recently" isn't a timeline.
- Skipping the struggling moment. Most interviewers jump straight to "what did you choose?". The value is in what happened before that.
- Stopping at the functional Job. The emotional and social dimensions ("I wanted my boss to trust me", "I needed my team to stop bothering me about this") are often the real purchase drivers.