Customer discovery is the practice of interviewing real people about a problem space before you commit to building a solution. Done well, it takes 3-4 weeks and 15-20 conversations. Done poorly — or skipped entirely — it is the most expensive mistake in product development. According to CB Insights analysis of startup failures, poor product-market fit (customers not actually needing what was built) is the single most common cause of failure, accounting for 43% of cases.
The goal of customer discovery is not to validate your idea. It is to understand the problem deeply enough that you can build something people will actually use. These are different objectives, and confusing them produces discovery that confirms what you already believed rather than challenging it.
This guide covers how to find people to interview, how to design and run discovery conversations, how many you need, how to analyse what you hear, and how to turn findings into decisions your team will act on.
What is customer discovery and how is it different from user research?
Customer discovery is specifically about understanding the problem space before you have built a product (or before you make a major product bet). The term comes from Steve Blank's customer development methodology and Eric Ries's lean startup framework.
User research is broader and includes understanding how people interact with a product that already exists — usability testing, task analysis, interface feedback. Discovery research happens before and without a product to test.
The practical distinction: if you are showing people something and asking what they think of it, that is user research or concept testing. If you are asking people how they currently handle a problem, what gets in the way, and what they have tried that didn't work — that is discovery.
Discovery research is also different from surveys. Surveys measure the distribution of attitudes across a population. Discovery interviews reveal the texture of a specific person's experience — the workarounds, the frustrations, the context, the competing priorities. Neither substitutes for the other. But for early-stage product development, interviews produce richer, more actionable insight than surveys.
5 rules for good discovery interviews
These are hard-won. Violating any of them produces research that feels useful but misleads.
1. Talk to real potential users, not friends. Your friends are supportive. They want your idea to succeed, so they will tell you things that support it. Your network is also demographically skewed. Find people who match your target profile but have no stake in your success.
2. Stay in problem space. The most common mistake in discovery interviews is pitching your solution. The moment you describe your product, the interview becomes about your product rather than the participant's experience. Ask about their world: how they currently do things, what fails, what they have tried. Do not describe what you are building until the end, if at all.
3. Listen more than you talk. A well-run discovery interview should be 70-80% the participant talking. If you are filling silence or completing their sentences, you are not listening — you are leading.
4. Ask about past behaviour, not hypothetical future behaviour. "Would you use a tool that did X?" produces unreliable answers — people overestimate their likelihood of adopting new things. "Tell me about the last time you had to do X — what happened?" produces real information about real behaviour.
5. Be comfortable with silence. After a participant finishes speaking, pause before your next question. People often add the most candid observation after a few seconds of silence, when they think the "official" answer has been given.
How to find participants for discovery interviews
This is usually the hardest part, particularly before you have a product or customer base.
Warm outreach from your own network: The most effective starting point. Message 30-40 people on LinkedIn who match your target profile. Frame it honestly: "I'm researching how [professionals in X role] handle [specific challenge]. Would you spend 30 minutes telling me about your experience? No product pitch — I'm genuinely trying to understand the problem." Expect a 15-25% response rate.
Relevant online communities: Slack workspaces, LinkedIn groups, Reddit communities, Discord servers, professional association forums. Most communities have rules against direct recruiting — post a genuine question about the problem you are researching and see who engages, then reach out privately.
Customer intercepts: If you have a website, app, or any existing audience, a short pop-up or exit survey asking for interview volunteers can produce participants quickly. Screener question examples: "How do you currently handle X?" or "Which of the following best describes your role?"
Partner with complementary services: If your target users work with a particular tool, agency, or platform, partnerships for recruiting are often mutually valuable.
Incentives: For hard-to-reach audiences, 50 to 100 EUR/USD gift cards are reasonable for a 30-45 minute interview. For early-stage discovery with curious participants, no incentive is needed if the topic is genuinely relevant to them.
How to design your discovery interview guide
A discovery guide is not a script. It is a set of topic areas and question prompts that help you navigate the conversation consistently without constraining it.
Suggested structure for a 40-minute discovery interview:
Opening (5 minutes): Set context. "I'm going to ask you questions about how you currently [do X]. I'm not going to show you anything or pitch anything — I just want to understand your experience. There are no wrong answers. The more specific you can be about things that actually happened, the more useful this is."
Their context (10 minutes): "Can you tell me a bit about your role and how [the problem area] typically comes up in your work?" This surfaces the context your product will need to fit.
The problem in practice (15 minutes): "Tell me about the last time you had to [do the thing your product might help with]. Walk me through what happened." Follow the story: what prompted it, what they did, where it got difficult, what they used, what they wished was different.
Workarounds and alternatives (5 minutes): "What have you tried to make this easier? What didn't work about it?" Workarounds are the most revealing signal in discovery — they show where the problem is real enough to spend effort on.
Close (5 minutes): "Is there anything about this area that I haven't asked about that you think is important? What would make this significantly better?" Then, if relevant: "Would you be open to another conversation as I develop some ideas?"
How many discovery interviews do you need?
More than most teams do; fewer than most people think you need to do rigorous research.
5-8 interviews will typically surface the 2-3 most significant problems if you are talking to a relatively homogenous group. Enough to decide whether a problem exists and is worth pursuing.
15-20 interviews across a range of participant types gives you confidence in patterns before a significant product investment. At this scale, you can start to see which problems are universal vs segment-specific.
If you are seeing the same 3-4 problems described in similar terms by people with different backgrounds, you have found something real. If every interview surfaces a different primary problem, you may be talking to too diverse a group, or the problem space may be fragmented.
See how many interviews you need for qualitative research for a fuller treatment of sample size logic.
How to analyse discovery interviews
The analysis task is to find the patterns across individual accounts without losing the texture of individual stories.
After each interview, write a brief memo: 5-10 minutes of reflection immediately afterwards. Key points: what problem did this person primarily describe? What was the most surprising thing they said? What workaround did they use? What language did they use to describe the frustration? These per-interview memos are the raw material for synthesis.
After 10+ interviews, look for patterns across memos:
- Which problems appear in most conversations?
- Which are described with the most emotional intensity?
- What language do participants use — their exact words for the problem?
- Who has the problem most acutely?
- What have they tried, and why did it fail?
Code for jobs and pains. For each interview, identify: the main job the participant is trying to do (the progress they want to make); the primary pain in doing it (what gets in the way); and the emotional stakes (why it matters). A table with one row per participant and these three columns will quickly show which combinations are most common.
For groups of 15+ interviews, tools like Skimle can accelerate this synthesis considerably — loading all interview transcripts, identifying recurring patterns across the corpus, and letting you compare which problems appear most frequently across different participant types using metadata by role, company size, or sector. See how to synthesise user research for the practical workflow.
From discovery to decisions
Discovery research only adds value if it changes what you build or how you position it. The most useful synthesis outputs:
A problem statement: A precise, evidence-based description of the problem you are solving, in the customer's language. Not your product description — the underlying problem. "People who need to [X] currently [describe current approach], which fails because [specific failure mode], which costs them [stakes]."
A target profile: Not a persona with a stock photo, but a description of who has the problem most acutely, most frequently, and in contexts where they would most want a better solution.
3-5 hardest questions: The things you learned that you don't yet know how to solve. "Participants said they need X, but they also said Y, which conflicts with how we planned to do X." Discovery surfaces the tensions that product design needs to resolve.
For managing ongoing discovery as a continuous practice rather than a one-time sprint, see always-on customer research and how Skimle Ask enables ongoing AI-led discovery conversations without scheduling overhead.
Frequently asked questions
How is customer discovery different from market research?
Market research typically asks about a population — market size, segment definition, competitive landscape, purchase intent across a sample. Customer discovery is focused on individual experience — understanding the texture of a specific problem for specific people. Market research tells you how many people have a problem; discovery tells you what the problem actually feels like to live with.
Can I do discovery interviews remotely?
Yes, and most teams do. Video calls work well — you can see facial expressions and attention. Audio-only is fine for structured conversations. The main thing remote discovery loses is the ability to observe someone doing the thing you are asking about. Where "show me how you currently do X" is valuable, consider asking participants to screenshare their current workflow rather than just describing it.
What if participants say they would use my product but nobody ends up buying?
"I would definitely use this" is one of the least reliable things a discovery participant can say. People are polite. They want to be helpful. They imagine a future self who would use a product even when their actual behaviour wouldn't support it. Weight revealed behaviour (what they currently do, what they have already tried and paid for) far above stated intent.
How do I avoid confirmation bias in discovery interviews?
Confirmation bias in discovery shows up as selectively remembering the evidence that supports your idea and downweighting the evidence that challenges it. Structural defences: write a memo after each interview regardless of direction (positive and challenging sessions both); have someone else review your synthesis for pattern; specifically seek participants who you expect to be less likely to have the problem you think you are solving.
When should I stop doing discovery and start building?
When you can describe the problem specifically and precisely, when you have found 10-15 real people who have it and can explain what they have tried and why it failed, and when you are learning things you would not have anticipated. You are ready to start building when new interviews are confirming what you already know rather than adding new information. Discovery does not end at launch — it becomes ongoing as your user base grows.
Ready to analyse your discovery interview transcripts and find the patterns that should shape your product? Try Skimle for free — load your discovery interviews, identify recurring problems and language, and build a synthesis your whole team can access.
Related reading:
- Jobs-to-be-done interviews: how to run them and analyse what you find
- How to synthesise user research
- Always-on customer research: from discovery to churn
About the authors
Henri Schildt is a Professor of Strategy at Aalto University School of Business and co-founder of Skimle. He has published over a dozen peer-reviewed articles using qualitative methods, including work in Academy of Management Journal, Organisation Science, and Strategic Management Journal. His research focuses on organisational strategy, innovation, and qualitative methodology. Google Scholar profile
Olli Salo is a former Partner at McKinsey & Company where he spent 18 years helping clients understand the markets and themselves, develop winning strategies and improve their operating models. He has done over 1000 client interviews and published over 10 articles on McKinsey.com and beyond. LinkedIn profile