Customer discovery means structured conversations with potential customers, users, and partners to test assumptions about the problem, the buyer, and the business model before you spend years and grant money building a product. The National Science Foundation’s I-Corps program trains research teams to do this; its national Teams program requires at least 100 potential customer interviews, according to NSF solicitation NSF 25-549. A common pattern among technology founders who skip discovery is a product that works in the lab but has no clear buyer.
Why interviews come before the product
Technology push starts with an invention and searches for an application. Market pull starts with a costly problem and asks whether the invention could solve it. Interviews connect these perspectives: technical performance matters when it addresses a need someone has reason and authority to act on.
Evidence can shape the field of use—the application covered by a license—that you pursue when licensing a university invention. It also grounds the commercialization section, explaining the path to market, in an SBIR funding proposal. Investors will ask who buys, why they buy, and what evidence supports your answers.
From hypothesis to interview to pivot
Write hypotheses
A hypothesis is an assumption you can test against evidence. Record your customer segment, or target group; problem; value proposition, meaning the benefit offered; channel, meaning how customers find and obtain the product; pricing; and key partners. Use a one-page business model to keep these assumptions visible and revisable.
Design the interview
Choose the assumption you need to test and the role best placed to discuss it. Prepare open-ended prompts about recent events, existing workflows, and actual purchases. Avoid explaining your solution first: that can turn an interview into polite feedback on your presentation.
Run the interviews
Explain that you are researching how people handle a problem, then ask permission to take notes. Follow specific examples with prompts about consequences, workarounds, and decisions. Listen for unexpected needs. Talk about the problem, not unpublished technical details: an interview can count as a disclosure, so agree on boundaries with your tech transfer office or patent practitioner first.
Synthesize and decide
Compare evidence across roles and record contradictions alongside repeated patterns. Persevere when evidence supports the direction, pivot—change a major business assumption—when it points elsewhere, or stop when the opportunity lacks support. Separate observations from interpretations so an enthusiastic comment does not become an assumed purchase commitment.
How to get to 100 conversations
Find contacts through professional societies, publicly available conference attendee lists, alumni networks, former colleagues, and trade shows. Ask people already interviewed for warm introductions, meaning introductions through a shared contact. Explain the process you are studying rather than requesting a sales meeting.
Seek end users who operate the product, economic buyers who authorize spending or sign purchase orders, and influencers who shape preferences. Include technical gatekeepers who assess compatibility or security, regulators who explain oversight expectations, and distributors who could bring the product to customers. Their incentives may differ.
Use short video calls or in-person meetings so you can follow unexpected answers; surveys offer less room for that exploration. Ask every interviewee for two more names, ideally people with different roles or experiences. Respect refusals and requests for confidentiality.
| Tracking field | What to capture |
|---|---|
| Who and role | Name, organization, and relationship to the problem |
| Date | When the conversation occurred |
| Key quotes | Exact wording, distinguished from your interpretation |
| Surprises | Evidence that challenged an assumption |
| Next contact | Suggested introduction or missing perspective |
Questions that work and questions to avoid
Ask about behavior before opinions. A concrete account of the last purchase or failed workflow gives you something to investigate; praise for an imagined product does not.
| Goal | Ask this | Avoid this |
|---|---|---|
| Understand the problem | Tell me about the last time this happened. | Would this be useful? |
| Identify current solutions | How do you handle it today? | Do you like this idea? |
| Explore the cost | What did that cost in time or money? | How much would you pay? |
| Understand purchasing | Who else approved the last purchase? | Would you buy it? |
| Explore switching | What would have to be true for you to switch? | Wouldn’t this be better? |
| Seek evidence | Can you show me your current workflow? | Imagine using this someday. |
What NSF I-Corps teams look like
NSF’s I-Corps pages and solicitation NSF 25-549 describe the national Teams program as follows. Discovery tests commercial assumptions; participation does not establish that a technology has a viable market.
| Element | National Teams program |
|---|---|
| Team | Three to five members, including an Entrepreneurial Lead, Technical Lead, and Industry Mentor |
| Training | Seven weeks, with at least 100 potential customer interviews |
| Award | Up to $50,000; NSF 25-549 specifies a 12-month award period |
| Participation fee | $10,000 paid from award funds |
| Format | Online curriculum with a kickoff, weekly sessions, and closing presentation |
| NSF award route | Relevant NSF research award active within the past five years |
| Regional route | Complete a regional program hosted by an NSF I-Corps Hub and obtain a recommendation |
The Entrepreneurial Lead focuses on commercial exploration, the Technical Lead contributes research expertise, and the Industry Mentor adds industry perspective. Regional I-Corps programs through university-based hubs are a common first step for researchers without a recent NSF award. Verify current eligibility, amounts, fees, and format with the official NSF I-Corps source.
Common mistakes
- Pitching instead of listening to how people describe their work.
- Interviewing only friendly contacts who share your assumptions.
- Confusing users with buyers who control spending.
- Asking leading or hypothetical questions that invite agreement.
- Stopping after a handful of interviews and failing to record surprises.
- Ignoring regulators, payers, or reimbursement—the process of payment for care—in regulated markets.
Update the model, revisit the target market, and identify the next unresolved assumption. Feed supported findings into your technology startup pitch, distinguishing observed behavior from expectations.
Frequently Asked Questions
Can I interview customers before I have a prototype?
Yes. Start by understanding their current work and the consequences of the problem. A prototype becomes useful when you have a specific assumption about use to test.
Do customer interviews count as sales?
An interview is research, not proof of demand. Treat interest as a reason to investigate purchasing requirements rather than as revenue you can expect.
Can I participate in I-Corps without a recent NSF award?
The eligibility route described in NSF 25-549 includes completing a regional I-Corps program hosted by an NSF I-Corps Hub and obtaining a recommendation. Check NSF’s current requirements before planning participation.
What if people disagree about the problem?
Compare their roles, working conditions, and purchasing authority. Disagreement may reveal distinct customer groups or show that your proposed market is too broad.