How to run jobs to be done interviews

The first jobs to be done interview most teams run is a memory test. The product manager opens with "tell me about the last time you bought our product", the customer answers in present-tense generalities, the transcript reads like a survey response, and a week later the team is back to debating roadmap from intuition. The interview that the JTBD literature actually describes (the one that surfaces the day of the switch in chronological detail) is a different artifact entirely, and the difference is almost never in the questions.

This is a working playbook on how to run jobs to be done interviews that produce evidence about the four forces, not opinions about your product. What the method is, how to walk a customer back through the day they switched, and what changes when the recording is voice instead of a written summary.

What jobs to be done interviews are

A jobs to be done interview is a structured conversation that reconstructs the moment a customer switched from one product, habit, or workaround to another. The goal is to surface the four forces (push, pull, anxiety, habit) that made the switch happen on a specific day, not to discover what the customer wants in the abstract. The format was developed by Bob Moesta and Chris Spiek at the Re-Wired Group, building on consulting work with Clayton Christensen at Harvard Business School, and is documented in detail in Christensen's HBR essay on the milkshake research and Moesta's Demand-Side Sales 101.

The unit of analysis is the switch, not the user. A customer who has been using your product for two years cannot be a JTBD interviewee in any useful sense, because the switch has compressed in their memory into a story, and the story is not the data. A customer who switched three weeks ago is the right artifact to interview.

The four forces (or: what the interview is actually for)

The interview is not a generic conversation. It is a tool for a specific framework. Push and pull on one axis. Anxiety and habit on the other.

• Push: the dissatisfaction with the old solution that made the customer start looking for something else.
• Pull: the appeal of the new solution that drew them in once they started looking.
• Anxiety: the worries about switching that almost stopped them from doing it.
• Habit: the inertia of the existing behavior that made them stay longer than they wanted to.

Push and pull together are demand. Anxiety and habit together are friction. A successful switch happens when push plus pull is greater than anxiety plus habit. Most teams find their product has plenty of pull (the customer liked the demo), weak push (the old solution was good enough), terrible anxiety reduction (switching felt risky), and powerful incumbent habits (Excel, the inbox, the old vendor). The interview is what tells you which of those four forces matters most for the customers you most want to win.

You do not ask "what was the push?" The interview surfaces the forces by reconstructing the day. The forces are inferred from the transcript, not named by the participant.

How to run jobs to be done interviews, step by step

Six steps. They are the shape Bob Moesta uses in the original switch interview, with two of them rebuilt for async voice because most teams cannot reliably get an hour-long live call from a customer who has already switched and moved on with their life.

01 · Recruit the customer who actually switched

Most JTBD interviews fail at recruitment, not at the interview. The right participant is someone who switched recently (last 30 to 60 days), where the switch is observable as a discrete event with a date and a Friday afternoon. The wrong participant is a long-time customer being asked to remember why they signed up. Memory has compressed. The story has been polished. The four forces are no longer recoverable.

Two screener questions usually do it. First: "When did you start using ?" Reject anyone who answers in years. Second: "What were you using to do before?" Reject anyone who answers "nothing." A customer who switched from nothing is a category-creation interview, which is a different method.

The piece on how to write user research questions covers the prompt-craft side of recruitment screeners; for JTBD specifically, the rule of thumb is to recruit eight to twelve customers per segment, all of whom switched within the same 60-day window.

02 · Walk the timeline backwards

The switch happens on a specific day. The work of the interview is to walk backwards from that day until you reach the first thought of switching, which is usually weeks or months earlier. Most untrained interviewers run the timeline forward from "first heard about us" to "signed up", and end up with a clean narrative that omits exactly the moments where the four forces lived.

The right opening: "Take me to the day you bought . What happened that morning?" Then: "Walk me back to the day before. The week before. When did you first start thinking about a change?" The customer's narrative will resist this; people remember stories, not timelines. Push gently. The dates are the data.

The backwards walk usually surfaces three anchor moments: the day of the switch, the day they first seriously evaluated alternatives, and the day they first noticed the old thing was a problem. Those three days are what the rest of the interview zooms into.

03 · Rebuild the day of the switch in detail

