Most founders I meet don't talk to users

19 August 2026

A founder messaged me the other day. She was about to run her first customer interviews and wanted feedback on her questions. She knew she had a tendency to ask leading questions because of her background, so she sent me what she was planning to ask.

The list went something like this:

• Show them the ads
• "Do you have any feedback for our ads?"
• "What would you like to see more of?"
• "Do you think the landing page conveys the product clearly?"
• "Is there any point in the checkout process that frustrates you?"
• Observe them using the landing page and ask when they decided to sign up for the trial

Good intent. But poorly designed imo. 😅¹

I told her the list mixed two different tools: user interviews and usability tests. That mix and line of questions may introduce bias. When you show people something and ask for their thoughts, you get opinions instead of lived experience or real behavior. That data isn't very useful. It's a common mistake for founders. I've made it too.

This isn't a one-off. Whether it's first-time founders or people with a decade of experience, many founders, particularly in Southeast Asia, don't talk to users enough. Some are foreign to user interviews and usability tests entirely. That, to me, is alarming.

Data tells you what. It does not tell you why.

If a user churns or drops out at a specific step, analytics gives you that. But data doesn't explain why.

A user might churn because the product already solved their problem and they're satisfied. Or they might churn because it failed their expectations entirely.

Same data point, completely opposite reasons.

It's on founders to figure out which one it is, and you can't figure that out from a dashboard.

User interviews and usability tests are different tools.

I run user interviews to explore open-ended questions on lived experiences like pain points, workflows, friction, habits. I ask questions like "describe how you build products" or "walk me through your last purchase." I avoid questions like "look at X, tell me what you think." That produces opinions, not real experiences.

The problem with opinions is that people try to be polite. They want to be helpful, make you feel good, or sound smart. Whatever the reason, it creates dirty data that sends you down the wrong path. Behavior is much harder to fake.

For most product decisions, I prefer usability tests. You give the user a role and a goal, then ask them to complete a task. For a checkout flow, you might ask someone who fits your ICP to go to the live landing page and complete a purchase. Put them in task mode so they behave like a real user landing on your site.

Behavior is the signal. Opinions are noise.

Talking to users doesn't mean asking them what they want, writing it down, and building it. That's usually the wrong approach. This is the most important idea in this essay, so I want to make sure it lands.

In 1999, Sony ran a focus group for a new sporty yellow Walkman. They pulled people off the street and asked what they thought. Most loved it. The yellow looked fresh, exciting, way better than the boring old black one.

Then Sony let each participant take a Walkman home as a thank you. Two stacks to pick from: yellow 🟨 and black ⬛.

Every single person walked out with the black one ⬛.

That's the gap between what users say and what users do. Opinions sound useful. They feel like data. But they're not. Behavior is the signal that's worth designing around.

Three to five users is enough.

Three to five users per round is usually enough to spot a pattern. That goes for usability tests too.

Whenever possible, bring along designers and engineers so they can watch users struggle firsthand. Seeing is believing. That kind of empathy and context never travels as well through a PRD.

We did this with TickerTown. You don't stop at one round, though.

We ran two rounds of user interviews (about five people each), then a few rounds of usability tests in batches of three.

On top of that, I had casual five-minute conversations with more than a dozen people: aunties, uncles, neighbors. No research setting, no script. Just quick questions on how they invest, how they handle money, what frustrates them. These are questions that surface during the formal sessions, and the casual chats give you unfiltered signal you'd never get in a structured interview.²

The conversations didn't prove the idea works. They made it clearer who might care, who definitely didn't, and what the product should stop trying to be. That's signal you can't get from a dashboard.

Talking to users does not guarantee success.

Of course it doesn't. For critical flows like checkout, you still need an A/B test to prove actual lift in production.

What talking to users does is bring you closer to the person on the other end: their vocabulary, how they think, and how they react to your copy + UI. That kind of proximity to the user is hard to get any other way.³

I know, I know. It might feel slower than jumping straight into code. But over the long haul, this discipline saves the team time and heartache.⁴

The first five to ten sessions will feel awkward. You might feel like you suck at it. Then it becomes muscle memory. You start learning directly from users, and you appreciate the craft of building a great product much more.

I first learned this at Y Combinator more than 10 years ago. "Make something people want." The partners were relentless about getting founders to talk to users. That's where I discovered the practice and started building the muscle.

If you want to go deeper, Steve Krug's Don't Make Me Think is a great, practical book on usability testing. No fluff. There's also a useful YC talk on YouTube that covers the basics well.