Lesson 12: Customer Interviews

Lesson 11 established the theory: qualitative research answers why/how questions, revealed preference beats stated preference, and several specific biases (confirmation bias, leading questions, social desirability bias, the "would you use this" trap) distort findings if not deliberately controlled for. This lesson is where that theory becomes a skill you can actually execute in a room — or on a call — with a real person, in real time, under the real pressure of wanting to hear a particular answer.

A customer interview is a structured, one-on-one conversation designed to surface a person's actual past behavior, context, and reasoning — not their opinions about hypothetical futures, and not a pitch dressed up as a conversation. The central discipline of a good interview is almost the opposite of what feels natural in a normal conversation: instead of asking what someone thinks, wants, or would do, a skilled interviewer asks about what someone has actually done, in as much concrete, specific detail as possible, because specific past behavior is a form of revealed preference (Lesson 11) that is far more reliable than a hypothetical opinion.

This lesson matters because customer interviews are simultaneously the most commonly used and the most commonly misused research method in product work. Nearly every PM conducts interviews at some point; comparatively few conduct them in a way that reliably produces trustworthy evidence rather than a comfortable, leading, self-fulfilling conversation. The gap between a good interview and a bad one is not raw talent — it is a specific, learnable set of techniques, which this lesson covers directly.

Learning Objectives

1
Distinguish a "past-behavior" interview question from a hypothetical or opinion-based question, and explain why the former produces more reliable evidence.
2
Apply the "switch interview" structure to uncover the specific moment and forces that led someone to adopt, or seriously consider adopting, a new solution.
3
Identify and avoid the most common interviewer mistakes: leading questions, pitching instead of listening, accepting vague answers, and interviewing only easy-to-reach participants.
4
Distinguish a customer interview conducted for discovery purposes from one conducted for usability testing, and explain why conflating the two produces weaker results for both.
5
Apply the "Five Whys" and silence techniques to move a conversation from a surface-level answer to a genuinely underlying one.

Lesson 6 (Jobs To Be Done) and Lesson 11 (User Research). This lesson assumes fluency with the laddering technique from Lesson 6 (which customer interviews are the primary vehicle for conducting) and with the stated-versus-revealed-preference distinction and bias list from Lesson 11, which this lesson translates into concrete interviewing technique.

Past-Behavior Questions vs. Hypothetical and Opinion Questions

The single most important technical skill in customer interviewing is the discipline of asking about specific past behavior rather than hypothetical future behavior or general opinion. Consider three ways of asking about the same underlying topic:

Hypothetical (weak): "Would you use a feature that let you set spending limits per category?"
Opinion (weak): "What do you think about budgeting apps in general?"
Past behavior (strong): "Tell me about the last time you tried to stick to a budget. Walk me through exactly what happened."

The past-behavior question is dramatically more reliable, for reasons directly tied to Lesson 11's stated-versus-revealed-preference distinction: a hypothetical question asks someone to predict their own future behavior, which people are demonstrably bad at, and costs nothing to answer generously; an opinion question invites abstract, socially acceptable answers disconnected from lived experience; a past-behavior question asks for a specific, real memory, which is far harder to answer with a comfortable, generic platitude, and which tends to surface concrete detail — including friction, workarounds, and abandoned attempts — that a hypothetical question would never reveal.

The Switch Interview Structure

A particularly powerful, structured application of past-behavior questioning is the switch interview (closely associated with Bob Moesta's applied Jobs to Be Done work, previewed in Lesson 6's Forces of Progress model), which focuses specifically on the moment someone adopted, or seriously considered adopting, a new solution. The structure moves through a specific sequence:

First thought: "When did you first start thinking you might need something like this?" — establishing the earliest moment of dissatisfaction (the Push force from Lesson 6).
Passive looking: "What did you do next? Did you look into any options at that point, even casually?"
Active looking: "What made you go from casually considering this to actually seriously looking for a solution?" — often revealing a specific triggering event, not a gradual, generic realization.
Deciding: "Walk me through how you actually chose [this solution] over the alternatives you were considering." — surfacing the Pull force and the specific comparison being made.
Anxiety and habit at the moment of commitment: "What almost stopped you from going through with it?" — directly surfacing the Anxiety and Habit forces from Lesson 6's Forces of Progress model.

This structure is powerful precisely because it anchors the entire conversation in a real, specific, already-completed event, rather than a general opinion or a hypothetical scenario — every question asks about something that actually happened, in a particular order, which the respondent can recall concretely rather than construct on the spot.

