Visit Website →
← Back to blog

10–15 JTBD Interviews That Fuel a Phase 0 Build Plan for Founders

September 4, 2026
10–15 JTBD Interviews That Fuel a Phase 0 Build Plan for Founders

A JTBD interview reconstructs the exact day a customer switched from their old solution to yours, then maps four forces (push, pull, anxiety, habit) that drove the change. Done well, it produces a ranked list of causes behind switching behavior, not opinions about features. Expect a 45 to 60 minute conversation with someone who switched recently, not a survey.

TL;DR:

  • Running recent switchers within 30 to 90 days ensures more accurate recall of the forces behind their decision, reducing memory compression issues.
  • Using backward timeline walks, participants reconstruct their switching event with specific sensory and contextual details, revealing true motivations.
  • A sample size of 10 to 15 interviews per customer segment typically uncovers the dominant forces driving switching behavior, with saturation reached around 12 interviews.
  • Asking behavior-specific, past-tense questions about what happened rather than opinion-based or hypothetical prompts yields more actionable insights.
  • Converting insights into a structured build scope or market model helps turn qualitative forces into prioritized product and messaging strategies.

Table of Contents

What Makes a JTBD Interview Different From a Discovery Call?

Most product interviews ask people what they want. A jobs to be done interview asks what already happened, and it treats the switch event, not the person, as the unit of analysis. You are not building a persona. You are reconstructing a specific Tuesday afternoon when someone got fed up enough to cancel one thing and sign up for another.

That distinction changes everything about how you structure the conversation. Instead of "What features matter to you?" you ask "Walk me through the day you decided to switch." The answer surfaces the four forces that Bob Moesta and the JTBD community formalized decades ago:

  • Push: what's actively wrong with the old solution (a broken workflow, rising cost, a missed deadline)
  • Pull: what's attractive about the new option (a specific feature, a recommendation, a demo moment)
  • Anxiety: what almost stopped the switch (fear of migration pain, data loss, learning curve)
  • Habit: what kept them with the old solution longer than they should have stayed (sunk cost, comfort, inertia)

The canonical teaching example is the mattress interview transcript, where Moesta interviews a mattress buyer and walks the timeline back from the purchase to the exact night the old mattress became unbearable. It sounds mundane. It's actually a masterclass in getting someone to relive a decision instead of summarizing it.

This differs sharply from usability testing or generic discovery interviews, which optimize for present-tense reactions to a prototype or an existing product. JTBD interviews live in the past tense almost entirely. You're not asking "Would you use this?" You're asking "What did you do, and when, and what were you thinking right before that?" Microsoft's research group has described jobs to be done as a framework for aligning teams around outcomes rather than features, and the switch interview is the primary tool for extracting those outcomes from real behavior instead of guesswork.

How Do You Structure a Switch Interview Step by Step?

The structure matters more than the questions. A switch interview follows a predictable arc: build rapport, establish the timeline, walk backward from the switch moment, then probe each force as it surfaces. Here's the breakdown for a standard 45 to 60 minute session.

  1. Warm-up and consent (3 to 5 minutes). Confirm you're recording, explain the conversation is about their experience switching, and ask permission for the audio to be reviewed by your team.
  2. Timeline anchoring (10 to 15 minutes). Ask them to name the day they actually made the switch, then walk backward: "What were you using the week before? The month before? When did you first notice something was off?" This backward walk is the single most important technique in the whole method, because forward narratives get rationalized and cleaned up.
  3. Struggling moment excavation (10 to 15 minutes). Once you locate the specific trigger event, dig into it hard. Who was in the room? What time of day was it? What had just happened? Specificity here is the tell that you've hit a real memory instead of a summarized story.
  4. Force mapping (10 to 15 minutes). Work through push, pull, anxiety, and habit in whatever order the conversation naturally surfaces them. Don't force a checklist order. Follow energy: if they light up talking about a competitor's onboarding email, stay there before moving on.
  5. Product-specific questions (5 to 10 minutes). Only now do you ask anything about your actual product. Asking earlier contaminates the switch narrative with performance-review answers about your features.
  6. Wrap and thanks (2 to 3 minutes). Confirm you can follow up, thank them, stop recording.

Pro Tip: Never ask "What would make this better?" during the timeline walk. Save all forward-looking, hypothetical questions for the last five minutes. Mixing past-tense reconstruction with future-tense speculation in the same breath is the fastest way to collapse a good interview into generic feedback.

