TL;DR

  • A JTBD interview is a switch interview, not a user interview. You are asking about the moment they switched from their old solution to yours — what pushed them away, what pulled them toward you, and what almost stopped them.
  • The switch has 4 phases: First Thought, Passive Looking, Active Looking, and Switch. Each phase has specific questions. The goal is to reconstruct the timeline, not to get opinions.
  • The most important question: "What was happening in your work that made you start looking for a new solution?" This reveals the trigger, the context, and the desired outcome — the 3 components of a job statement.
  • Avoid hypothetical questions, satisfaction scales, and feature preference questions. These produce opinions. The switch moment produces insights.
  • You need 10-15 switch interviews. After 10, you will hear the same job statement repeated with different words. That repetition is your signal that you have found the core job.

Why Switch Interviews, Not User Interviews

Most teams get it wrong.

Most product teams interview customers like this: "What do you like about our product?" "What would you improve?" "How satisfied are you on a scale of 1 to 10?"

These questions produce opinions, not insights.

Key metric: the central data point from this analysis
Key metric: the central data point from this analysis

Opinions change. Insights do not.

When you ask customers what they think of your product today, you get a snapshot of their current mood. When you ask them about the moment they switched, you get the actual reasons they hired your product.

A switch interview asks about a specific moment in the past: the moment the customer changed their behavior. This moment is real, not hypothetical. It actually happened.

Framework overview: the structured approach covered in this article
Framework overview: the structured approach covered in this article

And it reveals the job the customer was hiring your product to do — because they already hired it. They just need to tell you why.

The switch interview is the highest-ROI research activity a product team can do. One hour. One customer. One story. And you learn more about why your product matters than you would from 100 survey responses.

The concept of the switch interview was developed by Bob Moesta and Chris Spiek while working with Clayton Christensen's research team at Harvard Business School.

The methodology was designed to capture the actual causal mechanism behind customer behavior — not what customers say they want, but what they actually did and why.

The distinction matters because the job your product was hired to do is rarely the job you think you were hired to do.

Customers hire solutions for reasons that often have nothing to do with your feature roadmap. The switch interview is the tool that surfaces that gap.

The 4 Phases of the Switch

The timeline is always the same.

Every customer goes through the same 4 phases when switching from one solution to another. Understanding this timeline is what makes the interview structured instead of a free-form conversation.

Your job as the interviewer is to reconstruct each phase. The timeline matters because the job lives in the sequence — not in any single answer.

Phase What Is Happening What to Listen For
First Thought Something was not working with the old solution The trigger, the context, the push factor
Passive Looking Started paying attention to alternatives How they discovered options, what stood out
Active Looking Started evaluating options seriously Real evaluation criteria, not stated preferences
Switch Made the decision and committed The final push, the anxieties overcome, the validation

The Opening (1 minute)

Set the frame immediately. Tell the customer you want the story of how they got here — not their current opinion of the product.

"Thanks for making time. I want to understand the story of how you started using [product]. Not what you think of it now — the story of how you got here. There are no wrong answers. I am going to ask you to remember specific moments."

The opening sets the contract. If you ask for opinions, you get opinions. If you ask for the story, you get the timeline — and the timeline is where the job lives.

Phase 1: First Thought (5 minutes)

The goal here is to find the trigger. What made them realize the old way was not working?

Anatomy of a JTBD Trigger: Context, Push, Desired Outcome
Anatomy of a JTBD Trigger: Context, Push, Desired Outcome

"Take me back to before you started using [product]. What were you using before?"

"How long had you been using that?"

"What was happening in your work that made you start thinking about changing?"

"Was there a specific moment when you thought 'this is not working anymore'? What happened?"

Listen for the context (situation), the frustration (push), and the desired outcome (what they wanted instead). These 3 elements are the building blocks of your job statement.

The trigger is never a feature complaint. It is always a moment of frustration — a specific situation where the old way stopped working. That moment is the seed of your job statement.

Phase 2: Passive Looking (5 minutes)

Now you want to understand what alternatives they became aware of and why. This reveals the competitive landscape from the customer's perspective.

"Once you started thinking about changing, what did you start paying attention to?"

"Did you notice other products or approaches? How?"

"What made you notice them? A colleague? An ad? A Google search?"

"What stood out to you about the alternatives?"

Listen for the competitive landscape from the customer's perspective — not your competitors' feature lists, but what the customer noticed and cared about.

Customers do not discover products the way marketers think they do. The channels and triggers that actually lead to a switch are rarely the ones your marketing team is optimizing for.

Phase 3: Active Looking (10 minutes)