Common Interviewer Mistakes

Leading questions (introduced in Lesson 11) remain the most pervasive interviewing mistake, but several additional, interview-specific mistakes deserve direct attention:

Pitching instead of listening. An interviewer excited about their own product idea often unconsciously turns an interview into a sales pitch — describing the proposed solution and gauging reaction, rather than first fully understanding the respondent's existing behavior and pain independent of any proposed solution. Once a solution has been described, the respondent's subsequent answers are contaminated by anchoring toward that specific solution, making it much harder to learn what they would have said, or wanted, absent that framing.
Accepting vague answers. A respondent saying "it was frustrating" or "I just wanted it to be easier" is common, and an inexperienced interviewer often moves on, treating this as sufficient detail. A skilled interviewer follows up specifically: "What does 'frustrating' mean, concretely — what happened, step by step, that felt frustrating?" Vague language is a signal to dig deeper, not a finished answer.
Interviewing only easy-to-reach participants. Directly echoing Lesson 11's representativeness concern, interviews conducted only with the most available, most enthusiastic, or most vocal customers systematically miss the perspectives — often including churned users, skeptical prospects, or quietly dissatisfied customers — that would most challenge the team's existing assumptions.
Filling silence too quickly. When a respondent pauses after a question, an uncomfortable-feeling silence often tempts the interviewer to jump in with a clarifying suggestion or a multiple-choice-style prompt. This frequently short-circuits the respondent's own, more genuine train of thought — deliberately tolerating a few seconds of silence often produces a more considered, more useful answer than immediately rescuing the respondent from having to think.

Discovery Interviews vs. Usability Interviews

A conceptually important distinction, often blurred in practice: a discovery interview aims to understand a person's existing behavior, context, and needs — usually before a specific solution exists, or independent of one — while a usability interview (more precisely, a usability test conducted with an interview component) aims to observe how a person interacts with a specific, already-built prototype or product, to identify points of confusion or friction.

Conflating these two produces a specific, recognizable failure: a session framed as "discovery" that spends most of its time reacting to a shown prototype has, without anyone quite deciding to make this trade, actually become a usability session — collecting reactions to a specific proposed solution rather than the more foundational, solution-independent understanding discovery is meant to produce. Neither type of session is superior; they simply answer different questions, and a PM should be deliberate about which one they are running in a given conversation, rather than drifting between the two without noticing.

Digging Deeper: The Five Whys and the Power of Silence

Two specific, complementary techniques help move a conversation from a surface-level answer to a genuinely underlying one, directly extending Lesson 6's laddering technique into live interview practice:

The Five Whys: repeatedly asking "why" (or a softer equivalent, like "what made that important to you?") in response to a stated reason, until reaching an explanation that feels genuinely foundational rather than another intermediate justification. As in Lesson 6, this has a natural stopping point — the most specific, stable explanation, not the most abstract one imaginable.
Tolerating silence: as described above, resisting the urge to fill a pause immediately after asking a question, giving the respondent genuine space to think past their first, most readily available answer.

Used together, these techniques counteract a natural tendency in conversation — both interviewer and respondent are inclined to treat the first plausible-sounding answer as sufficient and move on — that, left unchecked, produces exactly the kind of surface-level, insufficiently specific finding this lesson (and Lesson 11) warns against.

Common Mistakes to Avoid

Asking "would you use this?" partway through an interview, then treating the answer as reliable evidence

As covered in Lesson 11, this remains one of the single most reliable ways to generate falsely confident, stated-preference-only validation — an interview format doesn't inoculate against this trap; it requires the same discipline of avoiding hypothetical framing.

Describing the proposed solution before fully understanding the respondent's existing behavior

Once a solution is on the table, every subsequent answer is anchored to it, making it far harder to learn what the respondent's actual, solution-independent experience and need really are.

Treating a vague answer as a complete answer

"It's frustrating" or "I wish it were easier" are starting points, not findings — a skilled interviewer follows up for concrete, specific detail rather than recording the vague version as the finding itself.

Recruiting only friendly, easy-to-reach participants

This produces exactly the unrepresentative sample problem from Lesson 11 — a systematic bias toward the perspectives of people already inclined to be positive and engaged, at the expense of skeptics, churned users, or people who never adopted the product at all.

Rushing past silence

Jumping in to rescue a respondent from a pause, or offering a multiple-choice-style prompt ("was it more about cost, or more about time?") before they've had a chance to answer in their own words, often produces a shallower, more interviewer-shaped answer than genuine patience would have.

Customer Interviews