Pre Build Customer Discovery: 10 Questions That Save Months of Work

What you need to know

• The goal of customer discovery is not to confirm the product idea. It is to understand the problem and the customer well enough to know what to build and for whom.
• Questions about past behavior and current workflow produce more reliable data than questions about future intent. "What do you currently use for this?" is more revealing than "Would you use a product that did this?"
• The language customers use to describe their problems is the right language for the product's marketing. Discovery interviews are also copywriting research.
• Discovery fails when founders show the product concept too early. The customer's feedback anchors to the solution rather than to the problem. Keep solutions out of discovery interviews.
• 15 to 30 interviews with the right profile are sufficient. Quality of profile match matters more than interview volume.

The core argument

Customer discovery is the cheapest form of product validation available. A 20-minute conversation with a potential customer costs nothing but the time of the people involved. The information produced by 20 conversations, synthesized carefully, can redirect months of development work toward a problem customers actually have in the severity and form that makes them willing to pay for a solution. Skipping discovery and building first is not faster; it is faster to the wrong answer.

The 10 questions below are structured to produce actionable information about the problem, the customer's current behavior, and the constraints that a solution must fit. They are not leading questions: they ask the customer to describe their experience rather than to react to a product concept. The answers to these questions, collected across 15 to 25 interviews, reveal whether the assumed problem is real, who has it most severely, what they currently do about it, and what a better solution would need to do to make them switch.

The synthesis work after the interviews is as important as the interviews themselves. Recording the interviews (with permission), tagging answers by theme, and mapping which answers appear consistently across interviews turns 20 conversations into a product requirements document that reflects real customer experience rather than founder assumptions. This synthesis is where the insights that change product direction come from.

Common mistakes

1. Interviewing friends and family who will say positive things. Customer discovery interviews must be with people who fit the target customer profile, not with people who are supportive of the founder. Supportive non-customers produce false validation. Actual potential customers who express skepticism about current solutions are the most valuable interview subjects.

1. Asking hypothetical questions about the product. "Would you use this?" and "Would you pay $50 per month for this?" produce social-desirability bias responses. "What do you currently pay for related tools?" and "Tell me about the last time you had to deal with this problem" produce behavioral evidence.

1. Showing a prototype or mockup before the customer has described the problem. Anchoring the interview to the solution prevents the customer from describing the problem in their own terms. Describe the problem space you are researching; do not show a product until the customer has articulated their experience independently.

1. Over-interpreting one strong signal. One customer who expresses intense frustration with the problem and high enthusiasm for a solution is not representative of the market. Pattern across 15 to 25 interviews; do not pivot the product direction based on a single interview, however compelling.

1. Not taking notes or recording (with permission). Interview recall is unreliable. Notes taken during the interview produce the quotes, the exact language, and the specific workflow details that synthesis depends on. Recording with explicit permission allows more focused listening during the interview.

Where to start

The 10 questions:

1. "Tell me about your role and what you spend most of your time on." (context)
2. "Walk me through how you currently handle [the problem area you are investigating]." (current workflow)
3. "What does that process look like in practice, step by step?" (detail)
4. "What is the most frustrating part of how you do this today?" (pain intensity)
5. "Tell me about the last time this was particularly painful. What happened?" (incident recall)
6. "What have you tried to solve this? What tools do you use?" (current alternatives)
7. "Why hasn't that fully solved the problem?" (gap in current solutions)
8. "What would a perfect solution look like from your perspective?" (customer-defined success)
9. "What would make you switch from what you are using today?" (switching criteria)
10. "What does this problem cost you, in time or money?" (willingness to pay anchor)

These questions reveal the problem, the severity, the current behavior, and the criteria for a solution. They do not ask about the product concept; they produce the foundation for defining the product concept correctly.

Related reading

• MVP Failures I Have Witnessed: A Field Guide
• MVP Validation Frameworks: A Comparison of the Top Five
• How to Build an MVP in 2026: A Non-Technical Founder's Complete Roadmap
• MVP vs Prototype vs Proof of Concept: Stop Confusing Them