Coding Switch Interviews: Turning Transcripts Into the Four Forces

Code every quote in a switch interview transcript against two axes at once: which of the four forces of progress it represents (push, pull, anxiety, or habit) and where it falls on the switch timeline (first thought, passive looking, active looking, or deciding). Tag consistently across interviews, then tally the tags into a forces matrix to find the pattern.

Quick answer: Tag every quote with one force — push, pull, anxiety, or habit — and one timeline stage. Build an interviews-by-forces matrix, then look for the force that shows up as dominant across most interviews near the decision point, not just the one quote you personally like best.

What "Coding" a Switch Interview Actually Means

Coding a switch interview means breaking a messy, chronological, emotional story into discrete, labeled units — usually a sentence or a short cluster of sentences — each tagged with a force and a timeline stage. It turns a 45-minute retrospective narrative into a structured dataset you can actually compare across participants.

This matters because switch interviews (the retrospective, story-based interviews popularized by Bob Moesta and Chris Spiek, and formalized in Clayton Christensen's Competing Against Luck) don't unfold in tidy order. A participant will jump from "the day I finally called the vendor" back to "six months earlier, when things started feeling off," then forward to "three weeks after we switched." Your job as a researcher is to unstick the narrative from its telling order and re-sort it along axes that actually predict behavior.

If you're new to the underlying theory, ground yourself first — our complete guide to jobs-to-be-done walks through the job statement, the forces model, and the timeline before you ever pick up a coding sheet.

A properly coded transcript unit should carry:

• The verbatim quote (not your paraphrase — paraphrasing is where bias creeps in)
• A force tag: PUSH, PULL, ANXIETY, or HABIT
• A timeline tag: first thought, passive looking, active looking, or deciding
• The participant ID and a rough timestamp in the recording
• An optional researcher note, kept visually separate from the quote itself

Keep the quote and your interpretation in different columns. The moment you let them blur, you've stopped coding and started confirming what you already believed.

The Four-Force Coding Scheme: Tag Every Quote as Push, Pull, Anxiety, or Habit

The forces of progress model — developed by Clayton Christensen, Bob Moesta, and their collaborators out of the original McDonald's milkshake research — argues that every switch is a tug-of-war between two forces pushing someone toward change and two forces holding them back. Coding means assigning each quote to one of the four.

Three rules keep this scheme defensible instead of arbitrary:

1. Tag the quote, not the interview. One participant will show all four forces at different moments — don't summarize a whole 45-minute conversation as "an anxiety-dominant interview" before you've tagged every unit.
2. Let one quote carry two tags when it earns it. "I liked what I saw, but I panicked about migrating our data" is legitimately both PULL and ANXIETY — split it rather than forcing a single label.
3. Tag literal language, not your inference. If someone says "it was fine, I just wanted to try something new," resist coding that as PUSH unless they name an actual problem. Curiosity without dissatisfaction is a weaker push, and your matrix should reflect that honestly.

Adding the Timeline: Where in the Switch Did This Quote Happen

A force tag alone tells you half the story — you also need to know when in the switch it occurred, because the same force means something different depending on the stage. Anxiety at "first thought" is background noise; anxiety at the deciding moment is often the whole ballgame.

Alan Klement's When Coffee and Kale Compete offers the clearest map of these stages, building on the original Forces of Progress research:

In practice, you'll infer the stage from context clues rather than a clean timestamp: "that's when I started asking around" signals passive looking; "we had it down to two vendors" signals active looking. Note the stage alongside the force tag in the same row of your coding sheet, not as an afterthought.

This two-axis approach is really a compressed, decision-specific version of the emotion curve used in broader experience mapping. If you want the fuller discipline of charting emotional peaks and troughs across an entire relationship rather than just the switch moment, our customer journey complete guide covers that terrain.

Building a Forces Matrix Across Interviews to Find the Dominant Hindering Force

A single coded transcript looks scattered — a little push here, an anxious aside there. The pattern only appears once you lay multiple interviews side by side in a matrix: rows as interviews, columns as the four forces, cells as counts or weighted scores, plus a "dominant hindering force" column.

Here's a simplified example from five switch interviews about a project-tracking tool:

Read across this matrix and a pattern emerges that no single interview would reveal: three of five participants are held back primarily by habit, not fear of the new tool. That's a materially different roadmap conversation than "reduce onboarding anxiety" — it's closer to "make switching away from the old workflow feel low-cost and reversible."

Build the matrix in this order:

1. Normalize your unit of analysis. Decide whether a "tag" is a quote or a theme, and hold that unit constant across every interview — don't count quotes in interview 3 and themes in interview 7.
2. Tally raw counts per force, per interview. This first pass is intentionally crude; it's a starting point, not the answer.
3. Weight by proximity to the decision. A single anxious quote at the deciding stage usually matters more than five passing habit comments at first thought — note this with a simple high/medium/low weight column rather than treating raw counts as equivalent.
4. Look for the majority pattern, not the loudest interview. The dominant hindering force is whichever of anxiety or habit shows up as primary across the most interviews, not the one from the participant whose story you found most memorable.

Forces rarely act alone — habit often reinforces anxiety, since the longer someone has done something one way, the scarier switching feels, and that kind of reinforcing loop is easy to miss if you only ever count tags in isolation. If you're comfortable with feedback-loop thinking, our systems thinking complete guide is a useful lens for mapping how these forces reinforce or dampen each other across an interview set.

Once the matrix has told you which hindering force dominates, resist the urge to jump straight to a feature list. Feed the finding into your opportunity score work instead, so the roadmap decision reflects both the size of the unmet need and the force actually blocking it.

The Cherry-Picking Trap: Coding Discipline That Keeps You Honest

The single biggest risk in this entire exercise is coding backward from a conclusion you already believe. If you walked into synthesis convinced the roadmap needs a specific feature, you will find quotes that confirm it — qualitative coding is permissive enough that motivated reasoning always finds supporting evidence.

Cherry-picked quotes aren't lies; they're worse. They're true statements arranged to prove something the full transcript doesn't actually support.

Borrow the discipline that grounded-theory researchers like Strauss and Corbin built into qualitative coding methodology, and adapt it for switch interviews:

• Code the entire transcript before drafting a single conclusion slide. If you stop coding once you've found three quotes that support your hypothesis, you've stopped researching.
• Use independent double-coding on at least a subset of interviews. Have a second researcher tag the same transcripts without seeing your labels, then reconcile disagreements — this inter-rater step is standard qualitative practice, and disagreements are usually where the interesting nuance lives.
• Set a minimum interview count before declaring a pattern. Research on interview saturation — Guest, Bunce, and Johnson's often-cited study among them — found that new themes tend to stop emerging somewhere around a dozen interviews for a reasonably homogeneous population. Treat "dominant force" claims from three or four interviews as a hypothesis, not a finding.
• Keep a visible register of contradicting quotes. For every pattern you report, log the quotes that don't fit. If that list is empty, you probably didn't look hard enough.
• Separate the coding session from the roadmap conversation. Code on a day you're not also planning sprints — the temptation to let a deadline decide the tag is real.

A forces matrix built on cherry-picked quotes doesn't just produce bad prioritization — it produces a fragile job statement that won't survive engineering handoff, because the first pointed question in a spec review ("where did this come from?") exposes the gap between what you claimed and what the transcripts say. Once your coding holds up under that kind of scrutiny, translate the dominant force into a properly formatted JTBD job statement so the rest of the org can act on it without re-deriving your synthesis.

From Matrix to Roadmap: Where Prodinja Fits

None of this coding scheme requires special software — a spreadsheet and discipline will get you there. But the raw material has to come from somewhere, and most teams lose the verbatim quotes long before synthesis because they're buried in call recordings nobody re-transcribes.

Prodinja's Journals tool is built for exactly that capture problem: it lets you voice-record reflections and interview debriefs right after a switch conversation, while the language is still fresh, rather than relying on memory or a rushed note days later. Those journal entries — the raw switch quotes — are the ore this whole coding exercise runs on.

From there, Prodinja's Customer Jobs tool — which combines JTBD job statements, Ulwick-style opportunity scoring, and a forces-of-progress workspace — is designed to walk you through translating those captured quotes into push, pull, anxiety, and habit tags, and into the timeline stages described above. That keeps the matrix-building step inside the same tool where the raw material already lives, instead of in a disconnected spreadsheet.

It won't code the transcripts for you or decide which force is dominant. That judgment call — and the discipline to make it honestly — is still yours.

Key Takeaways

• Every quote gets two tags, not one: a force (PUSH, PULL, ANXIETY, or HABIT) and a timeline stage (first thought, passive looking, active looking, deciding).
• The four forces come from Christensen and Moesta's Forces of Progress model — two forces (push, pull) drive change, two (anxiety, habit) hold people back.
• Timeline placement changes meaning: anxiety at first thought is background noise; anxiety at the deciding stage is often the whole story.
• A forces matrix — interviews as rows, forces as columns — turns scattered quotes into a pattern, especially the dominant hindering force column.
• Habit and anxiety are not the same problem and call for different roadmap responses: habit needs low-friction, reversible onboarding; anxiety needs proof and reassurance.
• Guard against cherry-picking with full-transcript coding, independent double-coding, a minimum-interview threshold, and a visible log of contradicting quotes.
• Coding is the input to prioritization, not a replacement for it — feed the dominant force into opportunity scoring and job-statement work rather than jumping straight to a feature list.