Customer Discovery in MVP

Customer discovery in MVP is the process of talking directly to potential users to understand their real problems before building anything. It replaces assumptions with evidence.

Most founders skip this step because building feels more productive than talking. That is the mistake that leads to products nobody wants.

Key Takeaways

• Before building, not after: customer discovery happens before the first line of code, not after launch when changing course is expensive.
• Conversations, not surveys: the best customer discovery involves direct conversations that can go in unexpected directions.
• Tests your riskiest assumptions: the goal is to find out whether the problem you think exists actually matters to real people.
• Shapes the entire MVP: what you learn in discovery determines what you build, who you build it for, and what you leave out.
• Never truly finished: discovery continues after launch in a lighter form as you learn from real user behavior and feedback.

What Is Customer Discovery in MVP Development?

Customer discovery is the process of interviewing, observing, and learning from potential users to validate whether the problem your MVP will solve is real, frequent, and painful enough to justify building a product around it.

The term was popularized by Steve Blank and is foundational to the lean startup methodology.

• Problem-first approach: discovery starts with the problem, not the solution, which prevents founders from falling in love with a product idea before confirming the problem exists.
• Structured conversations: discovery interviews follow a loose but purposeful script designed to surface real pain without biasing the user toward confirming your hypothesis.
• Identifies real users: discovery helps you understand who actually has the problem, which often differs from who you initially assumed would be the target user.
• Produces requirements without asking for them: users describing their current workarounds and frustrations reveal exactly what a good solution must do.

Customer discovery is not market research and it is not a survey. It is a direct, ongoing conversation with the people you are building for.

How Do You Run Customer Discovery Interviews?

Run customer discovery interviews by asking open-ended questions about the problem, how users currently solve it, what they have tried, and how much it costs them to live without a good solution. Do not pitch your product. Just listen.

The most common mistake in customer discovery is turning an interview into a pitch. The goal is to learn, not to sell.

• Start with context questions: ask about the user's role, daily workflow, and how the problem you are researching fits into their regular work.
• Explore the current experience: ask how they currently handle the problem, what tools they use, and what frustrates them about those tools.
• Quantify the pain: ask how often they face the problem, how much time it takes, and what it costs them when things go wrong.
• Ask about past behavior, not future intent: "have you tried to solve this before?" produces more reliable data than "would you use this product?"
• Avoid leading questions: asking "would you use an app that solved X?" tells you nothing. Ask instead what they have already tried and what was missing.

The Mom Test by Rob Fitzpatrick is one of the most practical guides available on how to run customer discovery interviews that produce honest, useful data.

What Questions Should You Ask in Customer Discovery?

The best customer discovery questions ask about real past experiences, not hypothetical future behavior. Questions about what users have already done, tried, and paid for reveal more than questions about what they would theoretically do.

Past behavior is a much stronger predictor of future behavior than stated intentions.

• Tell me about the last time you faced this problem: this surfaces a real, specific instance the user can describe accurately from memory.
• How do you currently handle it, step by step: this reveals the actual workflow and identifies where the pain and inefficiency are concentrated.
• What have you already tried that did not work: this shows what alternatives exist and why users found them insufficient.
• How much time does this cost you each week: quantifying the problem reveals whether the pain is significant enough to justify a product.
• Who else on your team deals with this: this identifies whether the problem is individual or organizational, which shapes the product scope.

Avoid questions that ask users to predict their own behavior or evaluate your idea. Their predictions are often wrong; their experiences are always real.

What Do You Look for in Customer Discovery Results?

In customer discovery results, look for consistent patterns across multiple conversations. When five or more users independently describe the same pain, the same workaround, or the same frustration, you have found something real worth building around.

One passionate user is anecdotal. Five users with the same problem is a signal. Ten is a clear direction.

• Repeated pain points: when multiple users spontaneously describe the same frustration, it is a real problem worth solving.
• Active workarounds: users who have already invented a workaround are spending real time and energy on the problem, which confirms its importance.
• Clear quantification: users who can tell you specifically how much time or money the problem costs are describing a problem with real urgency.
• Emotional language: frustration, annoyance, and resignation in how users describe a problem indicate a pain point worth addressing seriously.
• Absence of good alternatives: when users say they have tried everything and nothing works well, there is likely a genuine market gap.

Discovery interviews should continue until you stop hearing new problems and start hearing the same patterns in different words.

When Does Customer Discovery End?

Customer discovery never fully ends, but the intensive pre-build phase should conclude when you can predict what the next interview will say before it happens. That level of pattern clarity is the signal to move from discovery into building.

Knowing when to stop is as important as knowing when to start. Discovery that never converts into a build decision is not discovery, it is avoidance.

• Saturation signal: when interviews produce no new information and confirm patterns you have already identified, you have enough to proceed.
• Hypothesis clarity: when you can write a clear problem hypothesis and describe exactly who has it, discovery has done its job.
• After the MVP launches: discovery continues in a lighter form as you talk to real users about their experience with the product you built.
• After every major product decision: before adding a significant new feature, a short discovery phase with target users is worth running again.

At LOW/CODE Agency, we include customer discovery as a structured part of the discovery phase for every MVP engagement because the clarity it produces shapes every subsequent decision.

Conclusion

Customer discovery is the investment that protects every dollar spent on development. It finds the real problem, identifies the real user, and reveals what the real solution needs to do. Skip it and you are building on assumptions. Run it well and you are building on evidence.

Ready to Turn Discovery Into a Real Product?

Good discovery findings are only valuable if they lead to a well-built product.

At LOW/CODE Agency, we are a strategic product team that has delivered 450+ digital products for clients including Medtronic, American Express, Coca-Cola, Zapier, and Sotheby's. We run structured customer discovery as part of every engagement and use what we learn to build MVPs that solve real problems for real users.

• Structured discovery phase: every project starts with a discovery process that validates the problem before any development scope is agreed.
• Interview facilitation support: we help clients design and run customer discovery interviews that produce actionable, unbiased results.
• Discovery to roadmap translation: we turn discovery findings into product requirements and a prioritized feature roadmap before building begins.
• Problem-first design: our UX process is grounded in what we learned in discovery, not in what looks good in a mockup.
• Full product team: strategy, design, development, and QA working together from the first conversation to the last sprint.
• Honest scope feedback: if discovery reveals the problem is smaller than expected, we say so before you commit to a full build.

If you want to build an MVP grounded in real customer insight, visit lowcode.agency to get started.