Once you know roughly when the switch happened, slow down. What time of day was it? Where were they sitting? What did they try first? Who else was involved? What was the trigger that turned thinking-about-it into doing-it?

The day-of-switch detail is where the four forces become legible. The vague "I needed something faster" becomes "my boss asked me on Tuesday morning for a report I didn't have a way to pull, I tried Excel for twenty minutes, gave up, and signed up for the trial during my coffee break." That second sentence has a push (the boss), a pull (the trial), an anxiety (will the trial actually do this in time), and a habit (Excel) all visible in one paragraph. The first sentence has none of them.

If the participant skips ahead, walk them back. "Before you opened the trial, what did you try first?" The order of attempts is often where the switching cost lives.

04 · Surface the four forces through the transcript

You do not ask "what was the push?" You ask questions whose answers contain the push. Four reliable patterns, one per force:

• For push: "What was wrong with what you were using before?" Asked in past tense, anchored to the day of the switch, not to today. The push is historical.
• For pull: "When you found , what made you stop and look closer?" Specifics of the moment, not feature lists.
• For anxiety: "What worried you about switching?" If the answer is "nothing," probe one more time: "What was the part you weren't sure about?" Almost no real switch is anxiety-free.
• For habit: "What had you been doing instead, and how long had you been doing it that way?" Length of the habit usually correlates with the size of the switching cost.

The forces are usually not balanced. Across a single interview, two of the four will be loud. The interview's job is to find which two. Across eight to twelve interviews on the same segment, a pattern emerges, and that pattern is the synthesis output.

05 · Listen for energy, not just words

Most JTBD interview transcripts read flatter than the conversation actually was. The customer leaned forward when they described the boss-on-Tuesday moment. The pause before they said the price was the longest pause in the call. The "honestly..." that prefaced the real reason. None of that is in the written transcript.

This is where voice does the heavy lifting. A voice recording preserves what a transcript cannot: speed, pause, emphasis, hesitation. The four forces are not just named in the words. They live in the energy. The customer's voice gets faster on the pull and slower on the anxiety. The push usually arrives with a sigh. Without the audio, half the interview is gone before analysis begins. The longer essay on what voice catches that text loses covers this asymmetry in detail.

"My boss asked me on Tuesday morning for a report I didn't have a way to pull. I tried Excel for twenty minutes. Then I... [pause]... honestly, I just signed up during my coffee break."

06 · Synthesize at the force, not at the quote

A common mistake at synthesis is to cluster transcripts by topic ("price", "speed", "team buy-in"). Resist that instinct. Cluster them by force. Across twelve interviews, what was the most common push? What were the recurring anxieties? What habits showed up in five-plus customers? The output of a JTBD synthesis is not a wordcloud. It is a force diagram with the strongest two named in plain language.

The general thematic-analysis pass we describe in analyzing user interview transcripts still applies, with one substitution: the codebook is the four forces, not an open code set. The atomic unit being coded is a moment in the day-of-switch narrative, not a quote about your product.

Why voice changes jobs to be done interviews

The Bob Moesta school of JTBD treats the interview as a recording, not a transcript. Standard practice is for the team to listen together to the audio after the call, because the energy of the customer's voice is part of the data. That practice has held up for two decades. It also has not scaled, because scheduling an hour-long live call with a customer who has already switched (and is no longer thinking about you) is the rate-limiting step in every JTBD program. Most JTBD pipelines die on recruitment.

The async voice version works because the artifact (a voice recording) is the same as the live version, while the constraint (a live calendar slot from a customer with no remaining incentive) goes away. The customer answers four to six prompts on their own time. Each prompt is one timeline anchor: the day of the switch, the day before, the week before, the moment of first thought, the day-of-switch detail, the four-forces probe. The recordings come back as audio plus transcript. The team listens together at a fixed slot the same way they would for a live call. The same operational shape we describe in how to run continuous discovery interviews carries over: the customer side is async, the team listening is the only synchronous part.

The trade-off is the loss of in-the-moment follow-up. You cannot probe a hesitation as it happens. The async fix is to design adaptive prompts that catch the most common hesitations after they appear: when the participant says something vague in prompt three, prompt four asks them to expand on it. For most teams the trade is favorable, because the calendar constraint kills more interviews than the live probe rescues. The wider voice user interview guide covers the prompt-set pattern in operational detail.

