Customer discovery for startups is a disciplined way to learn whether a defined group has a problem worth solving, how they handle it today and what evidence would support a product experiment. It is not a search for compliments or a promise of product-market fit. Its purpose is to make the next decision less speculative.
Begin with a problem and a target audience
Describe the idea as hypotheses: who experiences a problem, in what situation, what they do now, why that is inadequate, and what change might help. Avoid treating a feature as the problem. “Operations leads reconcile information from several systems before a weekly review” gives you a task and context to investigate; “teams need a smart dashboard” already assumes a solution.
Choose an initial audience based on meaningful differences in the problem, workflow or buying process. Write down who is in scope, who is not and how you will find participants. If users, buyers and approvers differ, explore each role rather than assuming one interview represents the whole decision.
Design useful discovery interviews
Prepare a short guide with open prompts. Start with context and recent behaviour, then explore consequences, alternatives and the decision process. Ask: “Walk me through the last time you handled this”; “What happened next?”; “What was difficult?”; “What did you try?”; and “Who else was involved?” Questions should invite a story, not a yes or no.
Avoid leading questions that reveal the answer you hope for, such as “Wouldn’t this save time?” or “How much would you pay for this great feature?” Avoid stacking multiple questions. Let participants use their own language. If you show a concept, do it after learning about the problem and label clearly what is hypothetical.
Recruit beyond the founder’s immediate network when possible. Record how participants were reached because a convenience sample can overrepresent enthusiastic or similar people. Ask permission before recording, explain how notes will be used, and avoid collecting sensitive details you do not need.
Collect behavioural evidence
Recollections are useful but imperfect. Ask about the most recent occurrence, steps taken, time or money spent, workarounds, frequency over a defined period, and consequences when the task fails. Where appropriate, observe the process or review an artifact while respecting privacy and confidentiality.
Separate evidence from interpretation. “This is frustrating” signals an experience; repeated workarounds, budget allocation, switching effort or escalation can reveal how the issue affects operations. None alone proves demand. Look for patterns across participants and record exceptions rather than hiding them.
Maintain a simple evidence table: hypothesis, observation, source, interpretation, confidence and next question. Distinguish direct quotes from summaries. This helps prevent one vivid story from becoming a universal claim.
Test willingness to pay and adoption conditions
Willingness to pay is more than a hypothetical number. Explore how the problem is funded today, who controls the budget, what other priorities compete for it, how purchases are approved and what evidence a buyer needs. A transparent price presentation, pilot proposal or paid commitment can test an offer more directly than asking whether a price sounds reasonable.
Test adoption conditions too: switching cost, data access, integration, training, procurement, security review and risk of disrupting existing work. Someone may value an outcome but be unable to buy or implement it. In a business setting, understand the buying group and who owns the workflow after purchase.
Discovery interviews generate hypotheses and explain needs; they do not establish market size or guarantee sales. When prevalence or commercial potential matters, pair interviews with appropriate quantitative or behavioural tests.
Decide what belongs in an MVP
An MVP is a focused way to test a consequential assumption with the least unnecessary build. It is not automatically a smaller version of every planned feature. Define what you need to learn, the smallest credible experience that can produce evidence, and what must be true for the test to be fair.
The next step may not require software. A manual service, clickable prototype, concierge workflow, sample report, landing page or limited pilot can test core value earlier. Be explicit about what is real, what is simulated, and what information will be collected. Protect trust and service quality while experimenting.
Set learning measures before the test: task completion, quality, repeat use, payment, referral, time saved or another relevant behaviour. Add guardrails for error and negative effects. Decide how support will work and what happens when the test ends.
Proceed, change direction or stop
Review findings against the original hypotheses. Proceed when the problem is clear, the audience is reachable, a credible value proposition is emerging and the remaining risk can be tested. Change direction when another segment, trigger or workflow appears more important. Stop when the problem is infrequent, current alternatives work well, adoption barriers dominate or a responsible test is not possible.
These are not permanent verdicts. Document what changed, what remains unknown and the next decision date. If signals conflict, run a narrower test rather than smoothing disagreement into a positive average.
- 01 · Choose a segmentDefine who has the problem and when.
- 02 · Explore behaviourDiscuss recent examples and workarounds.
- 03 · Form hypothesesMake assumptions explicit and testable.
- 04 · Test an MVPObserve task outcomes and trade-offs.
- 05 · Review evidenceCompare findings with thresholds set in advance.
Yes, with a clear need
Proceed to the next bounded test or delivery stage.
Mixed or incomplete evidence
Iterate on the segment, workflow or solution and test again.
No, or unacceptable risk
Stop or change direction when the need is weak or risks cannot be addressed.
Customer discovery checklist
- Problem hypotheses are separate from product ideas.
- Participants match the target user, buyer or approver to be understood.
- Questions focus on recent behaviour, context and current alternatives.
- Interviewers avoid leading prompts and label hypothetical concepts.
- Evidence includes workarounds, consequences and constraints.
- Quotes, observations and interpretations are clearly distinguished.
- The next experiment has a learning goal, measure and decision rule.
- The team is willing to proceed, change direction or stop.
Frequently asked questions
How many customer interviews are enough?
There is no fixed number that guarantees validation or product-market fit. The useful amount depends on audience variation, the question and whether new evidence is changing the decision. Set a stopping rule based on learning and remaining uncertainty.
Should we pitch the idea during discovery?
Explore customer experience before showing a solution. Later, a concept can test comprehension and reactions, but label it as hypothetical and ask what is unclear, risky or less useful—not only whether someone likes it.
What if people say they would use the product?
Treat stated interest as one signal. Look for current behaviour, effort, budget, access, commitment and willingness to take a real next step, then test the offer in a realistic context.