JTBD Interview Questions: Reconstruct the Customer Switch

Direct answer: A JTBD Switch Interview reconstructs one real change decision. You trace what made the status quo questionable, which alternatives became real, what moved the person toward change, what held them back, and what progress they expected from the choice. The work is the timeline and evidence trail, not memorizing a list of “JTBD questions.”

Use the questions in this guide to close gaps in that reconstruction:

• ask about real events, not hypothetical preferences;
• let Push, Pull, Anxiety, and Habit emerge from the story instead of feeding those labels to the participant;
• separate Evidence / Inference / Assumption / Unknown / Decision;
• treat one interview as a source of candidate explanations and job hypotheses, not proof of market prevalence or causality.

Method scope: This guide focuses on the demand-side Switch Interview tradition: reconstructing a real change decision with a timeline and the Four Forces of Progress. “Jobs to be Done” is also used for other methods. For example, Outcome-Driven Innovation (ODI) uses a different process centered on a stable job, job steps, measurable desired outcomes, and quantitative prioritization. Both are called JTBD; they are not the same operational method.

The current first-party Switch Interview material describes the Timeline as the how of the decision and the Four Forces as the why. Strategyn makes the ODI distinction explicit. This page stays inside the Switch Interview job rather than pretending every JTBD school uses the same interview.

Table of contents

• The reconstruction model
• Choose the right decision and participant
• Reconstruct the timeline before explaining it
• Map the Four Forces after the evidence
• JTBD interview questions by evidence gap
• Worked switch reconstruction
• Contrast case: the team that did not switch
• Observation is not interpretation
• Account for memory and recall
• Compare stories without fake confidence scores
• What Switch Interviews can and cannot establish
• Copyable JTBD Switch Reconstruction worksheet
• What to do next

The reconstruction model

A useful Switch Interview should make it clear how you got from a remembered event to a Product implication.

Use this chain:

Change decision → Timeline → Alternatives → Forces → Expected progress → Evidence and contradiction → Candidate job hypothesis → Product implication → Next evidence

At each step, ask a different question:

1. What changed, nearly changed, stopped, or stayed the same?
2. What was happening before active search?
3. What first made the status quo questionable?
4. What happened next, in sequence?
5. Which alternatives became serious options?
6. What accelerated the move?
7. What blocked, delayed, or nearly reversed it?
8. Who else affected the choice, and what did this participant personally witness?
9. What did the person expect would become better?
10. What happened after the choice?
11. Which statements are direct evidence and which are your interpretation?
12. What does not fit the neat story?
13. What alternative explanation remains plausible?
14. What candidate job or progress hypothesis follows?
15. What Product decision can this evidence reasonably inform now?
16. What evidence is still missing?

That final question matters. A good interview can end with “we still do not know” or “another interview is not the right next method.”

If your actual job is broader research design, deciding whether interviews fit, recruiting, note-taking, synthesis, and method switching, use the complete customer interview workflow. This page owns the narrower switching-decision method.

Choose the right decision and participant

Do not start with “we need JTBD research.” Start with the Product decision the research may inform.

Examples:

• Why do teams abandon a manual workflow and adopt a workflow product?
• Why do qualified prospects evaluate us but stay with the incumbent?
• Why do customers churn to a competitor after apparently successful onboarding?
• Which part of a complicated B2B adoption journey deserves deeper investigation?

The interview target should have first-hand experience of the part of the decision you need to reconstruct.

A switch story can be useful when someone:

• moved to your product;
• moved to a competitor;
• abandoned a product;
• nearly switched but did not;
• stayed with an incumbent;
• kept a manual workaround;
• postponed the decision;
• chose non-consumption or “do nothing.”

Do not force every case into “customer hired our product.”

B2B: separate roles before you interpret the story

One person rarely owns the whole buying journey. Distinguish, when relevant:

• end user;
• champion;
• manager;
• admin;
• buyer;
• security reviewer;
• procurement;
• budget owner.

An operations lead may be excellent evidence for the broken approval workflow and the pilot. They may be weak evidence for why security approved the vendor. Ask what they directly saw, what they were told, and what they are inferring.

