Product Managers shouldn't see themselves as users of their own products

I’ve lost count of how many times I’ve fallen into the same trap: assuming I am the “typical” user of my own product. It’s a seductive illusion. After all, I know the product inside and out. I understand the market, talk to customers, and make the strategic calls. But every time I slipped into that mindset, the outcome was the same: features that made sense to me but puzzled real users.

This is one of the most common and costly mistakes Product Managers make. It’s not arrogance, it’s human nature. We naturally assume that people who use our products think, behave, and decide as we do. Unfortunately, they don’t. And that’s a very good thing, because those differences are what make discovery work both difficult and fascinating.

So why is it so dangerous to see yourself as your own user?

Why Our Perspective is Often Wrong

Product Managers often mistake their deep knowledge for universal understanding. But that expertise can actually distort how they perceive real customer experiences. Here’s why.

Limited perspective. A product manager’s view is shaped by their team, their goals, and their strategic lens. You cannot represent the full diversity of users’ perspectives.

Blind spots born of expertise. The more skilled you are, the harder it becomes to empathize with beginners. You forget what it’s like not to know, which means your onboarding, guides, and UX may speak a language most users don’t.

Too much exposure to tech. If you spend your day thinking in terms of features, APIs, and flows, it’s hard to imagine how a less technical person navigates your product.

Bias toward your own workflow. You’re solving your problems, not necessarily your users’. You know shortcuts, hidden pathways, and workarounds that regular users don’t even realize exist.

Innovation blindness. When you rely solely on your perspective, you close the door to new insights that often come from unexpected user behavior.

In short, believing you are your user feels efficient, but it quietly disconnects you from reality. You aren’t the customer; you’re the interpreter. Your role is to translate user needs into products that solve real problems in delightful ways.

So, How Do You Avoid This Trap?

When you stop designing for yourself and start discovering for others, your product fundamentally changes. You move from intuition-driven design to evidence-driven growth. Let’s explore several actions that help shift focus away from assumptions and closer to authentic understanding.

1. Know Your Customer (KYC)

There’s no substitute for well-conducted customer research. Partnering with specialized research companies or internal insights teams can help reveal motivations, pain points, and behaviors that surprise you. You may think you know your users, but data from real interactions often tells a more nuanced story.

Go beyond surface-level stats. Conduct interviews, observe usage contexts, and capture emotion as much as function. A customer is not just a data point; they’re a person navigating their own world through your product.

2. Build Living User Personas

Personas aren’t static marketing slides; they’re evolving representations of who your users truly are. Build them using actual data rather than assumptions. Start simple: what are their jobs, frustrations, and goals? Then refine over time as you gather more behavioral evidence.

Each persona should inform decisions throughout the entire product lifecycle: from ideation to marketing. Keep them close to your team’s daily conversations, not hidden in a shared drive.

3. Focus on Jobs to Be Done

“Jobs to Be Done” (JTBD) reframes how you view your product. Instead of asking, “What features should we build?” you ask, “What tasks are people trying to accomplish?” This perspective grounds your innovation in the users’ true goals, not just their requests.

When done well, JTBD workshops uncover powerful insights. You may discover that users aren’t buying your product; they’re hiring it to solve a problem in their lives. That distinction changes everything about how you prioritize and design.

4. Replace Opinions with Data

We all have opinions, and that’s the danger. Product instincts are valuable but can mislead when left unchecked. Establish a culture where analytics, experimentation, and real user data guide decisions.

For every idea you love, ask yourself: what evidence do I have that users will love it too? If the answer is none, go find it. Opinions are loud, but data is the truth.

5. Quantitative Discovery

Numbers tell stories, too. Use surveys, analytics dashboards, and behavior-tracking tools to collect a wide sample of user inputs. Be intentional about your questions: vague phrasing invites vague answers. The goal is to measure sentiment, frequency, and friction points, not just “likes” or “dislikes.”

6. Learn Fast with Minimum Viable Products

Instead of theorizing endlessly, launch something small and learn from real feedback. A Minimum Viable Product (MVP) is not a half-baked version. It’s a deliberate experiment to test user response.

Add quick feedback loops, embedded polls, or direct interviews. Watching users interact with even a rough version of your product teaches you far more than any internal debate ever could.

7. Qualitative Discovery and Continuous Conversation

Quantitative data tells you what is happening; qualitative discovery reveals why. Talk to users, watch them use your prototype, and listen to their hesitations.

Ask open-ended questions and let silence do some of the work. Users often reveal their biggest frustrations in what they don’t say. These conversations are gold; the more you have, the better you understand not just usage, but emotion.

8. Embrace the Beginner’s Mind

One of the hardest but most valuable skills for any Product Manager is learning to see your own product as if for the first time. This means regularly stepping back, questioning your assumptions, and seeking dissent within your own team.

Invite new employees, customer support agents, and even non-technical friends to test your product. Fresh eyes catch blind spots you’ve long grown immune to.

The Bottom Line

When you assume you know your users, you build for yourself. When you listen to your users, you build for growth.

The line between empathy and assumption is thinner than most PMs realize. But cross that line often enough, and you’ll know the difference instantly. One leads to insight, the other to rework.

So the next time you’re designing a feature, shipping a roadmap item, or defending a product decision, ask yourself this simple question: 

Am I solving a real user problem, or just validating my own perspective?

How do you personally stay connected to your users’ reality?

Also, If you want to get a new PM job in 2026, Aakash Gupta and my cohort "Land PM job" started enrolling for the 2nd edition, after already getting people hired in the middle of the first one!

Enroll here: www.landpmjob.com