The Easy Way to Waste an Hour
Most customer interviews are a waste of time. Not because the PM is bad at their job, but because the questions they ask produce answers that sound useful and aren't. The user nods politely. They say nice things. They tell you what you want to hear. You leave feeling validated. Two months later you ship the feature you discussed and nobody uses it.
This pattern is so common that we have a name for it: the polite waste . The interview happened. Words were exchanged. Notes were taken. But nothing was learned. The PM made a decision based on the conversation that they would have made anyway. The user said yes to a feature they will not actually use.
Good interviews are different. They surprise you. They make you rethink something. They reveal a problem you didn't know existed, or kill an idea you were excited about, or change how you understand a customer you thought you understood. This article is about how to run that kind of interview, drawing on Rob Fitzpatrick's book The Mom Test and on twenty years of watching the same mistakes get made by smart people.
Why Most Interview Questions Don't Work
The two questions PMs ask most often are the two questions that produce the worst data. They are:
- Would you use this feature if we built it?
- How much would you pay for this product?
Both are about the future. Both ask the user to predict their own behaviour. Humans are bad at this. We say we will exercise more, save more, eat better, and use the new feature. We don't. The gap between what we say and what we do is huge, and it gets huger when someone we want to be polite to is asking the question.
When you ask a user would you use this , you are asking them to do three things at once: imagine a future product, imagine themselves in a future situation, and predict their future emotional state. They will get all three wrong, and they will give you a confident answer anyway. The answer feels like data. It isn't.
Rob Fitzpatrick names this The Mom Test after a simple rule: don't ask questions that even your mom couldn't answer honestly. Your mom loves you. She wants to encourage you. If you ask her if your idea is good, she will say yes. The same is true of nearly every user, even ones who don't know you. They want to be helpful. They will be polite. So you have to ask questions that don't need their politeness or their predictions to give you the truth.
The Rule That Changes Everything: Ask About the Past
The single most useful change you can make to your interviews is to ask about the past instead of the future. The past is real. It happened. The user did something or didn't. Their answer draws on memory, not prediction. Memory is imperfect, but it is much better than imagination.
Compare these two questions:
- Bad: Would you use a tool that automatically tags your photos?
- Good: Tell me about the last time you tried to find a specific photo on your phone. What happened?
The bad question gets you a hypothetical. The good question gets you a story. The story has detail: how long they spent looking, what they were trying to find, what they did when they couldn't find it, whether they ended up giving up or solving the problem another way. The story also reveals whether the problem is real and how often it happens. None of that is in the hypothetical answer.
More good questions about the past:
- Walk me through what you did this morning.
- Tell me about the last time you got frustrated with this.
- When was the last time you tried to do that, and how did it go?
- What did you try before you came to us?
- Tell me about the last week. What took up the most time?
Notice that none of these mention your product. None ask about the future. None invite a yes-or-no answer. Each one opens up a story, and the stories are where the truth lives.
What to Listen For
Asking the right questions is half the work. The other half is listening to the right things. New PMs often listen for validation: signs that their idea is good. Senior PMs listen for specific things that tell them about the user's real life.
Listen for Specific Pain
When a user describes a problem, the more specific they get, the more real the problem is. It's annoying is not real. Last Tuesday I spent forty-five minutes trying to figure out where the file went, and I had to call my colleague because the client meeting was in ten minutes is real. Specifics tell you the problem actually happened, not just that the user thinks it might happen.
Listen for Workarounds
If the problem is real, the user has probably built a workaround for it. Spreadsheets they maintain on the side. Reminders set on their phone. Notes kept in their drawer. Asking for a colleague's help. The workaround tells you the problem is painful enough that the user invested effort to solve it. No workaround usually means no real problem, even if the user complains.
Listen for Money
If the user has paid for something to solve this problem, even partially, that is the strongest signal possible. They have voted with their wallet. The money does not have to be much. A ten-dollar app, a paid subscription, hiring a freelancer. Money spent is real evidence; words are cheap.
Listen for Time
Time spent is also evidence. If the user dedicates an hour every Monday to a manual process, that is a real problem worth real money. If they shrug about it, it isn't.
Listen for Emotion
Pay attention to when the user gets animated. When they lean forward. When they raise their voice. When they laugh at something they hate. The emotional moments are signal. They tell you what they actually care about, regardless of what they say they care about.
How Many Interviews to Run
A common question is how many interviews you need. The honest answer is that you keep going until you stop hearing new things. For most product questions, this happens between five and fifteen interviews. After fifteen, you are usually paying diminishing returns.
There are exceptions. If your users are very different from each other (different roles, different industries, different countries), you need more interviews to reach the point where patterns emerge. If your users are very similar to each other, five may be enough.
The bigger mistake than running too few is running them in too big a batch. Five interviews, then synthesis, then five more, then more synthesis is much better than fifteen all in one week. You learn between interviews, and that learning shapes the next set of questions. Batching prevents the learning from feeding back into the questions.
How to Set Up an Interview
The setup matters. A user who is rushed, defensive, or performing for an audience will give you worse data than one who is relaxed and honest. A few rules that help.
Set Expectations Up Front
At the start of the call, tell the user three things: this is not a sales call, you want their honest opinions including negative ones, and there are no right answers. This sounds obvious. It changes their behaviour. Without it, they will default to being polite and helpful, which produces bad data.
Keep It Short
Thirty minutes is enough for most interviews. Sixty minutes produces diminishing returns; the second half is usually elaboration on what was already said. Shorter interviews also make it easier to schedule users, which means you do more of them.
Avoid Demos
If the interview is for discovery, do not show the user your product. Showing it changes the conversation from what is your life like to what do you think of this thing . The first conversation is where the insight is. Demos belong in usability tests and sales calls, not discovery interviews.
Have a Plan, Not a Script
Write down five to seven topics you want to cover, in rough order. Don't write the exact wording. The conversation will go in unexpected directions, and you want to follow those directions, not stick to a script. The plan is a safety net, not a roadmap.
Take Notes (or Record)
Memory is unreliable. By the next morning, half of what was said has decayed. Either take detailed notes during the call or record it (with permission) and review later. Note-taking during the call can distract from listening, so a common approach is to jot key phrases and quotes only, then write up fully right after the call.
Common Mistakes
Mistake One: Pitching Instead of Listening
PMs love their products. They want users to love them too. So they pitch, even unconsciously. They describe the feature, explain the vision, ask leading questions. The user, sensing what the PM wants to hear, gives it to them. Discovery becomes validation theatre. The fix is to bite your tongue. The PM should be talking less than thirty percent of the time. If you find yourself explaining your product, stop.
Mistake Two: Asking Leading Questions
Don't you find it frustrating when X happens? Wouldn't it be nice if Y existed? Both questions telegraph the answer the PM wants. Users will agree, even if X doesn't actually frustrate them and Y wouldn't actually be nice. Replace leading questions with neutral ones. Tell me about your typical Monday morning. What's the most annoying part of this workflow?
Mistake Three: Not Going Deeper
When a user says something interesting, the natural impulse is to nod and move on. Resist it. Ask why. Ask for an example. Ask what happened next. The interesting answer is rarely on the surface; it is two or three follow-up questions deep. Senior interviewers spend more time on each topic than junior ones, because they keep going past the first answer.
Mistake Four: Talking to the Wrong People
Your friends, your team, and people who already love your product are the easiest to interview. They are also the worst sources of insight. They want to help you. They share your biases. They are not representative. Talk to people who don't yet use your product, who recently churned, or who chose a competitor. The uncomfortable conversations are the useful ones.
Mistake Five: Treating Each Interview as a Verdict
One user said the feature is great, so it is great. One user said it is bad, so it is bad. Neither single interview should carry that much weight. Patterns across multiple interviews matter. The first interview gives you a hypothesis. The fifth tells you whether the hypothesis is real.
Synthesising What You Heard
Interviews are useful only if you make sense of them. After running a batch, set aside time to look across all of them. Look for patterns, not exceptions. Look for things multiple users said in different words but with the same meaning.
Write a Short Summary After Each Call
Within an hour of the call, write down: who you talked to, what their context is, what surprised you, what you now believe that you didn't before, and what new questions you have. Keep it short. Half a page is plenty. The discipline of writing forces you to commit to specific learnings rather than vague impressions.
Look for Patterns Across Calls
After five interviews, read the five summaries side by side. What did multiple users say? What problem came up repeatedly? What workarounds did several users have? Where did users disagree, and what does that disagreement reveal? The patterns are the insights. A single user saying something is interesting; three users saying the same thing in different words is a finding.
Distinguish Signal from Noise
Not everything you hear is signal. Some is the user's personal preference, their unusual context, or their idiosyncrasy. Signal is what generalises across users. The discipline is to weight patterns over individual quotes, even when an individual quote is memorable.
When to Run Interviews
Interviews are most valuable at certain points and less valuable at others. Knowing when to run them helps you spend the time well.
- Most valuable: when you are entering a new problem space, considering a major bet, or trying to understand why something isn't working. Discovery moments.
- Valuable: as a continuous practice, even when nothing specific is on the table. The accumulated context shapes every decision later.
- Less valuable: when the team has already decided what to build and is just looking for confirmation. Interviews won't change the decision; they will just be theatre.
- Not valuable: when the question is about how the product behaves at scale, what percentage of users do something, or whether a feature works mechanically. Use analytics or testing for those.
A Final Word
The PM who runs five honest interviews per month for two years knows their users at a level no amount of reading can match. The skill is built by doing it repeatedly, getting it wrong, noticing what didn't work, and adjusting. The first ten interviews you run will be mediocre. The hundredth will not.
If you take one practice from this article, take this: pick three users this week. Schedule thirty minutes with each. Ask them to walk you through their last week, with an emphasis on the parts your product touches. Don't pitch. Don't lead. Just listen. After each call, write half a page of what you learned. Read all three summaries together. You will find at least one thing you didn't know. That is the start of a practice that will compound for the rest of your career.
Key Takeaways
- Ask about the past, not the future. Stories about what happened beat predictions about what would happen.
- Listen for specifics, workarounds, money spent, time spent, and emotional moments. These are the signals of real problems.
- Five to fifteen interviews is usually right. Run them in batches of five with synthesis between, not all at once.
- Avoid pitching, leading questions, and surface-level follow-ups. The PM should talk less than thirty percent of the time.
- Synthesise after each batch. Patterns across multiple interviews are the insights; single quotes are not.