Role confusion is not a small note-taking problem. It changes what the evidence can support.

Recency is a design trade-off, not a universal window

The official Switch Interview guide recommends recent switchers because concrete detail fades. That is useful guidance, but the Timeline material also makes clear that decisions can unfold over very different periods, from a moment to a multi-year enterprise purchase.

Recruit people who can reconstruct the relevant events with useful specificity. Consider:

• how long the decision journey was;
• how salient the events were;
• whether artifacts can anchor recall;
• whether the participant was directly involved;
• whether the research question requires switchers, near-switchers, churned users, or stayers.

Do not turn one recruiting heuristic into a law.

Reconstruct the timeline before explaining it

The current Switch Interview guide emphasizes concrete events and repeated “what happened next?” probing. The Timeline is not a fixed funnel that every story must perfectly match. It is a way to recover sequence.

Prior state

What was the person doing before active change?

Capture the real alternative:

• incumbent product;
• spreadsheet;
• email;
• internal tool;
• agency;
• manual work;
• postponement;
• doing nothing.

Ask:

• “What were you doing before you started looking?”
• “What was good enough about that approach?”
• “Where did it create work or risk?”
• “Who depended on it?”

First thought or struggling moment

Find the earliest remembered moment when another approach became conceivable.

Ask:

• “Do you remember the first time a different approach even crossed your mind?”
• “What was happening around that time?”
• “Where were you?”
• “Who else was involved?”

Do not assume the participant identifies the true beginning on the first answer. Probe backward when the chronology suggests earlier tension.

Passive looking

Sometimes alternatives become visible before an active buying process exists.

Ask:

• “Had you already seen or heard about other approaches before you started searching?”
• “What did you notice without taking action?”

Only keep this stage if the story supports it.

Trigger or escalation

Find the event that made the situation harder to ignore.

Ask:

• “What changed that made the old approach harder to continue?”
• “Was there a specific event that moved this from annoying to worth acting on?”
• “What happened immediately after?”

Active search and alternatives

Reconstruct what the person actually did.

Ask:

• “Which options did you actually investigate?”
• “Which ones were seriously in contention?”
• “What did you do to compare them?”
• “Was staying with the old approach still a realistic option?”

Knowing a competitor exists is not the same as seriously considering it.

Decision

Slow the story down around the moment the choice became real.

Ask:

• “What happened when the decision became real?”
• “Who needed to agree?”
• “What nearly sent the decision another way?”
• “What changed between the last moment of hesitation and the choice?”

Adoption or first use

The decision story does not stop at purchase.

Ask:

• “What happened the first time you used the new approach for real?”
• “Which expectation held?”
• “Which did not?”
• “What work still had to change?”

This is where an attractive purchase story can collide with onboarding, migration, habit, and reality.

Map the Four Forces after the evidence

Current first-party JTBD materials taught by Bob Moesta and Chris Spiek use four forces to make sense of switching pressure. The Four Forces are researcher lenses, not vocabulary the participant needs to know.

Push

Pressure or dissatisfaction in the current situation that makes change more plausible.

Evidence may sound like:

• a failure that became visible;
• increasing manual effort;
• a missed commitment;
• a new constraint;
• an incumbent no longer being “good enough.”

Pull

Attraction of a new possibility or expected progress.

Evidence may include:

• a new capability becoming credible;
• a peer example;
• a demo that changes expectations;
• a belief that the new approach will reduce risk or effort;
• a picture of a better future state.

Anxiety

Uncertainty, fear, switching risk, or doubt about the new option.

Examples:

• migration risk;
• security uncertainty;
• learning cost;
• loss of control;
• fear of choosing badly;
• concern about stakeholder acceptance.

Habit

Inertia and the advantages of the current approach simply because it is already embedded.

Examples:

• familiar workarounds;
• existing templates;
• learned shortcuts;
• social routines;
• “everyone already knows how this works”;
• sunk coordination.

Do not ask people to name the framework

Weak:

“What was your Push?”

“What was the Pull?”

“What were your emotional and social jobs?”

Better:

“What happened next?”

“What almost stopped the change?”

“What was good enough about the old approach that you kept it?”

