During the holiday break, my daughter made a long list for Santa. It continued to grow and grow until my wife and I warned her she may not get everything on her list. So she astutely decided she should prioritize her list by adding a checkmark to the things she wanted most. That worked well until every item ended up with a checkmark.
So her system developed quickly to add more and more checkmarks to the things she wanted most, making it clear to Santa that the more checkmarks, the more important it was to her.
This worked well, since one item rose to the top with the most checkmarks. Surprisingly, it was a calculator:
After that, a few items had lots of checkmarks, and then others only had a few. She effectively prioritized her (long) list of gifts she wanted from Santa so that the most important were at the top, and then the least important were at the bottom and she was okay if she didn’t get those because she was relatively certain she’d get the most important.
As a product manager and a dad, I felt pretty good about this entire process. She was able to effectively narrow down the most important things, and even come to terms with not getting everything she wanted if it meant she could be more certain of the more important things.
Product Prioritization
It is incredibly easy to get bogged down in the never ending list of things we need to do as product managers and product development teams.
Our lists can get long from customers, sales teams, developers, designers, and other stakeholders.
And then we often go straight to visualization frameworks (RICE, MoSCoW, stacked ranking, Kano, etc) to decide what we are going to work on and what our priorities are. I have always found this questionable at best, and really problematic for many companies and teams.
So what is a better way?
Strategic Framework
To ensure we always have the bigger picture in mind, it is critical we use a strategic framework for prioritization. I wrote about this previously:
The question has come up several times for me recently, though, and I wanted to revisit for my sake and for yours, since this is such a critical part of our work and our lives.
And I’ve made a new graphic, incorporating the same ideas I discussed and helping to make it more visual:
I feel like too often we jump right into the visualization processes and methods, but we need to have the broader context for prioritization as well. The cycle above shows the full process, complete with common frameworks for prioritization—tools like RICE, Kano, etc—but all within a more strategic framework.
So how do we apply this?
Vision/Strategy - First, we need to have the vision and strategy, both at the company level and at the product level. Without the vision and strategy, we can’t appropriately prioritize features within our product, or even stories within our backlogs.
Context - Next, we need to understand the context. This involves market data, company context, user research, etc. Without context, we can’t prioritize either. This is the type of work that we can and should do regularly as part of our research and discovery, but can also do for specific prioritization. It is the background that gives meaning to everything else.
Inputs - Within the broader context, we then need to gather specific inputs, such as quantitative and qualitative data from customers, value to the business, etc. This is where it is we can get specific about the things we need to prioritize. For example, if you have a feature request, you can put quantitative and qualitative data around it. What is the potential ROI? How many support tickets could be reduced? How many customers are requesting? What are they saying about it?
Visualize - Once we’ve gathered the inputs, we can rank, plot, or score our options. When we talk about prioritization, this is where most people (and articles) begin and end. This includes everything from stack ranking to MoSCoW to RICE to every other framework for visualizing your prioritization. You can score your features or items using your inputs, you can plot them, you can rank them, you can vote on them. But if you do it using everything we’ve discussed above, you’ll do it with the right vision, the right context, and the right inputs to make a much more informed judgement.
Decide - Of course, you can’t escape deciding. So this is where you use the information to decide. Data can’t decide for you, but all the work you’ve done to this point can inform you of the most right decision. As a product manager, it will be up to you to decide, though.
Align and Realign - Once you’ve decided, it is time to align everyone around the priorities using your roadmap and other communication tools. Then you continue to align, realign, and adjust based on your vision and strategy. None of this is stagnant or one-and-done, so you’ll be in a continual renegotiation as new information comes to light, as you iterate and learn, or as priorities shift. But you can add new data to what you have, and adjust as you go.
Working on the right thing is one of the most important aspects of product development. It is one of the key roles of product management. So understanding the right framework for getting our priorities correct is critical for all product managers and product teams. We can’t overlook the broader strategic prioritization framework while we’re considering how to prioritize within our products. So don’t miss the forest for the trees, or the strategy for the backlog.