How to run customer interviews that aren't just flattery

Customer interviews are the most powerful validation tool there is and the easiest to do badly. Done wrong, they're a machine for collecting compliments — you describe your idea, people are nice, you leave encouraged and uninformed. Done right, they surface the truth about whether a problem is real. The difference is entirely in how you ask.

Ask about the past, not the future

The single most important rule: ask about what people have actually done, not what they think they would do. "Would you use a tool that automates your invoicing?" invites a polite, useless yes. "Tell me about the last time you sent invoices — walk me through it" invites a story full of real pain, real workarounds, and real evidence of whether this matters. The future is hypothetical and flattering; the past is concrete and honest.

Don't pitch before you listen

The moment you describe your idea, the interview is contaminated — now the person is reacting to you, and politeness takes over. Spend the first and largest part of the conversation learning about their world and their problem before you mention what you're building, if you mention it at all. The best customer interviews can feel like you never pitched anything, because you were too busy learning.

Dig for specifics

Vague answers hide the truth; specifics reveal it. When someone says the problem is "annoying," push: How often? What did it cost you last time? What did you try? What did you spend? "We lose about two hours every Friday and I've cobbled together three spreadsheets to cope" tells you the problem is real and quantifiable. "It's kind of a pain" tells you nothing.

Know when you've heard enough

After roughly fifteen to twenty interviews with the right segment, you'll start hearing the same patterns — the same pain described in the same words. That repetition is your signal. If after twenty conversations you're not hearing patterns, your segment is too broad: narrow it and start again. And celebrate a clear negative — discovering the problem isn't real after fifteen conversations is a cheap, valuable save compared to discovering it after a year of building.