Discovery Methods

Teams reach for interviews the way some people reach for a hammer - for every job, whether it fits or not. But "how many users hit this problem?" and "why do they hate the current tool?" are different questions, and they need different methods. Before you pick a tool, get clear on what you're actually trying to learn.

Learn on the move: press play and turn your commute, walk or drive into time that grows your design career.

Listen to the full Discovery Methods course on DesignPath
Share
Share

Match the Method to the Question

Each method answers a different kind of question. Pick by what you need to know, not by what's easiest to run.

Talk - interviews.Best for why: motivations, frustrations, the story behind a behaviour. You get depth, not numbers.

Watch and test - observation and prototype showing.Best for what people actually do, which is often not what they say. You catch the workaround and the moment of confusion.

Ask at scale - surveys.Best for how many and how often: measuring how widespread a pattern is once you've found it.

Read - desk research.Best for what's already known: existing reports, reviews, and data you can use before spending a minute on primary research.

Depth vs Scale

There's a trade-off running through all of this. Talking and watching give you deep understanding from a few people. Surveys and desk research give you breadth from many, but shallow. You usually want to move from depth to scale: interview a handful to understand the problem, then survey to check how common it is.

Pro tip: If you can't say what decision a piece of research will change, don't run it. Method choice starts from the decision you're stuck on, not from "we should do some research."

Combine to Be Sure

No single method gives you the full picture. The strongest discovery triangulates - it lines up two or three methods and looks for where they agree.

If interviews suggest a pain, observation shows people hitting it, and a survey says 60% feel it too, you have something solid. If only one method points to it, treat it as a lead, not a fact. Agreement across methods is what turns scattered signals into confidence.

Where AI Helps

Prompt: "I need to learn [specific question] about [users]. Recommend which discovery methods fit best, in what order, and what each one will and won't tell me."

AI suggests the method mix; you match it to your real constraint.It can map questions to methods quickly, but it doesn't know your timeline, budget, or access to users. Use its suggestion as a menu, then pick what you can actually run this week.

Product Discovery Interviews

There are two very different reasons to sit down with a user, and teams mix them up constantly. One checks whether a design works. The other checks whether a problem is worth solving at all. This article is about the second - the conversation you have before there's anything to show.

Discovery vs Usability Interviews

They look alike - you, a user, some questions - but they aim at opposite ends of the process.

A usability interview puts something in front of the person and watches them use it: "can they do this, and where do they struggle?" It improves a solution you've already chosen.

A discovery interview has nothing to show. You're there to understand their world - what they're trying to get done, what gets in the way, what they've tried: "is there a real problem here, and how much does it hurt?" It helps you choose what to build.

Run a discovery interview like a usability test and you get polite opinions on your idea. Run it well and you get the raw material for a decision.

Ask About the Past, Not the Future

The biggest mistake in discovery is asking people to predict themselves. "Would you use a tool that did X?" almost always gets a yes - it's easy to be generous about a hypothetical, and people don't want to disappoint you.

The Mom Test by Rob Fitzpatrick puts it simply: ask questions even your mum couldn't lie to you on. That means asking about real, specific things that already happened.

  • Not "Would you pay for this?" but "What do you use today, and what does it cost you?"
  • Not "Do you struggle with X?" but "Tell me about the last time you did X. What happened?"

Past behaviour is fact. Future intention is a wish. Build on the facts.

Pro tip: If you catch yourself pitching and watching for a smile, you've drifted into selling. Put the idea away and get curious about their day.

Who to Talk To

Talk to people who live the problem now - current users, people on a competitor, and people using a clumsy workaround. That last group is gold: someone gluing three spreadsheets together every Monday is telling you exactly where a product could earn its place.

Mine Each Conversation

You're not collecting quotes for a slide. Pull three things from every chat:

  • Jobs: what they're really trying to get done ("keep the team aligned," not "use a project tool").
  • Pains: where it hurts today - the delays, errors, workarounds.
  • Gaps: the distance between what they want and what today's options give. That gap is the opportunity.

Keep the person's exact words. The phrase a frustrated user reaches for is often the sharpest description of the problem you'll ever get. The deeper craft of running the conversation - sampling, phrasing, avoiding bias, analysing transcripts - goes further in Qualitative Research Methods.

Where AI Helps

Prompt: "I'm running discovery interviews about [problem]. Draft 8 open, past-focused questions in the style of The Mom Test, then list 3 leading questions to avoid and why."

AI drafts the guide and sorts the notes; you do the listening.It can prepare questions and cluster transcripts into jobs and pains, but it can't hear the pause or the workaround mentioned in passing. Those are yours to catch - and usually where the opportunity hides.

Found this useful? Pass it on.
Share