The backward-walk technique deserves extra attention because it's counterintuitive. Most interviewers ask "Tell me about switching to us" and let the story run forward. That produces a tidy, socially acceptable narrative. Asking someone to start at the switch date and walk backward in time forces them to reconstruct rather than perform, and it's where the real anxiety and habit details show up, usually the parts they'd otherwise skip.

How Do You Structure a Switch Interview Step by Step? — overview diagram

Who Should You Recruit for JTBD Interviews?

Recruit people who switched in the last 30 to 90 days, not longtime customers. Memory degrades fast, and someone who switched two years ago has replaced their real reasoning with a simplified story that sounds better in hindsight. Research on JTBD interviews for B2B SaaS calls this memory compression, and it's the single biggest reason otherwise well-run interviews produce mushy, unusable insights.

Three participant pools work well for jobs to be done interview recruitment:

  • Recent switchers-in: people who chose your product in the last one to three months, when the switch story is still fresh
  • Churned accounts: people who left you for a competitor or reverted to a manual process, which surfaces your own push and anxiety forces
  • Active evaluators: people currently comparing you against alternatives, useful for pull and anxiety forces in real time rather than in retrospect

Avoid recruiting your happiest, longest-tenured users for switch interviews. They'll give you loyalty commentary, not causal data. If you want retention insights, that's a different interview with a different unit of analysis.

On sample size, a widely cited heuristic from practitioner circles suggests 10 to 15 interviews per segment usually surfaces the dominant patterns, with most teams seeing real saturation by interview 10 to 12. Beyond that point, you're mostly hearing variations on forces you've already mapped. That number holds per segment, not per project. If you serve three distinct customer segments with different jobs, budget for three separate rounds.

B2B research adds a wrinkle: the person who signs the contract, the person who champions the tool internally, and the person who actually uses it daily often have three different jobs, three different pushes, and three different anxieties. Mapping the buying committee is not optional in B2B contexts. Interview at least a handful of each role rather than assuming the champion's story represents the account.

What Questions Actually Surface the Four Forces?

Generic questions produce generic answers. The questions that work are specific, past-tense, and anchored to a moment in time rather than a general opinion. Here's a working template broken out by force, plus the follow-up probes that turn a vague first answer into something usable.

Opening and timeline anchors:

  • "What day did you actually sign up or switch? Walk me back from there."
  • "What were you using the week before that? What about a month before?"

Push probes (what was broken):

  • "What happened right before you started looking for something new?"
  • "Describe the last time the old tool actually failed you. What were you doing?"

Pull probes (what attracted them):

  • "How did you first hear about us? What was that moment like?"
  • "What was the thing that made you think 'okay, this might actually work'?"

Anxiety probes (what almost stopped them):

  • "What almost made you not switch?"
  • "Who else weighed in before you made the decision, and what did they say?"

Habit probes (what kept them stuck):

  • "How long had the old way been bothering you before you actually did something about it?"

Follow-ups matter more than the initial question. If someone says "it was just time for a change," don't accept it. Ask "What was happening that Tuesday specifically?" or "Who was in the room when you decided?" Vague answers almost always crack open with one more layer of specificity.

Pro Tip: Ban hypothetical phrasing entirely during the core interview. "Would you switch if we added X?" produces speculative fiction, not data. "What made you switch when you did?" produces a true story you can act on.

Avoid questions like "What do you like about our product?" or "What features are missing?" These are opinion prompts wearing a JTBD costume. They'll get you a feature wish list, which is exactly what the switch interview method exists to move past.

Should You Run Interviews Live, Async, or Both?

Live interviews of 45 to 60 minutes remain the gold standard because a skilled moderator can follow energy in real time and push on a vague answer immediately. But live sessions are hard to schedule, especially with busy B2B buyers, and that scheduling friction is the main reason teams under-recruit.

Async voice prompts are the practical middle ground. You send a structured set of voice questions, the participant records answers on their own time, and you still get the audio artifact without a live scheduling dance. The trade-off is real: you lose the ability to probe in the moment, so async prompts need to be designed with built-in follow-up branches that anticipate common hesitations before they happen.

Written surveys are the weakest format for JTBD work and should be avoided for anything beyond initial screening. Text strips out tone, pacing, and hesitation, which is exactly the information you need.

Audio matters more than most teams expect. Listening to the actual recording, not just reading a transcript, reveals pauses before a hard question, a laugh that signals discomfort, or a change in tone right as someone hits the real trigger event. Talkful's research on running JTBD interviews points out that these energy signals routinely get lost in text, which means transcript-only analysis quietly discards half the evidence.

