Most product management content tells you what to do. This one is the opposite — a list of my biggest product manager mistakes over nearly a decade in the job, so you can learn them the easy way instead of the way I did. There’s plenty out there on how to become a PM and what a PM should do; think of this as your quick guide to what not to do.
None of these are theoretical. I’ve made every one of them, some more than once. Here are the five product manager mistakes that cost me the most.
Mistake #1: Falling in love with my product
This one has bitten almost every product manager I know, regardless of experience — and I’m no exception. We get so invested, so passionate about our product, that we start romanticising it. The industry doesn’t help, with tropes like “a product manager is the CEO of the product” or “your product is your baby.” (For the record, you’re not the CEO of anything.)
The trouble starts when that love makes you defensive. You stop being open to negative feedback. You turn a blind eye to the product’s shortcomings and only ever point at the good bits. And that quietly kills any scope for improvement — because you can’t fix what you refuse to see. The lesson took me a while: be objective about your product, and don’t take critical feedback personally. It’s aimed at the product, not at you.
Mistake #2: Building with almost no feedback
Plenty of products get built in a silo — little to no input from actual users, internal stakeholders, or even a basic competitor review. And when you build like that, you’re really just assuming: assuming the user will behave a certain way. That is almost never how it plays out.
You should always be hunting for feedback, direct or indirect. Talk to your users. Talk to finance, sales and marketing. Talk to your engineering and design teams. Poke around competitor platforms. Read the social-media comments, the Play Store and App Store reviews. Believe me, there is a mountain of feedback out there about every product — you just have to be open to it.
One caveat, though, which leads straight into my next mistake: don’t act on everything that lands in your lap. You have to learn the art of filtering the relevant feedback from the noise.
Mistake #3: Not being able to say no
This is the near-exact opposite of the last one — saying yes to every product request that comes your way. In my experience it’s worst in your early years, when you’re nervous, maybe a little scared, to put your point across to senior leadership. So you just nod along to every idea from your manager, the sales head, sometimes the CEO.
Learn to say no. If a request genuinely doesn’t hold up, say so and reject it. Put mistakes #2 and #3 together and here’s the balance I wish I’d found sooner: be open to feedback, but assertive enough to turn some of it down — because plenty of the requests you’ll get are, frankly, silly.
Mistake #4: Skipping documentation
For a long time I built products with little or no documentation. This is especially common in startups and smaller teams, where you’re permanently in firefighting mode and, under the banner of “execution speed” or “moving fast,” you ship things undocumented and patch bugs on production as they appear. Even when there is documentation, it’s often poor.
Bigger organisations have the opposite problem — over-documentation. But if I had to pick, I’d take over-documentation as the lesser evil every time. Here’s the very practical reason. Skip the docs and, depending on your rapport with engineering, you’ll probably get away with it until launch. But when something breaks in production — and it will — everyone starts looking for a scapegoat, and that scapegoat is usually the product manager. Good documentation is indispensable in exactly those moments: it helps you resolve the issue faster and keeps accountability honest across teams. And when you move on and someone inherits your product, no docs means they’re shooting in the dark, reverse-engineering your logic with the eng team before they can improve anything. That’s just unprofessional. (This is a big part of why I’m such a stickler for a proper PRD.)
Mistake #5: Going quiet when things go wrong
The last one is the most underrated: no proactive internal communication. It doesn’t matter how well you plan strategy, roadmap or sprints — every now and then, things go sideways. A release slips. And the mistake is holding some unrealistic hope that it’ll magically work out, so you sit on the update until the very last moment.
Here’s the thing: your manager, your head of product, your CEO — they’re all fine with a reasonable delay, as long as they get a timely heads-up and an honest explanation of the root cause. If you’d committed to four weeks and two weeks in you sense it’s slipping, send the heads-up then. Be transparent, don’t hide things. The blow-up happens when your boss is expecting a release in two days and only then do you say it’s not happening — that’s when people lose their calm, and that’s when you’re in trouble.
To be clear, I’m not saying don’t take timelines seriously — put in every effort to hit what you committed to. But the moment you’re sure you won’t, communicate it early, because everyone downstream has their own stakeholders to manage. Your sales and marketing counterparts have their own seniors to update. Missing a date is survivable. Sitting on the message until the last minute is the real mistake.
Turning product manager mistakes into lessons
These are some of my biggest product manager mistakes — and with time, I’ve come to see them as learnings rather than mistakes. Falling in love with your product, building without feedback, saying yes to everything, skipping documentation, and going quiet when things slip: none of them are exotic. They’re the ordinary, human traps that catch almost everyone at some point. The good news is they’re all avoidable once you can see them coming — which, if you’ve read this far, you now can. If you want to sharpen the flip side of these, my write-up on the top 10 product management skills is a good next read.
Frequently Asked Questions
What are the most common mistakes product managers make?
Five of the most common: falling in love with your own product (and getting defensive about criticism), building with little or no user feedback, saying yes to every request instead of pushing back, skipping proper documentation, and failing to communicate early when timelines slip. Most PMs hit at least a few of these, especially in their first few years.
How do you decide which feedback to act on and which to ignore?
Weigh it against your product goals and the data, not just how loudly it’s said. Feedback that repeats across many users, or that a clear metric backs up, deserves attention; one-off opinions or requests that don’t fit the strategy usually don’t. Being open to feedback and being assertive enough to reject some of it are both part of the job.
Is it OK to say no to senior stakeholders?
Yes — respectfully, and with a clear reason. Saying yes to every request from your manager, sales head or CEO leads to a bloated, unfocused product. Explaining why a request doesn’t hold up is far more valuable than silently building something that shouldn’t exist.
If you’d rather not learn all of these the hard way, that’s exactly what mentorship is for. I’ve mentored 50+ people into and up through PM roles at Google, Microsoft and Amazon, and a lot of it is simply helping them sidestep the mistakes I made. Book a free 1:1 mentorship session and let’s talk through where you are.
New to all this? Start with what product management actually is, or see what a day in the life of a product manager really looks like.
