Most founders build before they talk to anyone. You refine the product, polish the pitch deck, and assume customers will show up once the technology is ready. Then the market doesn't care. The problem you solved isn't the one customers pay to fix. Or the switching cost is higher than the value you deliver.
Customer discovery stops that waste before it happens. Leave the building, run structured interviews, and test your assumptions against evidence before you commit resources to development. The method is grounded in Lean Startup and NSF I-Corps principles, and it only works if you treat discovery as research, not validation.
I coach founders through customer discovery and non-dilutive funding and run I-Corps programs. What follows is the field guide I give them before they make their first 100 calls, built from watching which startups made it into accelerators because they validated the problem before they built anything. If you are earlier than that, without a paying customer yet, the discipline is the same. I cover the adjustments in Customer Discovery Without a Paying Customer.
I've said this before and I'll keep saying it: most founders struggle right out of the gate because they can't frame what problem they're actually solving. I have never read that as a personal failing. It is the default state of anyone standing too close to their own idea, and it is why the questions below matter more than whatever answer you already have in your head.
What a real interview sounds like
I tell founders a discovery interview is not a pitch disguised as a question. When I worked with a student team on a Marine Corps medical training problem, the useful material came from watching the work, not from asking about it. Ask about the customer's current workflow, the problem they face today, how they solve it now, what they have tried, why those solutions failed, how much the problem costs them in time or money, and what would make switching worth the risk.
Ask open-ended questions and listen. Don't explain the product. Don't defend the idea when the customer pushes back. Probe for specifics when an answer is vague, and ask follow-up questions to understand behavior, not just opinion.
Good discovery questions sound like this: Walk me through how you handle this problem today. What have you tried in the past, and why did you stop using it? What would have to be true for you to switch from your current approach? How much time or money does this cost you per week? Who else is involved in this decision?
Bad discovery questions pitch the solution. Would you use a product that does X? Do you think this feature would be valuable? How much would you pay for this? Those questions don't produce evidence. They produce polite agreement that vanishes the moment you ask for a purchase order.
Unless and until you really get to know your customers, you’re really just guessing. Sometimes you actually have to see them in their natural environment.
The interviews I get real signal from surface the job the customer is trying to get done, the current alternative they use, the limitations of that alternative, the switching costs and risks of adopting something new, who influences or approves the decision, and what evidence would convince them to change.
Ask about the last time the customer actually faced this problem. Specific, recent examples reveal real behavior. Hypothetical questions about future needs get you aspirational answers that have nothing to do with what customers actually do.
Questions about money and time spent tell you urgency. If the customer can't quantify the cost, the problem probably isn't urgent enough to warrant a solution. Questions about past attempts tell you what the market has already tried and rejected, so you don't rebuild something a customer already knows won't work.
Questions about decision-making and approval reveal organizational complexity. In B2B and government contexts, the person feeling the problem often doesn't control the budget, procurement, or adoption decision. You need the full stakeholder map to build a go-to-market path that actually reaches the people who decide.
Logging responses and reading the pattern across segments
One interview has never proved anything for me. Patterns emerge across many conversations, so log what you hear, code responses for patterns, and track which assumptions get validated or invalidated.
After each interview, document the customer segment, the specific problem described, the current solution in use, pain points with that solution, whether the customer would pay to fix it, who else is involved in the decision, and any quotes that capture the customer's own language.
Coding responses for patterns
Across 20 to 30 interviews, start coding responses. Which customer segments share similar problems, and which describe something entirely different? Which pain points keep repeating? Which current alternatives come up over and over, and which switching costs or risks do customers cite most? The number of interviews itself is worth its own answer, which I get into in How Many Customer Interviews Should You Do?
That analysis tells you whether you're talking to one coherent customer segment or several segments with different needs. It shows whether the problem is urgent for most customers or only for a handful of edge cases. And it clarifies your real competition, which is usually not another startup but the customer's current workaround, or the decision to do nothing at all.
By 50 to 100 interviews I expect to see clear patterns. If every customer describes the same core problem in similar language, the problem is validated. If customers describe wildly different problems, you're talking to multiple segments and need to pick one.
If customers keep naming the same current alternative, that's your real competition, and your value proposition needs to explain why switching is worth the friction. If customers can't say how much the problem costs them, or call it a nice-to-have, it lacks urgency and will be hard to monetize.
Validated customer discovery gives you a clear customer segment definition, a problem statement in the customer's own words, a grip on the current alternative and its limits, evidence of willingness to pay at a specific price, clarity on who decides and how, and marketing language that resonates because it came straight from your customers.
When 100 conversations tell you to pivot
Every discovery effort I have run ended in one of three places. You validate the problem and customer segment. You invalidate your original hypothesis and pivot to a different problem or customer. Or you learn the problem is real, but customers won't pay enough to support a venture-scale business.
Pivot when interviews show the problem isn't urgent for most customers, the current alternative is good enough that switching costs are too high, customers describe a different problem that matters more to them, the willingness to pay is lower than what it costs you to deliver, or the decision-making process is so complex that sales cycles would sink you.
The strongest founders treat invalidation as a win. Learning a hypothesis is wrong after 40 interviews costs you a few weeks. Learning it after 18 months of development and a failed launch costs you the company. An evidence-based pivot isn't failure. It's the scientific method applied to entrepreneurship. I walk through how to tell a real pivot signal from ordinary founder discomfort in How Do You Know When to Pivot?
Common mistakes that waste interviews
I watch founders waste interviews by pitching the product instead of exploring the problem, asking leading questions that bias the answer, talking more than you listen, interviewing friends and family who won't give you honest feedback, and stopping after 10 or 15 interviews because you already heard what you wanted to hear.
You also lose ground when you interview people who aren't real potential customers, ask hypothetical questions about the future instead of probing past behavior, tune out negative feedback and focus only on the encouraging answers, and skip documenting interviews rigorously enough to spot patterns later.
The fix is discipline: commit to 100 conversations, not 10. Interview strangers, not friends. Listen more than you talk. Document everything. Treat discovery as research, and accept that invalidation is a valuable outcome, not a setback.
How discovery connects to business model decisions
I do not treat customer discovery as an academic exercise. The evidence you gather informs every business model decision you'll make. Who is your early adopter segment? What job are they hiring your product to do? What channels reach them? What relationships do they expect? What does the revenue model look like based on validated willingness to pay? What partnerships do you need to deliver the value you're promising?
You'll often find the business model you imagined doesn't match what customers will actually support. Discovery might show customers want a service, not a product. That they'll pay per transaction, not by subscription. That they expect you to integrate with existing systems. That procurement requires partnerships you don't have yet.
That evidence lets you design a business model grounded in market reality instead of assumptions. It connects your value proposition to the segment that will actually pay for it, and it surfaces go-to-market problems early, while they're still cheap to fix.
Frequently asked questions
How many customer conversations do I actually need to run?
I tell founders to aim for 100 as a working target, not a magic number. Patterns usually start to repeat by 20 to 30 conversations, and by 50 to 100 you should see the same problem, the same current alternative, and the same objections showing up again and again. If you are still hearing something new in every call past 100, you are probably talking to more than one customer segment.
Who should I interview first?
Start with people who are living the problem right now, not people who might someday. I tell founders to avoid friends and family entirely, because they will give you encouragement instead of evidence, and to prioritize strangers who match the customer segment you think you are building for, even if reaching them takes more work than a warm introduction.
Should I record the interviews or just take notes?
Record when the customer agrees to it, and take notes regardless. I have gone back to a recording weeks later and caught a detail I missed the first time, especially phrasing the customer used to describe the problem, which is often the exact language you want in your marketing later. Notes taken live are still worth doing, because they capture what struck you as important in the moment, before you have time to rationalize it.
What if the customer says they would definitely buy this?
I treat verbal enthusiasm as close to worthless on its own. A customer who tells you they would definitely buy something is being polite, not making a purchase decision. Ask what they would have to see to actually pull money out of a budget, or better, ask for a specific next step, a pilot, a letter of intent, an introduction to whoever controls the budget, and see whether the enthusiasm survives contact with an actual commitment.
How do I know when I've talked to enough people to stop and build?
Stop when new interviews confirm what you already know instead of teaching you something new. That is closer to the grounded theory idea of saturation than a fixed interview count. If your last 10 conversations described the same problem, the same current alternative, and roughly the same willingness to pay as the 10 before them, you have enough to commit resources with confidence.
Is it too late to run customer discovery if I've already built the product?
It's never too late, though it's more expensive. I have worked with teams who built first and validated second, and the interviews still produced real course corrections, on pricing, on which feature actually mattered, on who the real buyer was versus who the user was. The evidence just costs you more by that point, because you are testing sunk work instead of an idea on paper.
Start with a testable customer segment and hypothesis. Write 10 to 15 core interview questions focused on the problem, not the solution. Schedule conversations with people outside your immediate network. Document everything. Code for patterns. And accept that the best outcome might be learning your original idea was wrong before you spend a year building it.