Product Management is All About Decision Making: Here’s How to Improve Your Decision Quality

Background

At the end of the day, the ultimate measure of a successful product manager is really about showing consistently good judgement across a range of decisions that lead to positive outcomes for the company.  Hard skills are required to do the job - being analytical, understanding the technology, mastering discovery, solution development, experimentation to ship product.  Soft skills are required to lead within the business, influence others, and keep the team aligned and engaged and move up to larger roles.  However, without the ability to make key decisions with positive outcomes, over and over again, a product manager will ultimately struggle to deliver value for customers and be effective within the organization.

When I was first considering this blog I was spending the summer of 2021 nerding out on psychology books and research related to improving decision quality and removing biases.  To me, as a career product manager, I realized I’d made it through two degrees and over a decade of being a PM, and aside from a handful of consumer behavior classes, I couldn’t remember any formal training to help me systematically make better decisions.  It’s a gap, it’s a big one, and something that product managers and leaders of product teams should really focus on for development.

I know there are “process people,” and then those that find too much process restrictive, annoying, unnecessary, etc.  When it comes to improving the quality of decisions you’re making as a product manager, I think you can still have a lot of degrees of freedom in what you decide to do, but you will benefit greatly from trying to standardize how you decide.

In their awesome book Decisive, Chip and Dan Heath cite the following research finding:

“When the researchers compared whether process or analysis was more important in producing good decisions—those that increased revenues, profits, and market share—they found that “process mattered more than analysis—by a factor of six.” Often a good process led to better analysis—for instance, by ferreting out faulty logic. But the reverse was not true”


Processes can also be flexible to expand and contract as necessary to fit the situation.  There are some basic things you always want to think about regardless of the size and impact of the decision, and then for the bigger ones you’re going to want to add some steps.  I would also argue that if you’re doing it right, the process will help you move faster than if you try to go without and realize things late in the game.


How to Improve Your Decision Quality as a Product Manager

What follows is a very basic framework for trying to improve your day-to-day decision making processes, product managers should consider 3 basic phases to each decision. I’m going to continue to build this out over time, but to start, here’s 3 phases to consider:

  • Framing

  • Developing

  • Deciding


Framing

In my own personal experience I think this is the most common problem area for most people, especially when a decision is framed for you by someone else.  Ensuring that you’re looking at the problem correctly and that everyone agrees to the frame is critical no matter how big or how small.

There are many techniques available to help frame decisions effectively and you should invest in studying many to build up practice applying different approaches to different situations.  Beyond studying the best practices, I think you can boil down to a few critical questions you need to ask yourself:

  • Who originally framed the problem?  Do I agree with the framing?  Is the framing aligned to what’s best for the customer and/or the company?  

  • Separate the frame from the implied timeline.  What’s driving the urgency?  Is it actually connected to the problem or is it being added for some external reason? 

Another easy trap to fall into is “whether” choices. This is where someone has framed the decision to “we have decide whether we do A or B.” In the book Perfectly Confident, Don Moore points out:

“Whether” choices tend to neglect opportunity costs. Instead, you ought to be making “which” decisions. That is, you should be choosing from the full set of possible alternatives.

This is super common when someone else hands you the decision frame. “We have to decide whether or not we should do X.” You don’t know how much they’ve thought about other options, and you don’t know if there is some bias driving them to keep the frame limited, so be sure expand the options.



Developing Your Recommendation

Once you’ve established what the real problem is, and the appropriate decision to be made, then you can focus on getting the appropriate information to make a call.  Framing the problem appropriately helps avoid some biases that would come from leaving out relevant information.  Beyond that, you analyze the same sources you would normally, what changes is how you approach it.  

There’s a lot of research around decision making that shows trying to decide (or reach a decision) as a group is not good.  It’s subject to all types of biases including the ever popular “groupthink,” as well as many others. In a more “micro” context of a PM’s daily decisions, this often looks like involving your designer, dev lead, and dev team in reaching a decision through multiple conversations.

