Photo by Tim Gouw on Unsplash

5 Reasons Not to Be a PM

Sari Harrison
Product Coalition
Published in
5 min readMar 4, 2019

--

OK, I am not fond of lists like this. Every item on a “not to” list you can typically turn around and you have a “to” list. I’m trying hard for that not to be the case, but I might fail.

Product management is a tough profession. So there is some value in thinking specifically about why it’s tough. Even if you can indeed turn every item on this list around.

What I’m saying is… no one really loves the things on this list. But you need to embrace them to succeed as a PM.

1. No credit, just blame.

I recently answered a question on Quora about who was at fault if a product failed. My answer (with very little data I might add)? If there was a PM, then the PM is to blame.

If a product succeeds, the PM must fade into the background, offering all the glory to the engineers, designers, testers, and so on. Because they are the ones who did all the “actual” work. But if it fails? Sorry, but that’s all you.

It is your responsibility to make sure the product or feature is set up for success. Not just the market analysis, idea selection, and writing the PRD. But throughout the lifecycle as new data comes in, you need to adjust the plan accordingly.

And at some point, if you are convinced success is no longer within your grasp, it’s your responsibility to pull the plug. Sunk cost be damned.

This is one of the hardest things in the world to do. It’s your baby that you are aborting (too graphic? 🤔). And to add insult to injury, people will not thank you for it or give you any sympathy. They’ll instead be upset at you for letting them get as far as they did before you realized.

So if you do ship a product and it sinks, congratulations 🍾. It’s your fault.

2. No certainty, just ambiguity.

As an engineer, you can write some code, compile it, test it, and know with reasonable certainty that it works. Damn, I miss that sometimes.

What we do as PMs is drive innovation forward. And the only way to do that is embrace uncertainty. But for engineers to deliver code that works (by some definition), you have to give them the impression you are sure it’s the right code to write. Even though you…

--

--

Product management leader (Apple, Microsoft) | Mentor | Lifelong Learner