“What did you expect would become different?”

The first-party Switch Interview guidance explicitly recommends letting the forces emerge from concrete events instead of asking participants to identify framework labels.

Do not score the Four Forces

It is useful to visualize Push and Pull as favoring change and Anxiety and Habit as resisting it. It is not a measured equation.

Do not assign:

• weights;
• percentages;
• probability;
• thresholds;
• a “force score.”

The forces help explain a story. They do not turn a qualitative interview into a predictive model.

Timeline × Four Forces Evidence Map

Use the timeline to locate events, then use the forces to interpret pressure around those events.

This is not a coding template that guarantees one force per stage. A single event may matter to multiple forces, and some stories will not contain every neat marker.

JTBD interview questions by evidence gap

The query is “JTBD interview questions,” but the better unit is an evidence gap. Ask the next question because something important is missing from the reconstruction.

If the first thought is unclear

• “What was happening before you started looking?”
• “Do you remember the first time a different approach crossed your mind?”
• “What happened around that time?”
• “What were you doing immediately before that?”

If the trigger is unclear

• “What changed that made the old approach harder to continue?”
• “Was there a specific event that made this worth acting on?”
• “What happened next?”

Avoid inserting an emotion the participant has not expressed.

If the prior solution is unclear

• “What were you doing before?”
• “What was good enough about that approach?”
• “What made it difficult to abandon?”
• “What work did people already know how to do?”

If the alternative set is unclear

• “Which options did you actually investigate?”
• “Which option was seriously in contention?”
• “What did you rule out quickly?”
• “Was doing nothing still a realistic option?”

If Pull is unclear

Do not ask “What was the pull?”

Ask:

• “What first made that option seem worth considering?”
• “What did you expect would become different?”
• “Was there a moment when this option became more credible?”

If Anxiety is unclear

• “Was there a point where you nearly stopped the change?”
• “What uncertainty still mattered at that point?”
• “What would have sent you back to the old approach?”
• “Who was worried about the change, and about what?”

If Habit is unclear

• “What did the old approach make easy because everyone already knew it?”
• “What would have to change in your workflow to adopt the new option?”
• “What did you not want to give up?”
• “Which workaround had become normal?”

If the decision is unclear

• “What happened when the choice became real?”
• “Who needed to agree?”
• “What nearly sent the decision another way?”
• “What changed between hesitation and commitment?”

If expected progress is unclear

• “What did you hope would be different afterward?”
• “How would you have known the change was worthwhile?”
• “What problem did you expect to stop managing manually?”

Jobs can have practical, emotional, and social consequences. Christensen describes jobs as having functional, emotional, and social dimensions, but you do not need to force all three into every interview. Listen for them where they appear.

If post-choice reality is unclear

• “What happened the first time you used the new approach for real?”
• “Which expectation held?”
• “Which did not?”
• “What surprised you?”
• “What still required a workaround?”

For generic neutral-question repair rather than switching research, use Customer Interview Questions That Reveal Real Behavior.

Worked switch reconstruction

The example below is hypothetical. It shows how the evidence can lead to a conclusion without pretending to be a real customer case.

Product decision

A PM at a mid-market workflow product wants to decide which adoption constraints deserve deeper investigation.

The decision is not “which feature should we build from this interview?”

Participant and role

Operations lead / champion

First-hand involvement:

• ran the old spreadsheet-and-email approval process;
• experienced approval failures;
• joined vendor evaluation;
• led a pilot;
• influenced the final recommendation.

Not first-hand:

• security’s internal risk assessment;
• procurement’s negotiation;
• the budget owner’s final trade-off.

Anything about those areas needs attribution or another participant.

Switch event

The team moved one cross-functional approval workflow from spreadsheets and email into a workflow product.

Prior state

The team used:

• a shared spreadsheet for request status;
• email for approvals;
• manual reconciliation before weekly leadership meetings.

The process was familiar and flexible. It was also easy for approvals to disappear between systems.

Timeline evidence

Earlier tension

The participant remembers rechecking the spreadsheet before each weekly approval meeting because status could not be trusted.

First thought

After an approval was missed, the participant asked whether an internal workflow tool already existed. No buying process started.