A good way to counter biases of group work is to try to work separately from others and then compare your recommendations and logic at the end.  The delight you feel when you realize someone else was working on the same problem and reached the same conclusion as you is justified.  Decision making research shows that this independent approach makes it more likely that you’ll consider a wider range of alternatives and remove biases.  This is similar to a lot of literature on the right ways to do interviews that has found its way into modern applicant tracking systems which force interviewers to write up their assessment and make a call before discussing with anyone else.

Assuming you and the others working on the same problem didn’t magically reach the same conclusion, it’s really important to have a frank data-driven conversation to understand why you landed in different places.  The conversation and additional understanding that comes from discussing the different recommendations helps to identify biases and ensure all relevant information is included in making the final call.

This approach of working separately is easier to pull off when it’s a bigger project, with more resources available and with more time to assess, however that doesn’t mean that it is unavailable for smaller quicker cycle decisions.  Think about the way you typically work with your development team and other product managers and how you raise new topics.  I’ll bet you usually start with “we should do X because of Y & Z.”  Most product managers are in the mode of influencing and trying to get people aligned to a plan from the get go.  Sometimes it’s good to hold off on getting people on board until you know you’ve picked the right path.  Try providing one other person on your team a quick summary of the frame and the relevant facts and have them write down what they would do.  Give them 5 minutes and then discuss for 5 more.  You spent 10 min and probably dramatically improved the quality of the call you are about to make.  You don’t have to slow down in a big way, just work a little differently when the impact of the decision warrants higher confidence.

It’s also important to point out that this is not permission to hide decisions from the team and the larger organization then spring them on everyone saying “I did what the research told me and didn’t work with any of you!” You still need to show your work, be transparent, and bring people along. All this section is saying is that perhaps you should isolate the development of a recommendation from getting people on board with it.



Deciding

Actually making and communicating the decision comes at the end of most of the work, however it doesn’t mean you can completely relax.  I mentioned upfront it’s really important to understand and isolate the timeline required to reach a decision from the decision frame itself.  I find too often that people assign arbitrary timing to decisions, usually for some personal reason they may not be fully aware of.  Even subconsciously, people act in self-interest and seek to avoid pain, which can lead them to push for decisions to be made sooner than is necessary simply to benefit themselves.

This is particularly key because one of the best ways to make a high quality decision is to step away for a bit and come back to it.  Said plainly, don’t rush from framing, to development, to deciding with no gaps.  In Decisive the Heaths discuss how stepping away from a problem and coming back to reconfirm your commitment to a decision helps eliminate transient biases.  Humans are not computers - we can still do things computers cannot, however the computers have us on making the same recommendation over and over again given the same facts.  Humans are susceptible to many biases that can cloud your judgement in the moment and the best way to counter them is to take some time and come back later. In the book Noise, Kahneman, Sibony, and Sunstein highlight:

In other words, the moment-to-moment variability in the efficacy of the brain is not just driven by external influences, like the weather or a distracting intervention. It is a characteristic of the way our brain itself functions.

In the day-to-day PM context, this can be as simple as not making a call in standup based on information you just received, but waiting until after lunch.  Sometimes there are truly time sensitive calls that need to be made and you can’t avoid moving quickly.  In most cases, the urgency is false, being driven by the desire of someone else to close out an open task and move on when in reality there’s no real penalty to waiting.  State your initial recommendation and tell the team you’ll give a final answer within X amount of time and you will reduce the chances of momentary bias affecting your decision.

Summary

Improving your judgement and decision making quality is one of the most important growth areas for all product managers.  The research strongly suggests focusing on a standardized process to improve quality and systematically reduce bias - it’s up to you to expose yourself to lots of different techniques, try them out, and figure out what works best for the hundreds of decisions you make each week large and small.


  

Previous
Previous

Self-Awareness: The Key to Becoming an Effective Product Manager

Next
Next

How I Became a Product Manager: Krislyn McDonnell