People in interviews are usually trying to be helpful. That's the problem.
Ask someone whether they'd use a new feature and most will say yes. Saying yes is easier than saying no, and most people genuinely can't predict what they'd do. Polite answers feel like validation and tell you very little.
I first ran customer discovery as a business development intern, validating a B2B engagement platform, and I've done a lot of it since. The biggest improvement in my interviews came from changing the kind of question I asked.
Ask about the past, not the future
Future questions invite guesses. Past questions get facts.
| Instead of | Try |
|---|---|
| Would you use a feature that does X? | Tell me about the last time you needed to do X. |
| How often do you do this? | When did you last do this? Walk me through it. |
| What features would you want? | What was the hardest part of the last time you did this? |
| Would you pay for this? | What do you currently use for this? What does it cost you? |
| Is this a problem for you? | What happened the last time this went wrong? |
The right-hand column gets you stories. Stories have details, and details are where the useful patterns hide.
Follow the specifics
When someone tells you about a recent experience, keep asking for more detail:
- What did you do next?
- How long did that take?
- Who else was involved?
- What did you try that didn't work?
- What happened in the end?
You're trying to reconstruct what actually happened. If they say "I usually just look it up," ask where, and what they found the last time.
Nielsen Norman Group's guidance on user interviews makes the same point about asking open-ended questions and avoiding leading ones. 1
Questions I've stopped asking
- "Do you like this?" Almost everyone says yes.
- "Would this be useful?" Same.
- Anything starting with "Wouldn't it be great if..." That's a pitch, not a question.
- "What would you build?" Users are great at describing problems and not always great at designing solutions.
Don't show the solution too early
If you show a prototype in the first five minutes, the rest of the interview becomes feedback on the prototype. That's useful sometimes, but it's a different kind of session.
I prefer to spend most of the interview understanding the current situation, and only show anything at the end, if at all. That way I learn about the problem before the person's thinking gets shaped by my idea.
Listen for workarounds
Workarounds are one of the strongest signals of a real problem. If someone has built a spreadsheet, a set of reminders or a manual process to deal with something, it matters to them.
Ask them to show you the workaround if they can. It often tells you more than anything they say.
Write it up the same day
Memory fades fast and reshapes itself around what you hoped to hear. I write a short summary within a few hours: the key story, notable quotes, workarounds, and anything that surprised me.
Then I look for patterns across several interviews before drawing conclusions. One interview is an anecdote. A handful with the same pattern is something worth testing, which is where the discovery before MVP post picks up.
Get consent and keep it proportionate
Ask before recording. Tell people how notes will be used and who'll see them. Don't collect more personal detail than you need for the research.
The most useful interviews I've done felt more like a conversation about someone's work than a test of my idea. If you find yourself defending your concept during an interview, you've probably stopped listening.