My Three Worst Decisions

This week, I want to share the three worst decisions I've ever made as a product manager and the lessons I took away from them.

Mistakes aren’t fun to admit, but it's a critical part of growth. My hope is that by walking you through these missteps, you can avoid falling into the same traps and make better calls when you find yourself in similar situations.

Every product manager faces tough calls. Do you push through on a technically messy feature? Do you go for quick wins instead of long-term value? Do you prioritize something because it matters to stakeholders, even when you don't think it won’t matter to customers?

These are real decisions that can shape not only your roadmap, but your reputation and career. By seeing where I went wrong, you’ll get a clearer lens on how to approach these moments in your own work.

Decision making is a difficult, yet critical characteristic of Product Management. You’re balancing technical constraints, customer needs, and stakeholder expectations, and it’s easy to let one of those voices dominate when you feel pressure.

Sometimes you cling too tightly to an idea, even when the cost outweighs the benefit. Other times you give in too quickly just to show progress. And sometimes, you chase the wrong things for visibility, forgetting that visibility on the wrong work doesn’t make you look good.

I've never seen good metrics to evaluate a Product Manager's decision making

This is because it's not possible to quantify it. You'll never truly know how things would have turned out if you decided to go the other way. Best you can do is guess.

That said, given the benefit of time and seeing things work out poorly is a pretty good way to identify a misstep.

So let's dive in to my dumb decision hall of fame, shall we?

I chose to chase small wins at the expense of big impact

I gave in to pressure for quick wins. I was tasked with starting a new team in a technical space our company had never worked in before. Stakeholders wanted to see “fast progress" to justify the expense, so I agreed to focus the team on smaller, incremental features that we could ship fast.

On the surface, it looked good. Give the engineers a chance to learn the tech stack. Figure out the release cycles. Find out if our customers would use this new product. Learn big and continuously; fail fast and small. All the Product slogans we like to say.

Fast forward and we had spent about 8 months tinkering around the edges while ignoring the more impactful work that could have actually gained some attention and moved the needle for our customers.

Did we release things into market? Yes. But did customers really care or even pay attention? Not really. We gained enough to keep going, but we didn't have any Summer blockbusters on our hands.

Those stakeholders who wanted to see progress weren't upset. But they certainly weren't impressed either. When I went back the next year and asked for a bigger budget, what do you think they said? (If you guessed "no", you are correct)

The danger with small wins is that they feel productive. They keep people happy in the short term. But if they aren’t tied to real impact, they create the illusion of progress without actual value.

Customers don’t care that you released ten small tweaks if the core problem they’re struggling with is still unsolved.

This experience taught me to balance incremental gains with bigger bets. Small wins are important, but they can’t become your strategy.

As a product manager, you have to be the one to remind your team and stakeholders of the bigger picture, even when the pressure for quick delivery feels overwhelming.

I ended up going on a crusade instead of cutting bait and moving on

I decided to hold onto a feature that was technically messy and riddled with blockers. From the beginning, it was obvious that building it would be slow, expensive, and painful. So we decided to start small with a super lighweight MVP.

I believed that once we overcame the obstacles, we’d have something that was a huge win. The reality? I SIGNIFICANTLY underestimated the complexity of the work.

We wasted months worth of time and money on something that never made it into the market anyway.

That's right. It never saw the light of day. The fail fast and small slogan I mentioned before? Threw that one away on this body of work.

"I said I was going to do it, and I am going to get this goddamn thing out the door" was my mindest.

When a feature fights you every step of the way, it’s usually a sign to reassess.

Here's the problem. On some level, any decision you make to build or not build something has a financial implication. In your business case, you look at how much revenue you can generate (or cost you can reduce). Then you look at the cost to create the thing. Now you can calculate a time period for ROI and the profitability of the work.

In other words, anything you decide to build made sense to your company based on how profitable it would be. But if it ends up taking twice as long to build, and in turn costs twice as much, the time it takes to make back what you spent just doubled as well.

Once building it no longer makes financial sense, it's dead.

In this case, we could have pivoted to solving a related problem in a simpler way that delivered value much faster. But I was too stubborn to let go.

The trap is believing perseverance is always the noble choice. Sometimes it is. But in product, perseverance while in the wrong direction is simply waste.

I chased visibility over value

The third mistake is the one I regret most, because I knew better at the time. I chose to prioritize work that I knew wasn’t valuable for customers simply because it had visibility with stakeholders.

It looked like a smart move politically. I was frustrated about not receiving a promotion despite delivering strong products. I thought it would earn me credibility and recognition. And frankly, I had done it in the past. Sometimes (solely from a self-serving perspective of career management, not being a GOOD Product Manager) it is better to have your boss' pet project on your plate than something that is actually the best for customers.

This time, it backfired.

This is the danger in taking work directly from senior leaders. I have literally seen people with VP titles, all the way up to CEO bring work in and force it on the backlog for the following reasons:

1. Their wife doesn't like your product
2. Their neighbor told them about a commercial he saw on TV
3. Their friend from college told them his company did and it was "a success" (No further math, metrics or detail)
4. They know someone with a start-up doing the same thing
5. They thought of it themselves on their way in that morning

This idea came to me from one of the sources on that list through a VP.

And in this particular case, I knew it would fail. Because remember I am a Product Manager. I spend time time actually talking to our customers and trying to find and better understand their problems.

And the specific problem this bad product idea solved? I had already done ALOT of research in that general area and knew it wasn't one customers really had.

To be fair, this particular thing defied logic. Without getting bogged down in the details, it is something you would ONLY know by talking to customers. If you had never spoken to one in your life (like this stakeholder), you would probably think there would be a demand for it.

But, instead of doing what I should have done as an experienced Product Manager and presented my insights and knowledge, I just agreed to deliver it. It was pretty simple and wouldn't take long to build.

While we successfully delivered the work, the work itself didn’t deliver for us. Since it wasn’t solving a meaningful problem, it landed flat. Like really flat. Like less than 0.5% of customers ever attempted to use it.

Attempted is the keyword there. Nobody (Zero) actually completed the flow in the first 60 days it was in market. And we told them about it. It wasn't a "no paid marketing" thing. After 90, it was clear it would cost more to keep it live than it would ever earn, so we just turned it off entirely.

Mind you this was an actual product feature release. Not a test, pilot, or MVP. We skipped all that becaue it came from senior leaders.

And instead of looking good to leadership, I looked like someone who spent resources chasing initiatives that didn’t matter. Visibility without value is a trap.

In fact, it’s far worse than working quietly on something impactful. Because when the spotlight is on you, the lack of results is amplified.

The lesson? Don’t confuse visibility with progress. Real credibility comes from solving important problems, not from showcasing flashy work that doesn’t stick. If your instinct tells you something isn’t a real problem space, trust it.

Because here's the thing. When that VP talks to their boss, are they going to explain that they sent you off to deliver this thing because their drunk friend mentioned it once at a bar?

I will bet that 99 times out of a 100 they do not. What gets reported up the chain is that YOU failed. Not them.

This is a case where saying no and showcasing your expertise may irritate a stakeholder, but it is far less damaging than saying yes to the wrong thing.

In Closing

Looking back, the three worst decisions I made as a product manager weren’t about missing a market trend or designing a bad feature. They were about ignoring my instincts and chasing the wrong priorities.

If you take anything away from this, let it be this: your job is not to deliver the most features or gain the most attention. Your job is to create real value for your customers and your company.

The decisions you make along the way will determine whether you succeed at that or not.

Mistakes will happen. What matters most is whether you let them define you, or whether you let them refine you.

Thanks for reading