A founder shows his mother an app concept and asks, “Would you buy a cookbook app for iPad?” She pauses, then says it sounds lovely. He keeps pushing: it’s only $40, cheaper than the cookbooks on her shelf, and you can share recipes with friends. She nods along, even suggests a small feature. He walks out convinced he has a viable product.
This is the opening scene of Rob Fitzpatrick’s The Mom Test, and it captures a problem that quietly ruins most customer interview questions. Even your own mother will lie to be polite. If the way you ask makes a polite “yes” the easiest answer, every interview becomes a confirmation-bias machine. Stack that across dozens of conversations and a real business, and you are not learning about customers — you are gathering encouragement.
The previous post in this series covered the four types of customer interviews and the principle of pulling stories instead of opinions. This article turns that principle into three concrete rules for the questions themselves. Each rule names a specific failure mode, shows how to apply it, and flags a pitfall that traps even experienced interviewers.
Rule 1: Focus on the Customer’s Life, Not Your Idea
The moment you open with your idea, the interview stops being research and turns into a pitch. The customer becomes a judge. You become the presenter. The conversation shifts from finding truth to keeping things polite.
This pattern is especially dangerous with senior stakeholders and friendly users, who tend to fall back on three reflex responses:
- Encouragement (“That sounds useful!”)
- Brainstorming (“You should also add a feature for X.”)
- Hypothetical buy-in (“Teams would probably use something like this.”)
None of these are evidence. They are social lubricants. A customer interview that collects them looks productive but produces no signal about whether anyone will actually change their behavior.
How to Apply It: Start From Current Behavior and Constraints
Begin where the customer’s day already happens. The things you need to understand are concrete:
- What their current workflow looks like
- Which tools or workarounds they already use
- What triggers the problem
- The exact moment the pain shows up
Compare three versions of the same intent:
- Bad: “Would you use a dashboard that tracks X?”
- Better: “How are you tracking X today?”
- Best: “Walk me through the last time you needed X. What did you open first?”
The first question asks the customer to evaluate your idea. The second asks them to describe a habit. The third anchors the answer to a specific event, where memory is far more reliable than judgment.
Pitfall to Avoid: Same Intent, Different Words
The most common failure is rewording the question without changing its intent. “How would this feature fit into your workflow?” sounds open, but it still points the customer at your solution and asks them to imagine fitting it in.
A safer version drops the feature entirely: “Walk me through a typical day, and tell me where X comes up.” Now the customer is describing their world, and you are listening for where your idea might or might not have a place.
If you ask a fish whether your bait looks tasty, you will not get a useful answer. You watch where the fish already feeds, what currents it lives in, and what conditions make it bite. The goal of the interview is not to evaluate your bait — it is to understand the fish.
Rule 2: Ask About Past Events, Not Hypotheticals
Hypothetical questions send people into their imagination. Imagination is clean. Real behavior is messy. It happens inside deadlines, approval chains, tool limits, social pressure, timing, and the workarounds people use to keep things “good enough.” None of that constraint set shows up when a customer is daydreaming about what they “would” do.
Past events drag the constraints back into the room. The customer cannot answer a question about what they did last Tuesday without reconstructing the real context — who else was involved, what was due, what they tried first, where it broke.
How to Apply It: Convert Hypotheticals Into Past-Event Questions
A simple substitution handles most cases:
| Hypothetical question | Past-event question |
|---|---|
| “Would you ever do X?” | “When was the last time you did X?” |
| “Do you usually do X?” | “Tell me about the last time you did X.” |
| “Would you pay for this?” | “What did you buy the last time, and who approved it?” |
Two concrete examples make the shift visible:
- “Would you pay for automation here?” becomes “Have you ever spent money to solve this problem? What did you buy, and what pushed you to buy it?”
- “Would your team use this every week?” becomes “When was the last time this problem came up? What else was happening that week?”
Each rewrite trades a clean prediction for a specific story. The story is harder to manufacture and far more useful.
Pitfall to Avoid: When the Customer Can’t Remember a Recent Example
Sometimes the customer genuinely cannot recall a recent instance. That blank itself is data. If a problem is hard to remember, it usually means one of three things:
- It happens rarely
- It is not painful enough to register
- It is not a top priority
Two follow-ups turn the silence into signal:
- “If it’s hard to remember, does that mean it doesn’t come up often?”
- “What usually takes priority over this?”
The answers tell you whether the problem you are investigating actually deserves a place on your roadmap.
The difference between hypothetical and past-event questions is the difference between a weather forecast and a journal entry. “Will it rain tomorrow?” is a guess. “What did you do when it rained last Tuesday?” is a fact. People idealize when they predict the future. They describe what actually happened when they remember the past.
Rule 3: Talk Less, Listen More (Use Silence Deliberately)
Most interviewers talk too much for the same reason: they want to be helpful. They explain, suggest, rephrase, and rush to fill silence. Unfortunately, every one of those instincts kills signal.
When you talk too much in an interview, four things happen, often without you noticing:
- You plant specific ideas in the customer’s head
- You narrow the range of answers they consider
- You teach them which responses you find “correct”
- You replace natural discovery with a script that already has answers
Each of these collapses the interview’s resolution. By the end, the customer is matching your expectations rather than describing their world.
How to Apply It: Three Habits for Better Listening
Three habits do most of the work:
- Ask one question at a time. Questions that bundle multiple topics produce fragmented answers. You also lose the ability to know which part the customer was responding to.
- Use silence on purpose. Ask, then stop. The most useful details often arrive after the first tidy answer, when the customer keeps thinking out loud.
- Mirror ambiguity back. When an answer turns vague, reuse the customer’s own words to ask again:
- “You said it was ‘confusing’ — what was confusing about it?”
- “You mentioned an approval process. Who approves what, and what do they check?”
Echoing the customer’s language keeps you on their terms instead of swapping in your interpretation.
Pitfall to Avoid: Listening More Doesn’t Mean Going Passive
Listening more is not the same as going quiet. The point is to draw the customer’s story deeper without steering it toward your solution. Active listening uses four specific tools:
- Anchor to a specific timeframe (“Last month? Last week?”)
- Ask for a concrete instance (“Walk me through one example.”)
- Probe the emotion (“What did that feel like at the time?”)
- Check the constraint (“Was it the money, the time, or the approvals?”)
A good counselor rarely shares their own opinion. They use brief questions and deliberate silence so the client tells their own story. “How did that feel?” — four words — pulls out more than ten minutes of explanation would. Interviews work the same way: the less you say, the more truth the customer reveals.
The 3 Rules at a Glance: Quick-Reference Table
| Rule | Signal you’re looking for | Bad question pattern | Good question pattern |
|---|---|---|---|
| Rule 1: Focus on the customer’s life. Start from how the customer works today, not from your solution. | Existing workflow, tools, workarounds, the trigger for the pain | “Would you use a dashboard for X?” / “How would this feature fit into your workflow?” | “How are you tracking X today?” / “Walk me through the last time X came up.” |
| Rule 2: Ask about past events. Past behavior reveals real priorities and real constraints. | Frequency, urgency, money already spent, who decided | “Would you ever do X?” / “Do you usually do X?” / “Theoretically, would you do X?” | “When was the last time you did X?” / “What did you buy last time, and who approved it?” |
| Rule 3: Talk less, use silence. Create space for the customer’s story instead of filling it with your own. | Hidden steps, emotional cues, unspoken constraints | Explaining your idea during their answer / rushing to fill silence / asking multi-part questions | Pausing after the answer / mirroring the customer’s words / one clear question at a time |
The table is not just a reference. Treat it as a self-audit tool before, during, and after every interview:
- Before the interview: pick one “good question pattern” per rule and write the follow-ups you would use if the customer answers thinly.
- During the interview: if you catch yourself explaining, stop and pause. The pause is the work.
- After the interview: review your notes against the second column — did you actually capture frequency, urgency, hidden steps? If not, the interview probably slipped back into asking for opinions.
If two of the three rules feel obvious but the third still slips in every conversation, that is the rule worth practicing first.
Conclusion
The three rules look like separate techniques, but they share one underlying principle: pull observable behavior, not opinions. Focusing on the customer’s life pulls behavior from context. Asking about past events pulls behavior from memory. Talking less pulls behavior from the silences your questions create. Every “good question pattern” in the table is a different way to keep the conversation anchored to something the customer actually did.
The next post in this series takes these rules out of the question-by-question view and into a three-step framework for running the full interview, along with a ready-to-use question library for problem importance, feature requests, emotional signals, and the questions most teams are afraid to ask.
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