How to Talk to Users

Translation and notes

A readable adaptation of the article's core ideas, with the original source clearly credited.

Talking to users sounds simple, but many founders create bad data with bad questions. If you ask whether someone likes your idea, you often get politeness. A better question connects to past behavior, real pain, and decisions that involved time or money.

A user interview is not a pitch. The founder should explain less and listen more. The goal is not to convince the user that the idea is good; it is to understand how their real life works and where the problem becomes painful enough to justify behavior change.

The quality of problem discovery shapes the quality of the product. If the problem is understood shallowly, the product will be shallow too. Good interviews reveal the user's language, buying triggers, current workarounds, and intensity of need.

Users are usually not product analysts; they are witnesses to their own lives. Asking them to predict the future or judge an unfinished idea often creates unreliable answers. Asking about the last time the problem happened, what they did, what it cost, and what frustrated them moves the conversation from opinion into evidence.

Good discovery should become a rhythm, not a one-time research phase. A team that keeps speaking to real users every week is less likely to drift into internal fiction. It notices weak signals sooner, learns the user's language more accurately, and makes product decisions with a stronger connection to reality.

This is a free adaptation, not a word-for-word republication of the original article.