Here's an uncomfortable truth about customer interviews: most of them produce fiction.
Not because customers are dishonest people. Because they're polite, because they want to be helpful, because they're bad at predicting their own behavior, and because we ask questions that practically beg for pleasant lies. "Would you use this?" "Sure, looks great!" Three months later the feature ships to crickets.
The fix isn't interviewing less. It's interviewing in a way that makes lying hard. Most of this comes down to a single principle, borrowed from Rob Fitzpatrick's The Mom Test: ask about their life, not your idea. Ask about the past, not the future.
Why People Lie in Interviews
Understanding the failure modes helps you design around them:
- •Politeness. Criticizing your idea to your face is socially expensive. Approving costs nothing.
- •Prediction failure. "Would you pay $20/month for this?" asks someone to simulate a future self. Humans are terrible at this even with full honesty.
- •Aspirational self-image. People report the behavior of who they'd like to be. Everyone claims they'd read documentation.
- •Leading questions. "Don't you find the export process frustrating?" tells them the answer you want. Most people will give it to you.
None of these can be fixed by better rapport. They're fixed by better questions.
Questions That Get the Truth
The pattern: past behavior, specific instances, concrete details. Compare:
Bad: "Would you use a tool that automated your reporting?" Good: "Tell me about the last report you had to produce. Walk me through exactly what you did."
Bad: "Is data quality a problem for you?" Good: "When was the last time bad data caused a real problem? What happened?"
Bad: "Would you pay for this?" Good: "What have you spent money on to try to solve this? What did you cobble together yourself?"
The good versions are all archaeology. They dig up facts that already exist, which is why the answers are trustworthy. Some questions that earn their place in almost any interview:
- •"Walk me through the last time that happened, step by step."
- •"What did you try before? Why did you stop?"
- •"Who else is involved when this goes wrong?"
- •"What happens if you just... don't do this task?"
- •"You mentioned X was annoying. What have you done about it?"
That last one is the money question. If someone has a problem but has never attempted a workaround, never searched for a tool, never asked a colleague, then it's not a real problem. It's a mild irritation that will never drive adoption. Workarounds are receipts. Spreadsheets held together with hope are the strongest buying signal in software.
Running the Session
Before
Know what you're trying to learn. Write down two or three assumptions this round of interviews should test. This connects the interview to your broader discovery process; an interview without a target assumption is just a nice chat.
Recruit for the segment that matters. Five interviews with the right people beat twenty with whoever answered the email. If you're testing an enterprise admin problem, five enterprise admins.
During
- •Talk 20%, listen 80%. If the transcript shows you talking half the time, you ran a demo, not an interview.
- •Silence is a tool. After they answer, wait three seconds. The second answer, the one that fills the silence, is often the real one.
- •Follow surprise. When something contradicts your assumptions, that's the vein of gold. "Wait, tell me more about that" beats moving to your next scripted question.
- •Don't pitch. The moment you start selling, honesty ends. If they ask what you're building, "we're still figuring that out, which is why this conversation helps" is true and sufficient.
- •Get specifics on frequency and stakes. "How often does that happen? What did it cost you last time?" turns anecdote into evidence.
Record with permission, or bring a note-taker. You cannot simultaneously interview well and capture verbatim quotes.
One structural tip for the session itself: spend the first few minutes on their context before going anywhere near your topic. Role, team, what a normal Tuesday looks like. It warms up the conversation, and half the time the context answers questions you didn't know to ask. The workflow they describe in passing is often more revealing than anything in your script.
After
Debrief within 24 hours, while it's fresh. Capture: what did we hear (verbatim quotes, not paraphrase), what surprised us, what does this do to our assumptions? Paraphrase is where bias creeps in. "Users want better reporting" might be your summary of a user who actually said "I export to Excel because I don't trust your numbers." Those are very different problems.
The Prototype Conversation Is Different
Everything above covers problem interviews. When you're showing a prototype, the rules shift slightly, but the honesty problem remains. People will compliment your mockup because you clearly made it.
Counters:
- •Give tasks, not tours. "Try to set up a weekly report" and then be quiet. Watching someone struggle tells the truth their words won't.
- •Ask comparative questions. "How does this compare to how you do it today?" invites honest ranking better than "do you like it?"
- •Ask for commitment, not opinion. "Can I follow up when the beta's ready? Would you put a weekly slot on your calendar to use it?" Watch what they do with a real ask. Enthusiasm that evaporates at the smallest commitment was politeness all along.
How Many Interviews Do You Need?
Fewer than you fear, more than one. For a given segment and question, patterns usually stabilize somewhere around five to eight conversations; by then you're hearing repeats. If every interview still surprises you, either your segment definition is too broad or the space is genuinely more varied than you thought. Both are findings.
What matters more than volume is cadence. A team that talks to customers every week compounds understanding. A team that does twelve interviews once a year has a stale snapshot. This is the heart of continuous discovery, and it's cheaper than it sounds: two interviews a week is two hours.
Common Ways PMs Sabotage Themselves
- •Interviewing only happy customers. Churned users and users of competitors know things your fans don't.
- •Letting sales pick the participants. You'll get the reference customers, hand-selected for enthusiasm.
- •Treating one vivid quote as truth. One customer's colorful complaint is a hypothesis, not a mandate. Look for the pattern across interviews, and check it against data (our product metrics guide pairs well here).
- •Asking the roadmap question. "What should we build?" outsources your job to someone without context. Users are experts in their problems and amateurs in your solutions. Extract the problem; the solution is on you.
The Bottom Line
Ask about their life, not your idea. Past behavior, not future intentions. Specific instances, not generalities. Hunt for workarounds and real commitments, because those are the signals that can't be faked out of politeness.
Do this on a weekly cadence and you'll build the kind of user understanding that makes prioritization calls obvious and product sense interview answers effortless, because you'll be drawing on real people instead of hypotheticals.
Want to practice on a new product and a new set of customers? Browse open PM roles at productmanagerjobboard.com.