Practical tooling patterns worth adopting:

  • Record every session, live or async, and get explicit consent before hitting record
  • Use a transcription tool for searchability, but treat the transcript as an index, not the source of truth
  • Schedule a team listening session within a day or two of each interview while memory of tone is fresh
  • Keep a shared repository of clips organized by force (push, pull, anxiety, habit), not just by participant

How Do You Turn Interview Transcripts Into Decisions?

Raw interviews are not insights. You need a repeatable process to convert ten to fifteen conversations into a short list of things worth building or messaging differently.

How Do You Turn Interview Transcripts Into Decisions? — overview diagram

Start with a timeline and forces map for each individual interview. Lay out the chronology from "first noticed a problem" to "actually switched," and tag each moment with the force it represents. This single-interview artifact is worth doing even if you never look at it again, because building it forces you to notice gaps in your own note-taking.

Then synthesize across interviews. Look for forces that repeat across five or more participants in the same segment. A push force that shows up once is an anecdote. A push force that shows up in nine of twelve interviews is a pattern worth acting on. Microsoft's research group has described JTBD as producing more predictive insight than feature-led discovery precisely because it clusters around causal patterns rather than individual preferences.

Practitioner guidance consistently points to interview 10 through 12 as the point where new forces stop appearing and existing ones just get restated, which is your practical signal to stop recruiting for that segment and start acting on what you have.

Concrete deliverables to produce from a completed round:

  • A ranked list of push forces, ordered by how many interviews surfaced them
  • A shortlist of pull moments worth turning into landing page copy or ad creative
  • A prioritized backlog of anxiety-reducing product changes (onboarding fixes, migration tools, trial extensions)
  • Two or three testable messaging hypotheses drawn directly from participants' own language

JTBD findings work best paired with quantitative follow-up. If nine interviews surface the same push force, run a survey to size how common that trigger is across your broader customer base before betting a roadmap on it. Combining switch interviews with win-loss analysis on sales deals adds another layer of confirmation, especially in B2B contexts where the buying committee complicates a single-voice narrative.

What Are the Biggest Mistakes Teams Make Running These Interviews?

Most failed JTBD interviews fail for the same handful of reasons, and nearly all of them are fixable with better recruiting or better interview discipline.

Recruiting long-term, happy customers instead of recent switchers. This produces loyalty stories, not causal data. Fix it by screening specifically for a switch date within the last 90 days.

Asking leading or hypothetical questions. "Would you like it if we added a dashboard?" invites polite agreement, not truth. Fix it by keeping every core question past-tense and behavior-specific.

Conflating the job with a feature request. When a participant says "I wish it had better reporting," that's a feature ask, not a job. Push one layer deeper: "What were you trying to accomplish when reporting let you down?"

Skipping the timeline walk and jumping straight to opinions. Without the backward walk, you get summarized narratives instead of reconstructed memory. Fix it by never skipping the anchoring phase, even under time pressure.

Failing to detect memory compression in real time. If answers feel suspiciously clean and quick, that's often a sign the participant switched long ago and has replaced the real story with a rehearsed one. Salvage the session by asking for extremely specific sensory or contextual details (time of day, who else was present) to test whether the memory is real or reconstructed after the fact.

Before every round, run a quick interviewer bias checklist: are you asking anything the participant could answer to please you rather than to describe what actually happened?

Can You Scale JTBD Interviews Without Losing Quality?

Async voice and lightweight AI-assisted probing are changing how teams run JTBD research, but the fundamentals haven't moved. Async voice prompts preserve the audio artifact, which matters more than almost any other design choice, while removing the scheduling bottleneck that kills recruitment velocity in busy B2B segments.

AI tools can help draft adaptive follow-up branches for async formats or flag which recorded answers sound vague enough to need a manual follow-up call. What AI cannot do reliably yet is catch the subtle tonal shift that signals someone just hit a real anxiety trigger. Modern implementations experimenting with async and AI-assisted synthesis still keep a human moderator in the loop for exactly that reason.

Ethics matter here too. Always get explicit consent before recording, be direct about how the audio will be used internally, and avoid recruiting language that signals what answer you're hoping to hear ("Tell us why you love switching to us" is a leading recruitment pitch, not a neutral one).

Pro Tip: Run a lightweight two to four week program: week one for recruitment and screening, weeks two and three for 10 to 15 interviews, week four for synthesis and a team listening session. That cadence fits inside most product planning cycles without stalling other work.

