Product management is one of the most written-about functions in tech — and one of the most misunderstood. The myths aren't just held by outsiders. Many of the most damaging misconceptions are held by PMs themselves. Let's clear them up.
I collected these misconceptions over nine years of working in product, hiring PMs, being managed by PMs, and watching teams struggle with expectations that didn't match reality. Some of them I held myself until experience corrected me. All of them cause real damage when they go unchallenged.
Misconception 1: The PM Is the "CEO of the Product"
This framing comes from a Ben Horowitz essay written in 2006. It captured something real — the PM's accountability for product outcomes — and then got turned into a philosophy that has damaged more PM careers and team cultures than almost anything else in the field.
The "CEO of product" framing implies authority. CEOs have authority. PMs don't. PMs have influence, credibility, and the ability to shape decisions — but they don't have the organizational power to direct people. Engineers aren't reporting to the PM. Designers aren't taking orders from the PM. When PMs internalize the CEO metaphor too literally, they start managing people who aren't their reports. They make unilateral decisions that should involve collaboration. They develop entitlement to outcomes without earning the trust that generates them.
The better metaphor, in my view: the PM is the person who makes everyone else's judgment more useful. They provide context, clarity, and constraint. They're a force multiplier, not a commander. The CEO metaphor is useful for conveying accountability. It's damaging when taken as a description of authority.
Misconception 2: Good PMs Are Always Objective
There's an aspiration in product management toward pure, data-driven objectivity. The PM who has no biases, who follows the data wherever it leads, who makes decisions based purely on evidence. This is a fiction, and believing in it makes you a worse PM.
Every PM has biases. They have intuitions about what matters, formed by their experience, their background, and the users they've talked to most. These biases are not a problem to be eliminated — they're a resource to be calibrated. The PM's job is not to be unbiased (impossible) but to understand their biases well enough to account for them.
The PM who thinks they're purely objective is the most biased PM in the room. They're not checking their assumptions because they believe they don't have any. The PM who knows they have a bias toward power users, or toward mobile experiences, or toward B2B product patterns, can actively seek out the perspectives that counterbalance it. That's not objectivity — but it's much more useful.
Misconception 3: More Features = Better Product
Feature-complete is not a compliment. It's a warning sign.
The implicit logic behind feature accumulation: more value means more users means more success. The reality: more features mean more cognitive load for users, more maintenance burden for engineering, more testing scope for quality, and more complexity in onboarding. Beyond a certain point, adding features actively makes a product worse — even as it makes the team feel productive.
The products that win in the long run are usually the ones that do fewer things exceptionally well. Notion's early success was partly because it was simple. Slack replaced email by being opinionated. Linear replaced Jira by having fewer, better features. In each case, the product won not despite having less, but because of it.
The PMs who build the most enduring products are the ones who are as aggressive about what not to build as they are about what to build. Saying no is a skill. Removing existing features is a skill. Both are severely undervalued in most product cultures.
Misconception 4: User Research Tells You What to Build
User research tells you about the problem. It does not tell you the solution. These are different things, and conflating them produces a specific kind of bad product decision: the feature that users asked for, built exactly as requested, that makes the product worse.
Users are experts in their own experience. They're not experts in product design or engineering. When a user says "I want a button that does X," they're telling you something true about their experience — they want to be able to do X more easily. They're not telling you that a button is the right solution. Maybe X should happen automatically. Maybe the feature that enables X already exists and just needs to be more discoverable. Maybe X is a symptom and the real problem is Y.
Research narrows the problem space. Design and engineering explore the solution space. The PM synthesizes both. When PMs treat user research as a source of feature requirements rather than a source of problem understanding, they short-circuit the creative work that produces genuinely good products.
Misconception 5: Data-Driven Means Trusting the Data
Data-driven product management is essential. It's also frequently abused to mean "we have a metric that validates our prior decision." The data doesn't validate or invalidate your decision — your interpretation of the data does. And interpretation is where bias lives.
I've watched teams run A/B tests where the "winning" variant won on a metric that didn't matter — and ignored the metric that did. I've watched teams attribute a DAU spike to a feature launch when it was actually seasonality. I've watched a product team declare victory on retention because their 30-day retention improved, while 90-day retention was collapsing.
Data literacy includes the ability to question your own analysis. To ask: am I measuring the right thing? Is this result actually meaningful, or am I fooling myself? What would I need to see to conclude that I was wrong? The PM who can't ask these questions isn't data-driven — they're data-decorated.
Misconception 6: A PM's Job Is to Have Great Ideas
This is the misconception most PMs carry into their first role. The job is to have great ideas — to be the creative engine of the team, to generate the insight that unlocks the product.
The reality: your team will never run out of ideas. Engineers have ideas. Designers have ideas. Sales has ideas. Customer support has ideas. Users have ideas. The PM who adds more ideas to this pile is rarely adding more value. The PM who helps the team figure out which existing ideas are worth pursuing, in what order, with what level of evidence — that's where the leverage is.
The best PMs I've worked with are idea synthesizers, not idea generators. They take in a huge amount of raw input from every direction and find the patterns, the priorities, and the framing that makes everything else make sense. The ideas they "have" are usually the product of listening very carefully to ten different people and connecting what those people couldn't connect themselves.
"The best product managers don't have the most ideas. They create the conditions where the team's best ideas rise to the surface."
Letting go of the identity of "the person with the ideas" is one of the hardest and most liberating things a PM can do. Once you stop trying to be the smartest person in the room, you can start being the most useful one.
Rethinking how your product team operates?
Many of the patterns that hold product teams back are misconceptions that nobody has challenged. I work with teams to identify and correct the beliefs that are limiting their effectiveness. Let's talk.
Work with Yogesh →