How to Run Customer Discovery Interviews That Actually Surface Real Problems
Most discovery interviews collect polite opinions, not evidence. Six ways to ask questions that surface real problems — concrete instances, workarounds, and costs instead of hypothetical enthusiasm.
How to Run Customer Discovery Interviews That Actually Surface Real Problems
Most discovery interviews fail quietly. The PM asks a question, the customer gives a polite, plausible answer, and everyone leaves the call thinking they learned something. What actually happened is the customer described a hypothetical future, not a real past — and a roadmap built on hypotheticals is a roadmap built on guesses wearing a research citation. The fix isn't asking more questions. It's asking questions that can't be answered with an opinion.
1. Ask about the last time it happened, not what they'd want
"Would you use a feature that does X?" produces a yes almost every time — agreeing costs the customer nothing and feels helpful. "Walk me through the last time you ran into this problem" produces something you can't fake: a specific Tuesday, a specific workaround, a specific amount of time lost. If they can't recall a concrete instance, the problem probably isn't painful enough to build for yet, no matter how enthusiastically they nod at your feature idea.
2. Interview for the problem before you've built anything to pitch
The moment a customer knows what you're building, every answer they give is filtered through "will this make the PM feel good." Discovery interviews run before a solution exists don't have that bias — you're not pitching, you're just listening to how someone currently solves (or fails to solve) a problem. If you must show something, show it last, after you've already heard the unprompted version of their world.
3. Follow the workaround, not the wish
Customers are bad at describing what they want and good at describing what they're currently doing. A spreadsheet cobbled together at 11pm, a Slack channel that's become an unofficial ticketing system, a manual export-and-reformat step every Monday — these workarounds are the most honest signal in the interview. They tell you the problem is real enough that someone spent real effort solving it badly, which is a far stronger buy signal than "yeah, that would be nice to have."
4. Quantify the cost, even roughly
"How much time does that take you?" and "how often does it happen?" turn a vague complaint into a number you can prioritize against every other vague complaint in your backlog. A problem that costs someone twenty minutes a week is a different bet than one that costs a team two days a quarter — but both can sound equally urgent in the room if you never ask for the arithmetic.
5. Let silence do the work
The instinct to fill a pause with a follow-up example or a leading clarification is the single most common way PMs contaminate their own data — the customer ends up agreeing with the example instead of generating their own. Ask the open question, then stop talking. The extra three seconds of silence is usually where the real answer, the one they hadn't rehearsed, shows up.
6. Write down the words, not your interpretation
The gap between "customer said the export is confusing" and your notes reading "customer wants better UX" is where discovery insight quietly turns into discovery fiction. Capture the customer's actual language and the specific moment they described. Synthesis and pattern-spotting come later, across many interviews — if you synthesize inside the interview itself, you've replaced ten data points with one opinion, yours.
Final thoughts
Good discovery interviews aren't more polished conversations — they're conversations engineered to resist politeness. Ask about the last real instance, watch for the workaround, get a number, and let silence pull out the unrehearsed answer. Do that consistently across even five or six interviews and you'll have a stronger prioritization case than a hundred survey responses to hypothetical features. When you do ship something that came out of this process, that's exactly the kind of evidence-backed story worth turning into a case study — and worth having on a portfolio a hiring manager will actually read next to your PRD.
Start your portfolio here — free, no credit card.
FAQ
What questions should you ask in a customer discovery interview?
Ask about the last concrete time the problem happened, not whether they would want a hypothetical feature. "Walk me through the last time this came up" surfaces specifics — a workaround, a time cost, a real Tuesday — that "would you use X?" never does, because agreeing to a hypothetical costs the customer nothing.
Why do customer interviews often produce misleading feedback?
Because the questions ask for an opinion instead of a memory. Customers are polite and want to be helpful, so hypothetical questions get enthusiastic hypothetical answers. Asking for a specific past instance, and quantifying its cost, filters out politeness and leaves you with evidence.
Should you show a prototype during a discovery interview?
Not early. Once a customer sees what you're building, their answers start getting filtered through wanting to be encouraging. Spend most of the interview on how they currently experience the problem — including their workaround — and save any prototype or concept for the very end, if at all.
How many customer discovery interviews are enough?
There's no fixed number, but a consistent pattern across five or six interviews using concrete, non-leading questions is usually a stronger prioritization signal than a much larger survey full of hypothetical questions. Depth and question quality matter more than raw interview count.
Related reading