Escalation

A later missed finance approval delayed a customer delivery and became visible to senior leadership. The participant was asked to propose a more reliable process.

Passive looking

The participant had seen a peer team use a workflow product before the escalation but had not investigated it.

Active search

The participant:

• asked IT about an internal solution;
• evaluated keeping the spreadsheet with stricter process rules;
• looked at two workflow products;
• involved an admin in a pilot.

Decision pressure

One product had broader native integration coverage. The selected product had weaker coverage for one system but offered clearer migration support and made approval ownership visible during the pilot.

Choice

The operations lead recommended the selected product. Security and procurement still had to approve it.

First use

The first live workflow made overdue ownership easier to see, but mapping several old spreadsheet fields still required manual work.

Alternatives that were actually real

• improve the spreadsheet process;
• ask IT for an internal workflow;
• Product A;
• Product B;
• postpone the change.

A vendor the participant had merely heard of is not treated as a serious alternative.

Push evidence

• recurring manual reconciliation;
• a missed approval;
• customer-delivery impact;
• senior-leadership visibility.

Pull evidence

• visible approval ownership;
• a shared workflow instead of email reconciliation;
• migration support that made the pilot feel operationally achievable.

Anxiety evidence

• security approval still unresolved during evaluation;
• concern about migration effort;
• worry that teams would resist another system.

Habit evidence

• the spreadsheet was flexible;
• people already knew the email workflow;
• existing formulas and conventions had accumulated over time.

Expected progress

The participant did not simply want to “automate approvals.”

A more useful interpretation is:

Regain confidence that cross-team commitments will not disappear between systems.

That interpretation still needs testing.

Contradiction

The participant initially says:

“Integrations were the deciding factor.”

But the chronology shows the team accepted an option with weaker coverage for one integration after migration support and workflow visibility changed the evaluation.

Do not delete the contradiction to make the story cleaner.

Possible explanations include:

• “integrations” is a post-hoc shorthand for implementation confidence;
• one missing integration mattered less than expected;
• another decision-maker cared more about integrations than this participant did;
• support quality changed the perceived switching risk;
• the chronology is incomplete.

The contradiction tells you what to investigate next.

Evidence / Inference / Assumption / Unknown / Decision

Evidence

The participant repeatedly reconciled status manually, described two missed approvals, joined the pilot, and recommended a product after comparing alternatives.

Inference

Low trust in cross-system status may have made visibility more valuable than feature breadth.

Assumption

Other teams with similar workflows experience the same mechanism.

Unknown

What security, procurement, and the budget owner believed mattered most.

Decision

Investigate trust/visibility and migration confidence across more roles and switch outcomes before deciding whether a Product change is warranted.

Candidate job / progress hypothesis

When approval failures become visible to senior stakeholders, operations teams may seek a way to regain confidence that cross-team commitments will stay visible and owned without manual reconciliation.

That is a candidate hypothesis, not a validated market truth.

Alternative explanation

The team may have chosen primarily because the vendor reduced implementation effort, while “confidence in commitments” is an attractive narrative imposed after the fact.

Both explanations remain plausible.

Product implication

This interview can justify:

• deeper research on trust and visibility;
• research on migration and implementation support;
• interviews with admins, security, and near-switchers;
• checking whether onboarding behavior supports the hypothesized friction.

It does not directly justify:

• building a dashboard;
• declaring integrations unimportant;
• claiming a new market segment;
• predicting conversion;
• reprioritizing the roadmap from one story.

Next evidence

A sensible next step could be:

• another switch interview with a comparable operations lead;
• a near-switch interview with a team that stayed on spreadsheets;
• an admin/security interview for the parts this participant did not witness;
• behavioral data on where pilot/migration workflows stall;
• no action yet if the Product decision is not actually blocked by this uncertainty.

Contrast case: the team that did not switch

Successful switchers can hide the forces that stop adoption.

This second case is also hypothetical.

A similar operations team experiences recurring approval confusion and evaluates a workflow product. The team still stays with its spreadsheet.

What the reconstruction shows

Push exists

Manual reconciliation is annoying and a missed handoff has already happened.

