How Do You Prioritize What To Build?
14 February 2021 ‧ 9 min read
Prioritization is one of the top challenges product managers are facing. Every product team has vastly more ideas than time to build them, necessitating prioritization. What makes this challenge even harder than the scarcity of resources is the uncertainty around the fundamental characteristics of each potential option to pursue: not only is the effort unclear, but even the likelihood of a positive impact is unknown.
For this reason, there is a lot of discussion how to prioritize product improvement ideas in order to maximize impact and the possibility of success. Many organizations have come up with their own prioritization frameworks (such as ICE, RICE, ROI, or value vs complexity) and spreadsheets they complete in order to prioritize their opportunities.
A lot of these prioritization frameworks have the fundamental flaw that they pretend to be scientifically accurate when they are in fact quite arbitrary. An almost bigger issue is that they assume a singular prioritization process where all opportunities are prioritized against all other opportunities. For instance, RICE prioritization assumes that you have a single set of opportunities that you can each score in terms of their reach, impact, confidence, and effort, rank them based on a combined score, and then pursue the top ranked opportunities.
However, if you indeed looked at everything you could be doing in a prioritization process, you would end up with a near infinite list of things to prioritize. The solution, which isn't often talked about in the context of prioritization, is to think of prioritization as a multi-tiered process in the shape of a pyramid:
Don't get me wrong: I am not suggesting that the layers of this pyramid are a new idea. In fact, I would hope that you have a product vision and strategy in place today, for instance. However, many organizations neither consider all layers of this pyramid as part of the overall prioritization approach, nor do they see all individual layers as prioritization exercises in and of themselves.
Following this pyramid top to bottom allows you to narrow down the possible opportunities step by step from the very big picture to detailed tactical options. It also means that any reprioritization that needs to occur doesn't have to put everything into question.
Let's dive in more deeply and look at the layers of the pyramid one by one. At the tip of the pyramid is the vision and strategy. It seems strange to think about vision and strategy setting as part of the prioritization process, but it should be—not only because obviously the vision and strategy should inform the lower layers of the prioritization pyramid, but also because you are prioritizing as you are setting the vision and strategy. The most important aspect of prioritization at this level is that you are considering multiple options and then saying yes to a few of them but no to the vast majority of options. Obviously, you should only have one vision (or perhaps, one company mission and one product vision)—but picking that vision means saying no to any potential different visions that you could set.
For the strategy, it is even more obvious that prioritization is required. For example, which of the many potential customer segments are you going to pursue? Out of all the potential value propositions, which one are you going to focus on? What aspects of the product will you try to differentiate in (and which ones will you be happy to just build out good enough)? Again, in order to help with the ongoing prioritization at the lower levels, it is incredibly helpful to state not only what the vision and strategy is, but also what it was explicitly decided to not be (for example, not only that you have decided to focus on customer segments A and B, but also that you have decided not to focus on segments C and D). This makes it much easier to understand in day to day decision making that certain ideas were considered but dismissed at the strategic level, so they don't need to constantly be reconsidered on the tactical level.
The next level of the pyramid is that of strategic business goals (or organization goals for non-businesses organizations). These goals, which might for example be set on an annual or quarterly basis, determine the organization's priorities for the given time frame, and set an ambition to be achieved. Obviously, these goals need to be linked to the vision and strategy, but they are on a more operational level: what are the next steps we are going to take on the path to delivering on our vision and strategy?
When prioritization processes fail, it is often at this level. Sometimes, the organization is simply taking on too many goals simultaneously, leading to a lack of focus. The more subtle way to fail is to prioritize a manageable number of goals, but not deprioritize the other potential goals strongly enough. As an example, when I was working at 8fit, there were several quarters where in the quarterly planning sessions we considered focusing on building out partnerships, but then decided not to prioritize it due to the resources that would have been required. However, when during the quarter a potentially lucrative partnership opportunity arose, we always re-opened the discussion, because the prioritization decision was always taken for the prioritized options, not explicitly against the deprioritized ones. Excluding options from the scope is actually the most important outcome of prioritization, not deciding what is in scope.
Once business goals are set, the product team can then prioritize product roadmap themes that will help achieve those business goals. This prioritization involves both deciding which potential themes contribute most to the overall strategy and current business goals, and also which order they should be addressed in. At any given point, you should have an idea for which roadmap themes you are working on now, which ones are planned to be addressed next, which ones are waiting for later, and also which ones you are currently not considering at all. This explicit prioritization and roadmap of themes again helps with continuous reprioritization discussions. Whenever new ideas and opportunities come up, you can see if they would fit into a theme already on the roadmap (or explicitly not on the roadmap). The default response should then be to address these new ideas whenever the respective theme comes up on the roadmap, unless there are strong reasons why the entire roadmap should be reprioritized due to the new opportunity.
For each of the roadmap themes, you should then determine which problem areas to tackle, which is again a prioritization exercise. Prioritizing the problem areas determines the scope of the theme (for the current prioritization period), and can for example be done on a quarterly basis as part of a regular objective-setting process. To make the difference between roadmap themes and problem areas clearer, consider this example: a roadmap theme might be improving new user onboarding. In onboarding, there are several potential problem areas: for example, sign up flows, tutorials and examples, CRM campaigns, the core product experience for new users, etc. Scoping roadmap themes in terms of the problem areas to tackle is part of the handover of the theme from product leadership to the empowered product team. Product leadership and product team decide on the scope of the theme (for a given time frame) and the objectives to be prioritized and deprioritized. The more tactical prioritization decisions within the scope of the theme are then taken by the empowered product team—with feedback and guidance from product leadership, of course, but the point of the empowered product team is that they solve problems, not execute tasks, and are empowered to take their own decisions how to best solve them.
The product team first discovers opportunities (or problems to solve) within the prioritized problem areas of their roadmap theme. They then prioritize the opportunities based on how likely they are to contribute to achieving their objectives that were agreed on in the scoping of the theme. It is important to note that this is the level at which most prioritization frameworks and methodologies work—now you can actually determine how many users have a given problem, how much effort it might roughly be to solve that problem, what the confidence level is that a viable solution can be found, and how much impact that solution might have on overall goals. And of course, collecting information about these factors is a good input into decision making by the product team in terms of which opportunities they will eventually pursue and develop solutions for. In practice, of course, what is much more important is that the product team picks opportunities that they strongly believe in. (Side note: in reality, when prioritization frameworks are used, the assumptions are often tweaked until the outcomes reflect what the person doing the tweaking most believes in anyway). It is also worth noting that even if you did use a prioritization framework at this level, the potential options to pursue have already been severely narrowed down: you are no longer considering all the potential options at the same time, but only potential opportunities for a given roadmap theme, as defined by its scope and problem areas.
The last layer is the most tactical: for each opportunity, the team might develop several different solution ideas ranging from radically different ideas to simply detail decisions for a single solution idea that is being pursued. Again, prioritization processes take place. In this case, they aren't even very formalized—they might just happen in the form of discussions and tradeoff evaluations in front of a computer screen or whiteboard. Sometimes, the team might decide to try different options (for example, in the form of prototype tests), other times, they will just pick a single option. In all cases, though, it is a prioritization decision: saying yes to one or few options, and saying no to all the other options.
Understanding this multi-layered process of direction setting and roadmap development as a cadence of prioritization processes helps progressively narrow down the possible opportunities to pursue. At each step, it is important to be crystal clear not only about what was prioritized but also what was deprioritized. It is always easy for something that wasn't explicitly prioritized to creep back in if it is deemed “important“ or “urgent“, but it's harder to argue that something that has been explicitly deprioritized to be suddenly prioritized again. In other words, don't think of prioritization as saying “X and Y are important”. Think of it as saying “X and Y are more important than A, B, and C”. Then, if suddenly the need to do A is raised, you can ask whether A has suddenly become more important than X and Y. If not, then the prioritization doesn't need to be changed.
The pyramid-based nature of prioritization also makes it clear why prioritizing opportunities by ROI or similar frameworks does not make a lot of sense. At each layer, the options need to be prioritized by how much they are contributing to the priorities set at the layer above. In essence, this means that in the end each solution ladders up to the vision and strategy. ROI alone should never be a criterion, because maximizing ROI is not a valid product strategy—every company wants to maximize ROI, and your product strategy needs to be clear in how you are different to the competition.
Understanding prioritization as a pyramid has several advantages. Firstly, it allows to keep the higher levels of the pyramid stable for a longer time. This means, that periodical prioritization decisions (for example, during annual or quarterly planning) don't have to consider all the potential options that could be prioritized, but they can already rely on the ones that were prioritized in the higher layers. The top-most layers of the pyramid impact everyone in the organization, which is why it is important that prioritization decisions on these layers are stable and can be relied on. Vision and strategic priorities, for example, should ideally be stable in the time frame of years. In contrast, priorities on the lower layers of opportunities and solutions might change daily as the team discovers more about their problem area, but the scope of reprioritization changes is limited to the team itself.
The second advantage of the prioritization pyramid is that it also provides a frame of reference for ongoing reprioritization as new problems or opportunities arise. An annual or quarterly planning process can never account for everything that might happen during the planned time, and new options will be discovered that will trigger questions about the priorities. If you have your priorities organized in a pyramid, you can ask at what level of the pyramid that new opportunity would fit in and to what extent there is a case to be made for reprioritization (and, conversely, what you would need to deprioritize at that level in the stack to pursue that new opportunity). This makes it easy to see if an idea that might be described as “just a small thing to squeeze in” would, in fact, run counter to prioritization decisions at the highest levels of the pyramid (and should therefore be avoided).
To wrap up, let me just add two additional small thoughts to make this prioritization pyramid work in product development reality. Firstly, it makes sense to combine this prioritization pyramid with a separate prioritization mechanism for bugs and other small tasks. There are several ways to balance capacity to work on these small items vs. the meaty, strategic work—you can dedicate team capacity or even set up dedicated teams to handle these items, or simply fit them in on a best effort basis. The challenge, if you try to fit these items in with the prioritization pyramid, is that fixing individual bugs will rarely ladder up to achieving any strategic goals, but an accumulation of small bugs can easily make the product suck and therefore stand in the way of achieving the strategic goals. The same is true for small tasks to help other teams. If the marketing team is asking for a specific event to be tracked on a landing page, and an engineer can do that in a couple of hours, there shouldn't be a need to evaluate reprioritizations up and down the pyramid. The key here is to really keep these tasks small and the capacity to work on them limited.
The second point is that it is important to understand that prioritization and sequencing are not the same. You won't always work on things in the order of their priority. That is because sequencing should take into account not also overall priority, but also things like dependencies, resource utilization and availability, the need for future iteration, the need to mix smaller and larger projects, and balancing between riskier and less risky bets.
I hope you found this article useful. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.