Validation guides
Customer Discovery for Technical Founders: Evidence First
Technical founders can build almost anything, which makes it easy to build the wrong thing. Customer discovery is how you find out what to build before you start. Here is a process that fits around an engineering schedule.
Customer discovery is the structured process of talking to potential customers to test your assumptions about their problem, their current solution and what they would pay, before you build. For technical founders it replaces feature guesses with evidence. Programs such as NSF I-Corps expect teams to complete at least 100 of these conversations.
The idea comes from Steve Blank's customer development method, and its first rule: "There are no facts inside your building, so get outside" (Steve Blank).
Key takeaways
- Customer discovery tests assumptions, not features. Write the assumptions down before the first call.
- Talk about their past, not your idea. Specific recent experiences beat opinions about the future.
- Volume matters. NSF I-Corps teams are expected to complete at least 100 interviews.
- Log every conversation the same way, so patterns are visible across calls.
- End with a commitment ask, such as a follow-up, an introduction or a pilot.
What is customer discovery?
It is the first step of customer development: finding out whether the problem you believe exists matters to the people you believe have it, and what they do about it today.
It is not selling, and it is not a feature survey. You are testing a short list of written assumptions, for example:
- Operations managers at mid-sized logistics firms spend more than two hours a week reconciling carrier invoices.
- They use spreadsheets and their accounting system, and nothing else.
- The finance director would pay to remove the task.
Each conversation confirms, contradicts or complicates one of them. When an assumption is contradicted repeatedly, you change it before writing code.
How many customer discovery interviews do you need?
More than most founders expect. NSF's I-Corps program expects teams to complete at least 100 interviews, and Stanford's Lean LaunchPad teams spoke to more than 100 people each, on average, in 2026.
The NSF solicitation for I-Corps Teams states that "teams are expected to have performed at least one hundred (100) interviews with potential customers and potential partners from their proposed target market(s)" (NSF 25-549).
In Steve Blank's Lean LaunchPad class at Stanford in spring 2026, "the eight teams spoke to 978 potential customers, beneficiaries and regulators", and most students spent 15 to 20 hours a week on the class (Steve Blank).
You do not need 100 conversations before you learn anything. Patterns start to show much sooner. But the numbers are a useful corrective to the founder who talked to five friends and started building.
Who should you talk to in customer discovery?
People in the specific role you believe has the problem, at the specific kind of company you plan to sell to. Friends, family and other founders only count if they fit that description.
Make a target list before you start: the role, the company type and size, and where you will find them. Include the people around the buyer too. I-Corps asks teams to interview "potential customers and potential partners", and Stanford's teams included beneficiaries and regulators.
For a technical founder, the easiest mistake is to talk mostly to other technical people, because they are easier to reach and speak your language. If your buyer is an operations manager, most of your conversations should be with operations managers.
What should you ask in a customer discovery interview?
Ask about specific recent experiences: the last time the problem happened, what they did, what it cost and what they tried before. Avoid asking whether they would use your product.
Rob Fitzpatrick's The Mom Test, as summarised by Sachin Rekhi, gives three rules: talk about their life instead of your idea, ask about specifics in the past instead of opinions about the future, and validate by asking for commitments.
A short set of questions that follows those rules:
- Tell me about the last time this happened.
- What did you do about it? What did that cost in time or money?
- What have you tried to fix it? Why did that not work?
- Who else is involved when this goes wrong?
- Can I follow up with you, or with the person who owns the budget?
Our full list of customer interview questions covers more situations, including what to ask the budget owner.
How do you record and analyse customer discovery interviews?
Use the same short template for every conversation, and review them in batches. Patterns across ten logged calls are far more reliable than your memory of the most enthusiastic one.
| Field | What to record |
|---|---|
| Who | Role, company type, size, how you found them |
| Assumption tested | Which of your written assumptions this call was for |
| Last occurrence | The most recent time the problem happened, in their words |
| Current solution and cost | What they do now, and what it costs in time or money |
| Strength of pain | Did they raise it unprompted? Have they tried to fix it? |
| Commitment | What they agreed to next: nothing, a follow-up, an introduction, a pilot |
| Verdict | Confirms, contradicts or complicates the assumption |
After every batch of calls, count the verdicts for each assumption. That count, not the best quote, decides what you build.
Why is customer discovery harder for technical founders?
Because building feels like progress and talking does not. The fix is to schedule discovery like engineering work, with a weekly target and a written output.
Treat discovery as part of the build. Block time each week for outreach and calls, set a target number of conversations, and write up the results before planning the next sprint. When an assumption fails, it should change the backlog that week.
NELL can shorten the preparation. Quick Validate is free and gives a first read on an idea, including where it is weakest, which is a good place to aim your first interviews. It does not replace them.
Frequently asked questions
What is the goal of customer discovery?
To test whether the problem you believe exists matters to a specific group of customers, how they solve it today and whether they would pay for something better, before you build.
How many customer discovery interviews should I do?
Programs such as NSF I-Corps expect at least 100. You will see patterns much earlier, but keep going until new conversations stop changing your assumptions.
Is customer discovery the same as market research?
No. Market research describes a market from published data. Customer discovery tests your own assumptions through direct conversations with the people you plan to sell to.
Can I do customer discovery by survey?
Surveys can help once you know which questions matter, but they are weak for discovery. Conversations reveal problems you did not know to ask about, and surveys cannot follow up.
When should customer discovery stop?
It does not fully stop, but the first phase ends when your key assumptions have been confirmed by repeated evidence, including commitments, from the same type of buyer.
Start where you are
Know where the idea is weakest before you pick up the phone.
Sources
- Steve Blank, Nail the Customer Development Manifesto to the Wall
- NSF 25-549, National Innovation Corps Teams program solicitation
- Steve Blank, Lean Launch Pad 2026 @ Stanford: Lessons Learned Presentations
- Sachin Rekhi, A Primer on Talking to Customers From The Mom Test
The example assumptions are illustrations. Interview targets from NSF and Stanford describe those programs, not a universal requirement.