This is where you understand their real evaluation criteria. The criteria that drive purchase decisions are often different from the criteria customers say matter in surveys.

Stated preferences from surveys vs. real evaluation criteria from switch interviews
Stated preferences from surveys vs. real evaluation criteria from switch interviews

"When did you go from 'maybe I should look' to 'I am going to look'?"

"What options did you seriously consider?"

"How did you evaluate them? What mattered to you?"

"Did you do a trial? A demo? Talk to other users?"

"What surprised you during the evaluation?"

Listen for the criteria that actually drive purchase decisions — which are often different from the criteria customers state in surveys.

The evaluation criteria customers describe in the interview are rarely the criteria they used at purchase. The real criteria surface through the story of what they compared, not through direct questions about what matters.

Phase 4: Switch (10 minutes)

Find the final push. The moment of decision. The anxieties they overcame and the validation that confirmed they made the right choice.

"What was the moment you decided to go with [product]?"

"What almost stopped you from switching? What was the biggest concern?"

"What convinced you to go ahead anyway?"

"If [product] did not exist, what would you have done?"

"Looking back, was it the right decision? What confirmed it for you?"

Listen for the anxieties, the anxieties overcome, and the post-switch validation. The anxieties tell you what barriers to address in your marketing. The validation tells you what job your product actually serves.

The anxieties customers overcame are the objections your marketing and sales teams need to answer proactively. The "if it did not exist" answer reveals your closest alternative — not your closest competitor.

Free Resource

Download the Full Switch Interview Script Template

All 4 phases, all questions, and the probe guide in one table you can use in your next research session.

What the Research Shows

The switch interview methodology has been validated across hundreds of implementations by product teams at companies ranging from early-stage startups to enterprise organizations.

The pattern is consistent: teams that run switch interviews find jobs their roadmaps were not addressing.

According to Nielsen Norman Group's research on JTBD interviews, the most common mistake teams make is treating discovery interviews as usability tests or satisfaction surveys.

Their guidance is clear: the interview should focus on the customer's situation before using the product, not their opinions about current features.

"The goal of a JTBD interview is to understand the context and circumstances that lead people to 'hire' a product or service to do a 'job.' Ask about past behavior and the circumstances that led to it, not about future preferences or current satisfaction."

— Nielsen Norman Group, JTBD Interviews: Research-Based Guidance

SVPG's analysis of the switch interview process emphasizes that the methodology works because it captures the functional, social, and emotional dimensions of the job simultaneously.

Traditional surveys can measure satisfaction but cannot reconstruct the causal chain that led to a decision.

10-15

Switch interviews with retained customers is the sweet spot. After 10 interviews, you will hear the same job statement repeated with different words. That repetition is your signal that you have found the core job.

The pattern across mid-market SaaS companies that have adopted switch interviews is consistent.

Teams report that after conducting 10-15 interviews, the job statement stabilizes — the same underlying job emerges from different customers using different words. This repetition is the validation signal that quantifies research is missing.

Customer Science's work on JTBD interview templates provides a structured checklist that helps teams prepare before each session.

Their framework includes prompts for identifying the 3 types of jobs: functional (the task to be done), emotional (how the customer wants to feel), and social (how the customer wants to be perceived).

The Business of Software guide on JTBD interviewing emphasizes that the interviewer's role is to remain neutral.

They specifically warn against leading questions that signal what answer you want. The goal is to let the customer's story emerge, not to confirm your assumptions.

ForgetTheFunnel's research on JTBD interview questions includes a specific note on the "hiring" and "firing" language that makes the job statement concrete.

Their email template for recruiting interview participants uses this framing explicitly: "We are looking for customers who switched to [product] from another solution."

The validation signal in switch interviews — hearing the same job repeated across different customers — is not anecdotal. It is a structural property of the methodology. When the job stabilizes, you have found the right unit of analysis for your product strategy.

See It In Practice

ProductQuant Conducts Switch Interviews for Your Team

We run the 4-phase switch interview process, synthesize findings, and deliver the job statements your roadmap team can actually use. No methodology theater. No decks. Just the jobs.

What to Do Instead

If you are currently running satisfaction surveys, feature request sessions, or NPS follow-ups, you are collecting data that does not tell you why customers hired your product.

Here is what those methods produce and why they fail:

Satisfaction Surveys

Satisfaction surveys measure the customer's current emotional state. They do not reveal the job.

A customer who is satisfied today may have hired your product for a different job than a customer who is dissatisfied. You cannot compare them without understanding the underlying job each was trying to do.