How JTBD Findings Feed Phase-0 Planning

A completed forces map isn't the finish line. It's raw material for scoping. Once you know your dominant push forces and the anxieties blocking adoption, those become inputs for sizing a market opportunity, prioritizing an MVP feature set, and drafting the messaging your pitch deck actually needs.

Some founders feed JTBD interview outputs, timeline maps, push and pull lists, anxiety-reduction ideas, directly into a connected phase-0 model covering TAM/SAM/SOM sizing, competitor positioning, and feature prioritization, leveraging SEO for SaaS strategies for subscription success to align messaging and go-to-market plans. Instead of pull findings sitting in a slide deck nobody reopens, they become inputs the AI advisory board can challenge and fact-check against market data before a single line of code gets written.

What to export from a completed JTBD round into a build spec:

  • Ranked push and anxiety forces, tied to specific feature or onboarding decisions
  • Pull-force language, ready to feed directly into pitch and landing page copy
  • A segmentation note on which buying-committee role each finding maps to

What I've Learned Running JTBD Interviews

Three rules hold up every time. First, the backward timeline walk is non-negotiable. Skip it once under time pressure and you'll spend the rest of the interview chasing a story the participant has already sanitized. Second, follow energy over your question order. The most useful anxiety detail I've seen surface in these interviews almost never came from the anxiety question. It came from a tangent the participant went on right after describing the pull moment.

Third, and this is the one teams resist most: stop interviewing your best customers for switch research. They love you. That's wonderful, and it's also useless data. The uncomfortable interviews, the churned accounts, the people who almost didn't switch, carry the forces that actually move a roadmap. One recurring pattern worth naming: teams that skip async voice entirely because it feels less rigorous than live calls often end up under-recruiting instead, and a smaller live sample beats a larger sample you never actually collected.

— Karl

Another Path: Turning Switch Interviews Into a Build Spec

There are other routes to organizing what you learn from switch interviews, spreadsheets, sticky notes, a shared doc your team half reads. Some tools take a different route: they turn your JTBD forces map directly into a connected business model, so the anxiety you uncovered in interview eight doesn't die in a slide deck, it becomes a scoped feature requirement your team can actually build against.

Klaritea

You type your idea in one line, and a tool structures it into ICP definitions, TAM/SAM/SOM sizing, competitor positioning, and a feature list, then lets you layer your push, pull, and anxiety findings on top of that structure instead of starting from a blank page. AI advisors covering marketing, business strategy, and operations can stress-test your assumptions against market data your interviews already pointed toward. Interviewing customers is still the work that generates real insight; Klaritea just keeps that insight from evaporating between your notes and your build spec. See how the connected model works and turn your next round of switch interviews into a scoped MVP instead of another folder of transcripts.

Sources

Start with the original recording, not a summary of it. The mattress switch interview transcript remains the clearest demonstration of timeline anchoring and force mapping in real time. Microsoft's research group offers a concise framework overview for teams new to the outcome-driven logic behind JTBD. For operational detail on running the interviews themselves, Talkful's practical guide covers audio-first analysis, and Bob Moesta's interview on sample size and saturation is worth a full listen for the recruitment math alone.

FAQ

What Is the Biggest Red Flag During a JTBD Interview?

A participant giving smooth, quick, generic answers with no specific sensory or contextual detail usually signals memory compression rather than a genuine recovered memory. Probe for exact time, place, and who else was present to test whether the story holds up.

What Are the Hardest Questions to Ask in a Switch Interview?

The hardest questions are the anxiety probes, asking what almost stopped someone from switching, because participants often want to present their decision as confident and rational rather than uncertain. Push gently with specific follow-ups like "who else weighed in" rather than accepting a vague "I just decided to go for it."

What Is the 10 to 15 Rule in JTBD Research?

Practitioner guidance suggests 10 to 15 interviews per customer segment usually reveals the dominant push, pull, anxiety, and habit patterns, with most teams reaching saturation by interview 10 to 12.

What Are the Four Forces in a JTBD Interview?

The four forces are push (what's wrong with the old solution), pull (what's attractive about the new one), anxiety (what almost stopped the switch), and habit (what kept someone with the old option longer than they should have stayed). Mapping all four for each participant is the core deliverable of a switch interview.

Does Klaritea Help With JTBD Research?

Klaritea doesn't run the interviews for you, but it helps founders turn completed JTBD findings, forces maps, opportunity lists, messaging hypotheses, into a structured phase-0 model covering market sizing, competitor positioning, and feature scope ahead of building anything.