It is easier to spend three evenings building a feature than twenty minutes asking a stranger whether the underlying problem matters. Code sits quietly while the founder works. People hesitate, misunderstand, and occasionally say the idea is not useful. That discomfort is exactly what makes the conversation valuable: it introduces reality before reality has an expensive product to reject.

Start with people who actually encounter the situation, not anyone willing to offer an opinion. Look through existing professional relationships, specialist communities, industry groups, users of adjacent tools, and introductions from people who understand the role. A short invitation should name the problem area and ask to learn about their current process. It should not promise a revolutionary platform or recruit praise. Ten conversations with the right role can be more useful than a broad survey answered by hundreds of spectators.

Ask for the past because the future is too easy to decorate. “Tell me about the last time this happened” opens a trail of observable details. What triggered the work? Who became involved? Which tools appeared? Where did it slow down, what failed, and what happened next? Ask to see a blank version of the spreadsheet, form, message thread, or report when appropriate. A real workflow contains edges and exceptions that a hypothetical answer politely removes.

Resist explaining the solution too early. Once the founder begins pitching, the customer becomes an audience and often responds with encouragement. Stay with the problem long enough to understand its frequency, cost, and ownership. Who is frustrated by it, who controls the budget, and who would have to change behaviour? Silence helps. People often add the most revealing detail after the neat answer has finished and nobody rushes to fill the gap.

Listen for differences between interest and evidence. “That sounds useful” costs nothing. A customer introducing a colleague, sharing examples, scheduling a follow-up, agreeing to test a manual service, or discussing budget gives up something real. Do not force commitment during a research conversation, but notice when urgency creates it naturally. Also record what contradicts the idea. The interview is not successful only when it confirms the founder’s first belief.

After several conversations, compare patterns instead of collecting memorable quotes. Which event repeats? Which workaround appears across organisations? Do the same people feel the pain and control the purchase, or are they different roles? Where does language converge? A single dramatic story can inspire a feature nobody else needs. Repeated structure is more useful because it suggests a product can serve more than one exceptional case.

End each conversation by thanking the person, asking whether you may return with what you learned, and requesting an introduction only when it feels appropriate. Then let the evidence change the brief. Perhaps the audience narrows, the promised outcome shifts, or the product begins as a manual test rather than software. Talking to potential customers is not a ceremonial step before the real building starts. It is where the first version is built in language, with mistakes still cheap enough to erase.