Pull exists

The new product makes ownership and reminders visible.

Anxiety grows

Security review raises questions about data access. The admin expects a difficult migration. The operations lead cannot explain how historical exceptions will move across.

Habit remains useful

The spreadsheet is ugly, but everyone knows it. The team has custom formulas and a monthly cleanup ritual that works well enough.

Decision

The team postpones the switch and adds stricter spreadsheet rules.

Do not say “Anxiety + Habit scored higher.”

Say what happened.

The non-switch is evidence that:

• the current solution still has real value;
• switching cost is part of the decision;
• Pull alone did not resolve implementation uncertainty;
• adoption research should include the status quo, not only happy customers.

The absence of a switch is evidence too.

Observation is not interpretation

A common JTBD failure is turning a vivid quote directly into a job or feature.

Use this trace instead:

event → observation → interpretation → candidate progress/job hypothesis → Product question

Example:

Observation

Participant describes rechecking a spreadsheet before every approval meeting.

Interpretation

The old process may create low trust in status visibility.

Candidate progress hypothesis

The desired progress may involve confidence that approvals remain visible without manual reconciliation.

Product question

Where in the workflow does trust break, for which roles, and what evidence would distinguish a Product problem from a process problem?

Unsupported leap

“Customers need an approval dashboard.”

That leap skips the mechanism and the remaining uncertainty.

The same rule applies to requests such as:

“I need an export button.”

Record the request. Then reconstruct the event, workaround, consequence, and decision context before deciding what problem it represents.

Account for memory and recall

A Switch Interview reconstructs a remembered decision. Memory is not an objective event log.

Retrospective evidence can be useful and still be limited:

• chronology may be incomplete;
• participants may compress repeated events;
• salient moments may crowd out less memorable causes;
• people may rationalize a decision after the fact;
• a reason stated today may not capture every mechanism operating at the time.

Improve recall with concrete anchors:

• where the person was;
• who was present;
• what happened immediately before and after;
• messages, calendars, tickets, purchase records, or other artifacts when appropriate;
• sequence correction: “You mentioned the pilot before security review, is that the order it happened?”

If someone cannot remember a detail, record the gap. Do not manufacture a clean timeline.

Functional, emotional, and social dimensions

Christensen’s broader Jobs theory describes jobs as shaped by circumstances and as having functional, emotional, and social dimensions.

Use that as a listening lens, not an interview checklist.

For example, the workflow case might contain:

• functional: keep approvals visible and moving;
• emotional: feel confident that commitments will not disappear;
• social/contextual: avoid arriving at a leadership review unable to explain status.

Do not ask the participant to fill three boxes. Do not force all three dimensions into every story. And do not confuse these dimensions with Push, Pull, Anxiety, and Habit, they answer different analytical questions.

Compare stories without fake confidence scores

After reconstructing each interview separately, compare cases on the same dimensions:

Then ask:

• Which mechanisms repeat?
• In which contexts?
• What differs?
• Which contradictions suggest role or segment differences?
• Are apparently similar stories actually different jobs?
• Which evidence would change the current interpretation?
• Is another interview still the right next method?

Do not count mentions and call the result a confidence score.

If the question becomes “how many interviews are enough?”, hand it to the dedicated sample-size and saturation guide.

If the question becomes “does interview evidence agree with behavioral, survey, support, or experiment data?”, use triangulation research.

What Switch Interviews can and cannot establish

The distinction is not academic. It tells you what to do next.

If the remaining question is quantitative, use a quantitative method. If it is causal, use an appropriate causal or experimental design. If it is cross-source, triangulate. If you still need to understand the decision mechanism, another interview may be useful.

Copyable JTBD Switch Reconstruction worksheet

Use this as a synthesis aid after or during a switching interview. It is not a scientific validation score.

# JTBD Switch Reconstruction

Product decision:
[What choice might this research inform?]

Participant:
[Role + firsthand involvement]

Change event:
[What switched, nearly switched, stopped, or stayed?]

Prior state / current solution:
[What were they doing before? What was good enough about it?]

First thought:
[What first made another approach conceivable?]

Trigger / escalation:
[What made the issue harder to ignore?]

