

You’re Not the User
Why product teams drift from reality and how to stay anchored in it. In product, we love to talk about being “user-centric.” But staying user-centric, especially in the messiness of building, scaling, and shipping, is much harder than it sounds.
I've wanted to write this article for years. Every organization I worked for or talked to over the years is guilty in its own way. Every team I’ve worked with truly wants to build the right thing for their users. Why wouldn't they? They’re smart, fast-moving, and care deeply.
But then, when digging deeper into how we decide what to build and where our work comes from, a familiar and dangerous pattern shows up over and over.
Somewhere along the way, we start operating more from assumption than reality. Not because we're sloppy or arrogant, but because we're deep in it. Juggling sprint commitments, internal expectations, fire drills, bonuses, analyses, prestige.
The world inside a company is loud and opinionated and the world outside gets more blurry.
It starts small. A roadmap gets shaped around technical feasibility. A feature is prioritized because a big customer shouted loud enough. A new initiative launches based on gut feel. Nobody stops and asks: Is this what most of our users actually need right now? Is this the most important thing to do?
And slowly, the gap opens up between the version of the user we have in our heads, and their real experiences out there.
A core issue
This isn’t just a UX or research problem. It’s a deeper issue in my opinion:
And once we start building for the internal picture of reality, the downstream effects compound:
- We prioritize features that don’t get used.
- We polish flows that users rarely reach.
- We ignore core flows because they are not fancy at the moment.
- We measure success by shipping, not by solving.
When you zoom out, you realize: this isn’t about effort, it’s about orientation and structure.
Inside vs. Outside
Internally, everything is being prepared to feel coherent. The roadmap is structured. The personas are polished and make sense. The team is aligned around clear metrics and milestones.
Externally, reality is way messier:
- Users interact with your product sporadically, often under stress, often with half attention.
- Their needs shift depending on their company size, their team maturity, the season.
- They drop off silently, abandon features without explanation, or churn for reasons that never show up in your analytics.
We design and make decisions for a rational, linear user, when the real users are emotional, unpredictable, context-bound.
And the further these two worlds drift from each other, the harder it becomes to reconnect. Markets can change overnight but most organizations are too slow to react this fast.
Why it happens
This drift is never intentional but almost all organizations have some kind of gap between their internal and external view of the users. Mostly because it’s baked into the way most companies operate.
- Internal urgency wins: There’s always something pressing: the next launch, the sales commitment, the quarterly OKR. These internal forces are loud, visible, and measurable while real user needs are often quiet, invisible, and ambiguous.
- Assumptions harden into “facts”: Personas from a past research sprint. Anecdotes from sales calls. That one big customer with very specific edge-case needs. Over time, these fragments become the foundation for big product decisions without anyone double-checking whether they still hold true.
- Metrics create false certainty: A spike in clicks is interpreted as engagement. A slight uptick in retention is seen as validation. But metrics without context can mislead. A confused user clicking around desperately might look exactly like a curious one exploring value.
- The feedback loop breaks: In many teams, real user input only shows up at the beginning of a project, if at all. After that, it’s silence. And silence gets filled with assumptions.
The result?
We optimize for what we can control and forget to stay curious about what we can’t see.
One problem I have experienced myself over and over. What happens if new information shakes up past decisions significantly? Do you stop doing what you are working on and pivot? Do you change at all?
And then the system reinforces itself
Once the team starts drifting from reality, the system tends to reward staying that way.
We celebrate launches instead of outcomes.
We reference personas instead of actual users.
We default to what feels familiar and manageable, not necessarily what’s real or right.
I’ve heard variations of the same phrases too many times:
- “Users just don’t get it.”
- “This is a critical feature” (based on one stakeholder).
- “We already know what they need” (even if that knowledge is outdated).
- "I'm in the ICP myself"
And in the absence of fresh insight, those narratives harden. The gap widens even more.
So what helps?
There’s no silver bullet. But there are habits, both for individuals and for the organization that I’ve seen can make a real difference.
What you can do as a PM or founder
- Talk to real users, regularly: Not in sprints, but as a rhythm. One short call a week can surface something your dashboards missed entirely. Don’t just ask what they think of your latest feature. Ask what they’re trying to get done, how they work, what frustrates them, what they reach for when they’re stuck.
- Dig into behavior, not just numbers: Go beyond the headlines. What are users actually doing? Where do they drop off? Which parts of the product are completely ignored? Segment your data. Patterns often don’t show up until you look at specific cohorts or behaviors.
- Make what you learn visible: Don’t let insights die in Notion. Share quotes in Slack. Bring real user stories into team meetings. Make the user feel present in the room — even if they’re not physically there.
- Build discovery into your normal week: Not as an extra thing, but as part of how you work. One light usability test. A quick follow-up survey. Ten minutes reviewing heatmaps. The best PMs I know treat user understanding the same way they treat backlog grooming — ongoing, expected, non-negotiable.
What product orgs should embed
- Create space for continuous discovery: Don’t make research something that needs special permission. Give teams recurring access to users. Lightweight, regular, and cross-functional. Make sure it’s easy to listen and even easier to learn.
- Validate before, during, and after: Don’t wait until after launch to find out if something works. Validate the problem early. Test the prototype. Follow up post-launch. Make user validation a standard part of your team’s “definition of done.”
- Make user insights available: Create a shared library of research findings, support themes, call notes, analytics breakdowns. Make it searchable and accessible not just for researchers, but for everyone making product decisions.
- Shift focus from output to outcome: Don’t just celebrate that something shipped. Celebrate when it actually helped users. Track real progress. What’s your version of “7 friends in 10 days” or “2,000 messages sent”?
- Build a culture that values evidence: Normalize the question: What do we know about users here? Encourage teams to change course when new insight emerges and celebrate them when they do.
Final thoughts
Staying close to users doesn’t mean running interviews every day or second-guessing every move. It means building habits that keep your team grounded in reality and close to real user's experiences, especially when pressure mounts.
The teams that do this well don’t just move fast -> they move with clarity.
They don’t chase outputs --> they create outcomes.
They don’t just build what they believe --> they build what’s needed.
It doesn’t need to be more complicated than that.
But it does need to be consistent.