Prioritization for PMs: 5 Hazards
And how you can avoid them.
In my time as a product manager, I’ve encountered and used different approaches to prioritization. I’ve noticed a common set of challenges emerge over and over again. These are the things that make prioritization hard, and my advice for not letting them get in your way.
1. Maximizing customer delight isn’t the only thing that matters.
Negative customer feedback carries a lot of weight, and can be emotionally painful to hear. We PMs want our customers to love our products. But, while maximizing customer delight is important, it’s not the only thing that matters. We need to be dedicated to maximizing the value our product yields to our broader business.
Your users and your business are, in most cases, two different stakeholders, each with different interests. Your customers probably don’t care about your internally-facing projects to reduce costs, free-up resources, or tackle technical debt. But these types of initiatives may contribute immensely to broader business objectives. On the other hand, failing to regularly deliver meaningful customer-facing product enhancements can end up driving your customers away. Finding the right balance is key, and can be solved for via a prioritization scoring framework that accounts for both factors.
2. Prioritization is a never ending activity. ♻️
Dusting off and revisiting your priority list periodically, as opposed to making prioritization a continuous activity, is one way to ensure things go completely off the rails with your product. As a PM, you need to maintain a constant state of alignment between you and your engineering counterparts. If not, engineers will make decisions about what to work on without you (and these will probably be bad decisions). The best way to do this is by having regular prioritization discussions, always knowing what developers are working on now, and what they’ll be working on next. (Note: making sure that developers know what they’re working on next, and why, is also generally good practice)
Most importantly, priorities can and will change. What was once a high priority may not be anymore. Knowing when to stop working on something mid-flight is possibly more important than knowing when to start, which leads us to…
3. Sunk costs.
The sunk cost logical fallacy is when we justify the continuation of an endeavor based upon the level of investment we’ve previously made into it.
When it comes to building products, this is the misconception that we should continue working on a project because doing otherwise will mean our prior investment (e.g. engineering effort spent) will have all been a waste.
While it may be painful to walk away from an in-flight project the team has spent a lot of time on, we must always consider the opportunity cost associated with not working on other, potentially more valuable things instead. We should all be using a prioritization scoring framework that incorporates level of effort (specifically, remaining LOE) as a factor.
4. Gut feelings.
Humans are, by nature, not totally rational or objective. Not only do we tend to draw our positions based on our initial gut feelings, but we then selectively search for data that backs these positions up. So, is it a problem that PMs are relying on our gut feelings to make prioritization decisions most of the time?
Should outright avoiding gut feelings be the goal? Not exactly. HBS professor, Laura Huang, discusses how we should interface with our gut feelings in her recent HBR article, When It’s Ok to Trust Your Gut on a Big Decision. We should be aware of these underlying forces at play, and do our best to remain objective and open to new information, as our own experiences may be limited. But, when used responsibly, gut feelings can help us make decisions quickly, when we may not have access to complete, codified datasets.
5. We like shiny, new ideas — versus what we’re familiar with and confident in.
True innovation often leads us to the biggest rewards, but carries a higher degree of risk and uncertainty. It may be tempting to focus on these types of initiatives, as they are more exciting, versus the “low hanging fruit” — i.e. the smaller stuff we’re confident we can build within a reasonable timeframe. Prioritizing these two different types of projects relative to one another isn’t easy. Leveraging a “confidence” factor within your prioritization scoring framework can be a good way to account for this.
In summary, product/feature prioritization needs to be approached as an ongoing, continuous activity, along with a scoring framework that considers both business and user value, LOE and confidence. We should be aware of our biases, but not avoid them completely. Prioritization is an important piece of product management, that can be enjoyable and rewarding when done right.