Aug 29 2017

Product Management Biases (And How to Avoid Them)

As a product manager, our job is to shepherd the client’s vision to help make it a reality, and along the way make suggestions and improvements based on our research and our own experiences. It is the latter part that can expose when we bring our biases to a project. Which is to be expected — we are only human after all, so no one can fault you for these!

After reading this article on iO9 (The 12 cognitive biases that prevent you from being rational), I began to think of how some of these known biases are relevant in a product management environment. I’ll talk about three big ones that I have fallen into myself, so hopefully, you can learn from my mistakes.

Confirmation bias

This happens when we look for justification in our thinking from sources that are inclined to agree with us. You most often hear about this bias when talking about politics, but in product management, it can appear in the form of a suggestion you make about a third-party integration or methodology that you think would be a good fit for your project.

An example of this might be a project where you are working with a client who requires a large content management system for their project. You have experience with a specific one, so you recommend it. Then you look up articles and blog posts justifying why that specific CMS should be used. While it is a comforting feeling knowing that you have a background with this CMS, your client may not get the benefits from the extra cost, or a large amount of overhead, or whatever the constraints might be.

You owe it to yourself to do as much research as you can on all of the different integrations and methodologies that are out in the universe so that you can feel confident making suggestions based on logical research and not solely on your previous experiences and feelings.

Post-purchase rationalization

Yes, it is exactly as it sounds. We decide to buy something very expensive and as soon as that creeping feeling of buyer’s remorse kicks in we attempt to rationalize (i.e., justify) why we made the purchase.

This can happen easily on any project you work on where you made a decision that turned out to be the wrong one and you now feel like you have to make justifications. Take it from me: you do not have to justify your decisions if you feel that you really can not. It was a mistake, so you must apologize and take ownership of the decision and then work with your team to come up with solutions that your client can agree with.

Your client (and your product) will thank you for your honesty. This happens to everyone from time to time, so don’t beat yourself up.

Negativity bias

I continue to suffer from this myself from time to time, but you can work through it by being communicative with your team. In this bias, we perceive negative news as being worse than it actually is. On any given project, it is very easy to feel overwhelmed at times — a database may fail, the database backup cannot be retrieved, your tech lead is enjoying her much deserved vacation and cannot be reached, the client has sent you three emails in the span of 5 minutes asking for a status; the list can go on depending on your project. At this point, it feels like the apocalypse is imminent.

Before it gets to this point, and you feel overwhelmed, always remember to gather whatever relevant facts you have at hand and call a quick standup with your team. In the example above, if you give your junior developer a few extra minutes, he may find that an unexpected NULL field in the database has caused the issue and that adding error handling for the exception can restore peace in the galaxy.

All kidding aside, bad news can feel much worse than it actually is, so don’t let yourself feel overwhelmed when one or more things go wrong. Left unchecked, these feelings can cause you to make bad decisions in an effort to “right the ship” as quickly as possible, without thought to consequence (like introducing defects into your product or having a team drop everything they are doing without giving them proper guidance). As a former colleague once told me, it isn’t the problem anyone remembers, but how you handled it.

If you are interested in more thoughts like this, you should take an inside look at our proven Product Management Process and learn how we plan for success.

Lauren Mullaney-Reid