Making decisions in the context of high uncertainty is one of the most fundamental parts of product management. In this post I share some hacks and techniques that will help you succeed in this difficult effort.
This post was inspired by Derek Siver’s Lifehacker post Decision Making: There Are Always More Than Two Options.
When [people} say they only have two options, beware. It means they got stuck. Once people get two options, they start comparing the pros and cons of those two, and forget to think of more options.
But remember those silly creative brainstorming exercises we did as kids? As adults, people let the “real world” wear them down so much, they forgot that those lessons were not just for kids.
As I read Siver’s piece, I thought this topic deserved some expansion focused on the types of decisions that product managers have to make. We have a lot of decisions, and many of them are presented as “either/or.” But if we’re good at our jobs we spend a lot of time finding our way out of either/or decisions into much more creative areas.
Sometimes a decision is an either/or, but often it’s not, and as a PM you’re being paid the big bucks to take a look at the bigger picture when considering a decision, to make sure you’re solving the right problem.
If you are quantitative (and I think you probably are, if you’re a product manager), you can think of making decisions as a multi-dimensional problem, where the dimensions include:
- Difficulty of doing the work
- Payoff for doing the work
- Ability to do the work
- Impact of doing the work on the net promoter score (NPS) or other success metric
- Elegance of the work
- Ability to reuse the work
- Ability to reuse earlier work to achieve this
- The option to NOT do the work – what happens if we don’t make any change? (the null hypothesis)
- The opportunity cost of the work – what can I NOT do if I do this work?
- Is this the most important thing I can do with my available resources?
A critical question you must always ask yourself – for any of your options – is “what’s the worst thing that could possibly happen” if we do or don’t do some particular work? You need to always consider that question for the “do nothing” (or null hypothesis) option, since it’s always cheaper and easier to do nothing – and if you do nothing about this particular thing, it means your resources are available for something else that might be more important or have a better payoff.
Of course, figuring out the payoff for a particular set of work can be incredibly difficult, and there is no actual right answer – the payoff always comes in the future, and predicting the future is inherently impossible to do accurately. Or at least, it’s impossible to predict the future accurately enough to distinguish between two “pretty good” options. But you should be able to see the future well enough to tell which of the options are “non-starter” and “pretty good” (and discard the former).
Performance: Optimize or Do Nothing?
As an example of all this, consider what happens when it comes to prioritizing performance improvements in your product. This is something all product managers face, and it’s often presented by engineering, as “either we can ignore the performance problems, or we can work on optimizing the queries.”
But because we know there are never just two options, we immediately try to see what other options there are – other possibilities that can result in improved performance, or that can take the effort that might have gone into the performance work and result in higher net value.
- For example, we can decide that particular functionality isn’t very useful anyway, and we just remove it or don’t release it – if we do that we’ve solved our performance problem without doing any optimizing!
- Or we realize even though this a very valuable capability, our design has gotten us into a corner where it will never perform well, so we need to come up with another design in order to deliver the capability effectively – in other words, we realize that optimizing will never solve the problem. Instead we need to redesign or rearchitect.
- Or we can say, the design is right, and the capability is good, but the implementation went down the wrong road and needs to be scrapped and rethought.
- Or we might say “You know, we faced exactly the same kind of problem in this other capability, and not only should we be able to use the same kind of solution, we should be able to use the exact same solution – in other words, it’s a reuse opportunity.”
- Or we could say, “the nature of this capability is that it can never perform as an instantaneous response, so we will wrap it in an interaction that engages the user much more, despite the fact that it’s taking a while.” (An example of this is the humorous messages that some of the iPhone photo apps give while they are processing images. Processing images on an iPhone is inherently expensive, and takes a long time – only Moore’s Law has much leverage on this, and that takes a while to kick in.
So, there are a whole lot of additional choices besides the “optimize or do not optimize” dilemma that was originally presented. Some are silly (cutting the feature might or might not fall into that category, for example), some are more or less expensive – rearchitecting might be very expensive, but it might also be the most cost-effective choice, because it enables us to sell twice as much when we have much better performance.
Deciding Between “Pretty Good” Options
Predicting the future is a great topic for another day. But for now, suffice it to say that when you have to decide between a few pretty good options, you have to be prepared for uncertainty regarding which one is the better choice. But if you do have several “pretty good” options, there are even more dimensions on which to consider the decision:
- Is there a way to do both of these “pretty good” options with the same effort or incremental effort?
- Or, is there another option that will get me some or all of the results of these two pretty good options?
- Or, what’s the multiplier effect if I do both of these pretty good options? For example, I may get a positive result of X if I do either, but doing both gives me a positive result of 3X. In that case, perhaps my decision is to make an effort to get funding to do both instead of choosing one or the other, with the benefit of growing my business at a significantly faster rate.
There are so many dimensions that come into making decisions in the real world that it’s amazing anything gets done at all! But the point of this article is to point out the following:
- If you think you have a simple either/or decision, you are probably not only wrong, but you’ll do a lot better in the long run if you consider other options.
- The options that are available for any decision are numerous, and you should consider – at least briefly – a number of different options in addition to your original either/or.
- You can think of this decision as the choice of a point in a space defined by multiple variables, where there are many potential optimums, but where you don’t have a really good objective function.
Let me know in the comments if you have additional thoughts on decision-making in the product management realm. In the future I’ll talk more about performance optimization specifically, since that’s an area where there are a lot more options than simply “optimize the query” or “do nothing.”