When jobs to be done interviews don't help

Three cases worth naming up front, because the method is often misapplied to questions it was not built for.

The category is too new for switches to have happened yet. JTBD assumes a comparison set. If your product is the first in its category, customers haven't switched, they've started. Run a different kind of interview (concept testing, problem validation) until enough switches accumulate to interview against.

The decision was made by someone other than the user. This is the common B2B and enterprise case. The four-forces frame still works, but you need to interview the decision-maker (the buyer, the procurement lead, the executive sponsor), not the end user. Mixing the two produces a force diagram that is incoherent.

You are pre-launch. JTBD requires a customer who has actually paid and used. If you are pre-launch, the right tool is assumption testing on the forces you suspect are operative, not interviewing customers who have not switched yet. The voice user research guide covers where assumption testing fits in a wider product-research practice.

FAQ

What is a jobs to be done interview?

A jobs to be done interview is a structured conversation with a customer who recently switched products, habits, or workarounds. The goal is to reconstruct the day of the switch in enough detail to surface the four forces (push, pull, anxiety, habit) that made it happen. The method was developed by Bob Moesta and Chris Spiek at the Re-Wired Group, building on Clayton Christensen's milkshake research at Harvard Business School. The interview is the recording, not the transcript: the energy of the customer's voice carries data the written words alone do not.

How long should a jobs to be done interview take?

The original switch interview is 45 to 60 minutes live. The structure walks backwards from the day of the switch through the previous weeks, then forward through the day itself in detail. Async voice versions split the same content across four to six short prompts (60 to 120 seconds of recorded answer each), totaling roughly 8 to 12 minutes of audio per participant. Both formats produce the same artifact: a recording that surfaces the four forces. The async version trades in-the-moment follow-up for a calendar that customers will actually accept.

How many jobs to be done interviews do I need?

Eight to twelve interviews on a homogeneous customer segment is usually enough to see the dominant forces emerge. This is consistent with what Guest, Bunce and Johnson found on thematic saturation in qualitative interviewing more broadly. Below five interviews you risk drawing the framework around one loud customer; above twelve, marginal returns drop sharply unless you are deliberately running multiple segments. If you are running JTBD across two segments (small business versus enterprise, for example), treat them as separate studies and recruit eight to twelve per segment.

Can JTBD interviews work async?

Yes, with one trade-off. The async version preserves the audio (which is most of the data) and removes the calendar constraint (which is most of the operational cost). It loses the ability to probe a hesitation in real time. The fix is to design adaptive follow-up prompts that catch the most common hesitations after they happen. For most teams the trade is favorable: the calendar constraint kills more JTBD interviews than the in-the-moment probe rescues. A live interview that does not happen produces no data at all.

What is the difference between a JTBD interview and a regular customer interview?

A regular customer interview asks about needs, opinions, and feelings in the present tense. A JTBD interview reconstructs a specific past event (the switch) in chronological detail. The first produces opinions about your product. The second produces evidence about the four forces driving customer behavior. They are complementary, not interchangeable. JTBD answers "why did customers switch to us." A regular interview answers "what do customers think of us." Most product teams need both at different moments.

Who created the jobs to be done interview method?

The interview format was developed by Bob Moesta and Chris Spiek at the Re-Wired Group, based on consulting work with Clayton Christensen at Harvard. Christensen popularized the underlying jobs-to-be-done theory in Competing Against Luck (2016) and the milkshake case study from earlier HBR research. Moesta's Demand-Side Sales 101 documents the switch-interview format in operational detail. Alan Klement's When Coffee and Kale Compete extends the framework into product strategy.

---

JTBD interviews are not about asking better questions. They are about getting the customer back to a specific day in their own past with enough detail that the four forces become legible without anyone naming them out loud. Live, that takes an hour and a calendar slot most customers will not accept once they have already switched. Async, in voice, it takes four prompts and a customer's coffee break. Talkful is built for the second shape, and the voice user research guide covers where it sits inside a wider product-research practice.