Every founder has heard it. “Talk to your users.” It gets said so often that it has stopped meaning anything, like a word you repeat until it turns to noise. And yet the same people who can recite it will go weeks without a single real conversation. The gap between knowing the advice and doing the advice is one of the strangest things in product. I’ve been trying to figure out why it’s so wide.
Here’s my first suspicion: the advice sounds like a task, but it’s actually a discipline. “Talk to users” reads like “buy milk” — a thing you do once and check off. But it’s more like “stay in shape.” There’s no version where you finish. The moment you stop, the muscle atrophies, and the worst part is you don’t notice it atrophying, because the product keeps shipping and the calendar keeps filling and you feel busy. Busy is the great anesthetic. You can be busy for a year and never once hear a stranger describe your product in their own words.
The second suspicion is harder to admit: talking to users is emotionally expensive. Building is safe. When I’m building, I’m in control, the compiler agrees or disagrees with me on clear terms, and nobody looks disappointed. A user interview is the opposite. You are voluntarily walking toward the possibility that the thing you’ve poured months into is confusing, or unwanted, or solving a problem the person doesn’t actually have. Some part of the brain treats that conversation as a threat, and it’s very good at generating reasons to postpone it. “We’ll talk to users once the beta is ready.” “Let’s not waste their time until it’s polished.” These sound like professionalism. They’re avoidance wearing a nice coat.
But suppose you clear both hurdles. You make the time, you swallow the discomfort, you get on the call. There’s a third trap waiting, and it’s the sneakiest: most “user conversations” aren’t conversations at all. They’re pitches with a question mark at the end. You describe your feature and ask, “Would you use this?” and the person, being human and kind, says “Yeah, totally, I’d love that.” You hang up glowing. You learned nothing. You have collected a polite lie and filed it as validation.
So what actually helps? A few things I keep coming back to.
Ask about the past, not the future. People are terrible at predicting what they’ll do and pretty reliable at reporting what they’ve already done. “Would you pay for this?” is fantasy. “Walk me through the last time you tried to solve this — what did you do?” is data. The past has friction, workarounds, and swearing in it. That’s where the truth lives.
Shut up longer than is comfortable. The most useful sentence in an interview is usually the one that comes three seconds after you think they’ve finished answering. Silence is a vacuum; people fill it with the real thing.
And separate the person who builds from the person who has to defend. It is nearly impossible to hear “this is confusing” as information when your ego is standing in the doorway. If you can, go into the conversation actively hoping to find the flaw, the way a good editor hopes to find the typo. Finding it is the win.
The uncomfortable conclusion I’ve landed on is this: “talk to users” isn’t ignored because founders are lazy or stupid. It’s ignored because doing it well requires you to feel bad on purpose, repeatedly, forever, with no finish line. That’s a real cost. The advice never mentions the cost, which is exactly why it never sticks. Name the cost, and suddenly the advice becomes doable — not because it gets easier, but because you stop expecting it to.
The science, to look up: The Mom Test (Rob Fitzpatrick) on asking about past behavior; social desirability bias; and prospection / affective forecasting errors in predicting one’s own future behavior.
Liked this? Get the next one in Working Theory.
Going weekly in August (it's in beta now). One genuinely interesting read on building, the brain, and the science most people missed.