What to do instead: Run a switch interview with both customers. You will learn that the satisfied customer and the dissatisfied customer hired the product for different jobs. Now you have an actionable segmentation — not a satisfaction score.

Feature Request Sessions

Feature requests tell you what customers think they want. They do not tell you what job they need done.

Diagram showing the gap between a customer feature request and the actual job to be done

A customer who requests "better reporting" may actually need "to get my team aligned before the Monday standup" — a different job entirely. Adding reporting features addresses the stated request but may not address the actual job.

What to do instead: Ask the customer who requested better reporting to describe a recent situation where they needed to get their team aligned. Probe the timeline. You will discover the job behind the feature request. Now your roadmap addresses the actual job, not the symptom.

NPS Follow-Up Calls

NPS follow-ups typically ask "Why did you give this score?" The answers are opinions, not insights.

A customer who gave a 9 and a customer who gave a 6 may have hired your product for the same job — but one is more satisfied today. The score does not tell you what job to optimize for.

What to do instead: Recruit NPS responders for switch interviews regardless of their score. The 9 and the 6 may tell you different things about the same job. One may be more satisfied because their job is fully addressed. The other may be less satisfied because a different aspect of the job is not addressed. Now you have a product strategy, not a satisfaction metric.

Usability Testing

Usability testing tells you whether customers can use your product. It does not tell you whether your product is doing the right job.

A product can be perfectly usable and still be hired for the wrong job — or fail to be hired at all because it does not address the actual job customers need done.

What to do instead: Before usability testing, run switch interviews to understand the job. Then your usability testing has a frame: "Does this design help customers do the job they hired us for?" Without that frame, usability testing is decoration.

Every research method that asks customers about your product today produces a snapshot. Only the switch interview produces the causal story — and the causal story is what connects product strategy to customer behavior.

FAQ

How many switch interviews do I need to run?

The sweet spot is 10-15 interviews with retained customers. After 10 interviews, you will start hearing the same job statement repeated with different words. That repetition is your signal that you have found the core job. More interviews after that point produce diminishing returns — you are just confirming what you already know.

Should I interview customers who churned or only retained customers?

Both, but for different reasons. Retained customers tell you why your product was hired — what job it is doing. Churned customers tell you why your product was fired — what job it failed to do. Both insights are necessary for a complete picture of the job map. However, the retained customer interview is the primary switch interview. The churned customer interview is a related but distinct methodology.

How long should a switch interview take?

Plan for 45-60 minutes. The opening takes 1-2 minutes. Each phase takes 5-10 minutes. Leave 5-10 minutes at the end for follow-up probes. Do not rush the timeline reconstruction — the sequence is where the job lives. If you finish early, probe deeper on the moments that seemed most revealing.

Who should conduct the switch interviews?

Ideally, the person who will act on the findings. If that is the product manager, they should conduct the interviews. If that is a researcher, they should conduct the interviews and present synthesized findings. The key requirement is that the interviewer stays neutral and does not lead the customer toward expected answers. Training on the methodology is essential — the Business of Software guide on JTBD interviewing specifically addresses interviewer neutrality.

How do I recruit customers for switch interviews?

Use the "hiring" and "firing" framing in your recruitment outreach. Specifically recruit customers who switched to your product from another solution — including switching from no solution (building something manually) to your product. The email template from ForgetTheFunnel uses this framing: "We are looking for customers who switched to [product] from another solution." This framing produces better interview subjects than generic "would you like to share feedback" invitations.

What is the difference between a switch interview and a standard user interview?

A user interview asks about the product today. A switch interview asks about the moment of change. The distinction is not semantic — it is methodological. User interviews produce opinions and satisfaction data. Switch interviews produce causal stories. The causal story is what connects customer behavior to product strategy. Nielsen Norman Group's research specifically recommends switch-style questions for JTBD interviews: "Ask about past behavior and the circumstances that led to it, not about future preferences or current satisfaction."

Sources

Jake McMahon

About the Author

Jake McMahon is the founder of ProductQuant. He holds a Master's in Behavioural Psychology and Big Data, which shapes how he approaches the intersection of customer research and product strategy. Based in Tbilisi, Georgia, he works with SaaS teams that need to understand why customers make the choices they do — not just what those choices are. His work focuses on switch interview methodology, job statement synthesis, and connecting JTBD findings directly to product roadmap decisions. Before ProductQuant, he spent years refining the behavioral frameworks that now underpin the firm's research practice.

Next Step

Get the Full Switch Interview Script

All 4 phases, all questions, and the follow-up probe guide in one table. Download it, print it, use it in your next research session.