In the previous installment, we looked at the real purpose of a customer interview and the four warning signs of a bad one. A second failure mode is just as common, and it tends to hide in plain sight: running every interview the same way.
Teams sit down with users at every stage of the product lifecycle — before product-market fit, after launch, during optimization — and ask roughly the same set of open-ended questions. The transcripts pile up. The insights blur. Decisions stall because the data points in too many directions at once.
The fix has two parts. First, recognize that there are different types of user interviews, each built for a specific decision. Mix them, and the signal gets noisy. Second, no matter which type you run, pull stories about what actually happened — not opinions about what users think they would do. The right type of interview combined with the right type of question produces signals you can act on.
This guide covers the four types of user interviews most product teams need (exploratory, validation, satisfaction, and efficiency) and the one principle that holds across all of them.
The 4 Types of User Interviews (And When to Use Each)
Not every interview has the same goal. When the goals get mixed, the data gets messy: an exploratory chat slides into a sales pitch, a satisfaction survey turns into a feature wishlist, and the team walks away with notes that contradict each other.
Four types cover most of what product and design teams need. Each has a clear purpose, a moment in the product lifecycle when it pays off, and a different kind of question that drives the conversation.
1. Exploratory Interviews: Discover Pain Points Before Forming Strong Hypotheses
Purpose: Uncover pain points and understand context before you commit to a strong hypothesis.
When to use: Early stages, before product-market fit, or when entering a new market segment.
Key questions:
- “Tell me about the last time you experienced [problem area].”
- “Walk me through how you currently handle [task] today.”
The goal here is breadth, not depth. You are mapping the landscape — who has the problem, in what shape it shows up, and what they are doing about it now. The biggest mistake at this stage is bringing your solution into the room. If you describe a feature, users will react to the feature. If you ask about their last actual experience, they will describe their world.
2. Validation Interviews: Test Specific Hypotheses Without Revealing the Solution
Purpose: Test a specific hypothesis about the problem, the solution, or willingness to pay.
When to use: When you have a clear hypothesis to prove or disprove.
Core rule: Do not reveal the solution too early. The moment you describe what you are building, the conversation shifts from understanding behavior to evaluating an idea. Ask first about current behavior and about past attempts to solve the problem. Once the solution enters the room, bias colors everything that follows.
Wrong: “We are building a tool that automates expense reports — would you use it?”
Right: “Tell me about the last time you submitted an expense report. What was that like?”
A validation interview works like a controlled experiment. If you ask a patient, “Do you think this drug will work?”, the placebo effect kicks in. You learn what they want to believe, not what the drug does. To know whether the drug works, you measure real outcomes before and after. A validation interview does the same: instead of asking, “Would you like this solution?”, you test the hypothesis against the user’s actual behavior data.
3. Satisfaction Interviews: Understand Why Users Love or Leave the Product
Purpose: Understand why customers love your existing product, or why they leave.
When to use: After launch, once you have real users with real usage history.
Key questions:
- “If our product disappeared tomorrow, what would you miss the most?”
- “Have you ever come close to canceling? What was happening at that moment?”
A satisfaction interview is like asking a regular at a favorite restaurant, “How has the food been lately?” The useful answer is not “Great.” The useful answer is, “Honestly, last week it was too salty and I almost stopped coming.” Asking what users would miss surfaces the real value of the product. Asking when they nearly left surfaces the real risk. Both come out of the same conversation if you ask for moments, not impressions.
4. Efficiency Interviews: Find Friction in Existing Workflows
Purpose: Identify friction points and improvement opportunities in an established workflow.
When to use: When you are optimizing a mature product that users already rely on.
Focus: Observe real usage patterns, not hypothetical improvements.
An efficiency interview works like a workflow analysis on a factory floor. Ask the worker, “What should we improve?” and you get, “Better tools.” Watch them work for an hour, and you find them walking the same stretch over and over for materials that could sit at the workstation. Imagined improvements describe what users think they want. Observed behavior shows where the actual bottleneck is.
The Core Principle: Pull Stories, Not Opinions
Every product team eventually learns one lesson the hard way:
Opinions often drift from reality. Stories stay anchored to what users actually do.
Ask for an opinion, and the customer gives you something that sounds rational, professional, and socially acceptable. They are not trying to mislead you. The question itself invites that kind of answer. Ask for a story, and the conversation gets pulled back to the ground:
- what actually happened
- what they tried
- what it cost them (time, money, effort, trust)
- what broke
- what they did next
Insights you can act on come from there.
A simple experiment shows the difference:
| Question type | Sample exchange |
|---|---|
| Opinion question | Interviewer: “What matters most when you subscribe to a work tool — price, features, or ease of use?” Answer: “Probably price and features. I usually compare a few options.” |
| Story question | Interviewer: “Tell me about the last work tool you actually subscribed to.” Answer: “A colleague mentioned it in a meeting. I needed it that day, the trial took two minutes to set up, and I just went with it. I didn’t compare anything.” |
The first answer sounds reasonable. The second answer shows what the user actually did.
Most people do not lie on purpose in interviews. They generalize their memory, simplify the story to fit the question, or reconstruct events under social and psychological pressure without realizing it. Good interviews rest on user stories, not user opinions.
The gap between what users say and what users do is the same gap that exists between a résumé and a job. A résumé (the opinion) says “strong communicator.” Watch the same person in five meetings (the story), and you might see them dominate every conversation or talk over anyone who disagrees. There is always a delta between how people describe themselves and how they behave. Asking for opinions in an interview is reading the résumé. Asking for stories is watching the work.
Conclusion
The right type of interview combined with the right kind of question turns a customer conversation into a real behavior signal. Choose the type that matches the decision in front of you — exploratory, validation, satisfaction, or efficiency — and inside that type, ask for stories about specific moments rather than opinions about general preferences. That combination is what separates an interview that confirms what you already believed from one that actually changes what you build.
The next installment in this series goes deeper into how to ask story-based questions, using the three rules of good questions from Rob Fitzpatrick’s The Mom Test.
Customer Interview Series
(1) Customer Interviews: The Real Purpose and 4 Warning Signs You’re Doing It Wrong
(2) 4 Types of User Interviews and the One Principle That Makes Them Work
(3) The Mom Test: 3 Rules for Asking Better Customer Interview Questions
(4) Customer Interview Questions: A 3-Step Framework and Ready-to-Use Question Library