Customer Discovery and Evidence-Seeking Interviews

An interview is not a sales pitch

The goal of a customer-discovery interview is to learn from reality before defending a solution. We want to understand a situation that occurred, the behavior a person took, the current alternative, and the cost or consequence of that behavior for them. Interviews may involve a potential customer, user, partner, or stakeholder because each role reveals a different part of the picture. Entrepreneurship programs such as NSF I-Corps use direct conversations with customers, partners, and stakeholders as part of customer discovery and evaluating commercial potential.

We do not turn a training-program practice into a universal rule. NSF I-Corps materials for accepted national teams specify a large discovery-interview requirement and state 100 interviews within that program. That number is not a scientific rule saying 99 interviews are insufficient or that 100 proves a market. The useful amount of interviewing depends on the decision at hand, segment diversity, question quality, recurring patterns, and other available evidence.

Ask about the last real situation, not an imagined future

A question such as “Would you use an app that organizes appointments?” invites a guess about the future and may encourage politeness. A stronger question is often: “Tell me about the last time an appointment changed at short notice. What did you do step by step?” Then: “Which tools did you use? Who was involved? Roughly how long did it take? What happened if details did not match?” We do not assume past behavior will always repeat, but it gives us more concrete material than general agreement with an appealing description.

Begin with context before the solution: When does the problem occur? What is the current alternative? What makes it important or unimportant? What has been tried before? Then leave room for silence and follow-up. If someone says, “I resend everything manually,” ask, “What do you mean by everything?” rather than offering an interpretation. That follow-up may reveal details that were not in your original hypothesis.

Record evidence before writing the conclusion

Write notes in layers. First: what situation, statement, or behavior did the person describe? Second: what is the current alternative? Third: what is the team’s interpretation? Fourth: what should be asked next? This separation prevents the founder’s interpretation from becoming “what the customer said.” You may add a confidence label or “needs verification,” but do not treat a confidence number as a scientific measurement unless it comes from a real calibrated method.

Interviews cannot answer everything. If we want to know whether people will actually use a new workflow, we may need a small experiment or prototype. If we want to know task duration, observation or usage data may be more useful. If we want to understand real willingness to commit, we may need a step that requires time, registration, or a genuine request, within clear ethical boundaries. There is no rule that “behavior is always stronger than opinion”; evidence strength depends on the claim being tested.

A good interview does not end by forcing the data to support the idea. It ends by updating the map of what is known and unknown. If interviews weaken an important hypothesis, that is useful learning that may prevent unnecessary building. If they strengthen it, they justify a more precise next test, not an early declaration of success.