Passive looking:
[What alternatives were visible before active search, if any?]

Active search:
[What did they actually investigate or do?]

Alternatives seriously considered:
[Incumbent / competitor / manual workaround / internal process / delay / do nothing]

Decision actors:
[User / champion / admin / manager / buyer / security / procurement / budget owner]

Choice / non-choice:
[What became the real decision? What nearly changed it?]

First use / aftermath:
[What happened after the decision?]

## Evidence

Push:
[Observation / event / participant language]

Pull:
[Observation / event / participant language]

Anxiety:
[Observation / event / participant language]

Habit:
[Observation / event / participant language]

Expected progress:
[What did they expect to become better?]

Contradiction:
[What evidence does not fit the neat story?]

## Interpretation

Candidate job / progress hypothesis:
[Bounded explanation, not market truth]

Alternative explanation:
[What else could explain the same evidence?]

What this evidence does NOT establish:
[Prevalence / causality / segment size / conversion / roadmap priority / other]

Product implication:
[Which decision is more informed now?]

Next evidence needed:
[Interview / analytics / observation / survey / experiment / no action]

A compact review before you trust the worksheet

Ask:

• Can every major inference point back to an event, observation, or participant statement?
• Did we preserve contradictions?
• Are B2B roles separated?
• Did we include the status quo and non-consumption where relevant?
• Did we turn a framework label into a participant answer?
• Did we turn a quote into a feature?
• Are we claiming more than this evidence can support?

If the answer to the last question is yes, narrow the conclusion.

Common failure modes

Framework-label interviewing

Weak: “What was your Push?”

Better: reconstruct the events, then classify the evidence.

Feature-first interviewing

Weak: “Why did you buy our automation feature?”

Better: start with what was happening before the team began considering change.

Clean-story bias

A real decision can be inconsistent. Preserve chronology that does not fit your first explanation.

Successful-customer-only bias

Include near-switch, competitor, churn, manual, and stay cases when the Product question requires them.

Alternative-set blindness

The real competitor may be a spreadsheet, an internal process, an agency, delay, or doing nothing.

Quote → job

A memorable quote is evidence, not automatically “the job.”

Job → roadmap

A candidate job is not automatically a feature priority.

Recall = causality

A remembered reason can suggest a mechanism. It does not independently prove objective causation.

Consensus = truth

Repeated wording across a qualitative sample is not automatically statistically representative.

JTBD methodology collapse

Switch Interview, job-story syntax, ODI/job maps, and desired-outcome research can all appear under the JTBD label. Keep the method you are using explicit.

What to do next

The next step depends on where you are in the research lifecycle.

Before the interview: build the runnable guide

If you have the decision, participant, and evidence gap but still need a full discussion guide, use the Interview Script Generator. It adapts the guide to the research job instead of forcing you to copy a generic script from this article.

After credible switch evidence: build the job-story artifact

Once you have a bounded situation, motivation, expected outcome, and any useful Four Forces evidence, use the JTBD Statement Generator to turn those inputs into an editable artifact.

The generator is downstream of the evidence. Do not use generated wording as a substitute for the interview.

If the problem is generic question wording

Use Customer Interview Questions That Reveal Real Behavior.

If the problem is the whole research workflow

Use Customer Interviews for Product Discovery.

If the question is sample adequacy

Use How Many Customer Interviews Are Enough?.

If the question needs multiple evidence sources

Use Triangulation Research.

If you want structured learning

Continue with the Product Discovery course.

Source notes

This guide uses sources according to the claim being made:

• How to Run a Switch Interview, current demand-side Switch Interview mechanics.
• The JTBD Timeline, sequence and Timeline/Four Forces distinction.
• The Four Forces of Progress, Push, Pull, Anxiety, and Habit in the switch model.
• Know Your Customers’ “Jobs to Be Done”, Christensen and coauthors on jobs, circumstances, and functional/social/emotional dimensions.
• Strategyn’s JTBD / ODI template, ODI methodology boundary and quantitative desired-outcome process.

The method is useful because it ties a switching decision back to concrete events and evidence. Keep the conclusion as narrow as the evidence allows.