Many startup teams think they’re “listening to users” because they run surveys and interviews. The trouble starts when behaviour subtly contradicts everything users said. After 22 years building and fixing software products, including nine at Meta, I’ve learned that the real risk lives in that gap. Here’s what listening to users actually looks like in practice.

At LSE Startup School this week, a facilitator said something that landed with a "boom"..for me at least:

“Misunderstanding the customer need is the biggest risk to any startup.”

The thing is, we all know this to be true. We have heard this being said many times, in many forms. So why did it land so?

We care so deeply about the people we are building for. Founders are under pressure; to ship, to raise, to keep the team moving, and under that pressure, “listening to users” can quietly turn into “collecting just enough input to feel safe.”

This isn’t about blame. It’s about structure. The way most teams try to listen to users makes it almost impossible to see what’s really going on. Believe me, I have fallen into this trap before.

A few years ago, I worked on a product at Meta - Facebook Classrooms. The user research indicated people wanted it. The use cases were clear. But people weren’t using it. The gap between what users said they’d do and what they actually did was the whole story. The product was deprioritised.

Why surveys and interviews feel like research and why they’re not enough on their own

Surveys and user interviews play a vital role in collating research data. On their own, though, they’re not enough.

Surveys tell you what people say they will do or feel i.e, their stated preferences. Recall the last time you took a survey. Do you recall stating the facts as they were or rather, how you felt, what you would usually do because that’s who you are? Behavioural research consistently shows that stated preferences often differ from what people do in real contexts. It’s not because users are dishonest; it’s because we’re all bad at predicting our own behaviour.

This pattern shows up in UX: what people say and what they do can point in different directions. I can tell you “I love this feature”, but then never use it.

User interviews have a similar trap. When someone close to the product leads the conversation, a few things happen almost automatically:

  • Users try to be kind.
  • They soften anything that might sound too harsh.
  • They don’t want to let you down, so they tell you the polite version.

Again, not because anyone is bad, but because we are wired for social harmony.

So what does listening to users actually look like?

In practice, it looks a lot less like “asking what they think” and a lot more like watching what they do, then joining up the dots.

Three parts, working together:

Seeing the product through truly fresh eyes

That might mean sitting with someone who’s never seen the product and watching them try to complete a task. No coaching. No saving them when they get lost. Just notice where they hesitate, where they improvise, where they silently give up. Those first three minutes often reveal more than ten survey questions.

Reading behaviour before reading opinions

Analytics are not the whole story, but they’re a powerful signal. Looking at where people drop, where they loop, where they stall, without a narrative already in your head, can be uncomfortable and incredibly useful. The key shift is moving from “does this data support my story?” to “what story is this data trying to tell me?”

Having conversations where users can be honest

Interviews are still valuable, especially when the person asking has no stake in a particular answer. When someone independent runs the conversation, users tend to be a little more direct. They don’t feel like they’re criticising the person who built the thing. They’re just describing their experience. That small change in dynamic often surfaces what wasn’t said on previous calls.

None of this is flashy. It’s not a new framework or a trendy tool. It’s patient, sometimes uncomfortable observation.

Why it’s hard to do this from inside your own product

If you’re a founder, none of this is news. You already know that what users do matters more than what they say. You probably wish you had more time to dig into it properly.

The hard part is structural:

  • You’re close to the product. Your brain fills in gaps your users still fall into.
  • You’re carrying pressure from investors, team and runway.
  • You’re human; it’s difficult to want to see something that might mean painful rework.

Over time, that creates a quiet gap between what the product is doing and what you think it’s doing. That gap is where most of the real risk lives.

A more honest definition of “listening to users”

So maybe “listening to users” in a startup context needs a broader definition:

  • It’s not just sending a survey.
  • It’s not just running interviews.

It’s building a regular habit of:

  • Watching real people try to use your product with no coaching.
  • Reading behaviour in your analytics before you read opinions.
  • Having conversations where users can be honest, ideally with someone independent.

Surveys and interviews still have a place inside that, as long as everyone involved understands what they can and cannot tell you. There’s a whole body of work on stated vs revealed preference that shows how often what people say diverges from what they actually do in context.

If you’re a founder, and any of this feels uncomfortably familiar, you’re not alone. Every team I’ve worked with has had some version of this pattern. The good news is: once you see it, you can change it.

Often, all it takes is one fresh pair of eyes, with no stake in the outcome, looking at what your users actually do and saying out loud what that behaviour is trying to tell you.

If this hits close to home, you’re the person I’m writing this newsletter for.