How to prioritize your product roadmap
As a product manager, one of your most important responsibilities is prioritization — you need to give your team a clear view of what to work on next. And since there are always more projects to work on then capacity to do them, you need to reject or deprioritize some ideas: focus is key to success.
But what does this process actually look like? Imagine you’re a Product Manager at a cat grooming marketplace, responsible for growing the supply of new cat groomers. Every time you have an idea, or receive a piece of feedback, you write it down somewhere on a sticky note. The goal of the PM is to take this messy board of potential options and turn it into a neat prioritized list of projects:
While there are tons of techniques you can use to break down these ideas into smaller chunks, then test/validate etc., we’ll leave that out and focus on 4 main prioritization techniques.
Stakeholder Driven Prioritization
a.k.a. what your boss wants
In this approach you simply ask your boss what they want done. Every time they have a new idea, you put it to the top of the stack and deprioritize the rest (alt: do this every time anyone requests something of you). This is very common in smaller, founder-led businesses, or when you’re starting out as a junior PM.
In defense of this strategy, you can say that it ensures the product roadmap aligns with the overall company strategy. It also helps to build a better relationship with the stakeholders by showing that their input is valued. Cynically, it can be good for your career to be currying favour with your boss.
However, it also has significant downsides. You’re basically outsourcing the prioritization question to somebody else, and that someone else may not have an accurate picture of your team’s capacity. You often end up implementing half-baked ideas that aren’t validated by user input or data, or you spend all your team’s time on requests from other stakeholders and don’t actually ship anything meaningful.
User Driven Prioritization
a.k.a what your users want
User-driven prioritization means listening to the needs and wants of the end-users and implementing the most popular ideas. Imagine you send out a survey to all your top cat groomers asking them what the main issues and feature requests are. You group them together, then prioritize by the most popular requests downwards. You can repeat this process for any source of user feedback e.g. customer support issues/app store reviews/social media comments.
This is a somewhat better approach than the previous one, because there is at least some validation of the problem. However, it is important to note that users may not always know what they want. Sometimes, they may request features that are not feasible or are not aligned with the product strategy. In the worst-case scenario you end up building something that everyone asks for but nobody ends up using.
While this can be mitigated to some extent by clever survey design and good UX research (The Mom Test is a fantastic book about this), you still need to exercise some skepticism when asking users directly what they want.
Data Driven Prioritization
a.k.a what the data says
Data-driven prioritization means weighing projects based on quantitative data of their cost/impact. For our example, it could mean analysing the signup funnel to detect where the most significant drops in conversion are, then coming up with projects to improve those steps.
By trying to quantify the impact based on some external business metric, you will make more objective and therefore impactful decisions. It’s a big upgrade on the previous methods because data doesn’t lie to you to make you feel better.
However, it is important to consider the limitations of the data. Data analysis tells you what your users are doing, but not why they are doing it. It’s great for evaluating the success of something already released, but can’t help you prioritize an experimental feature that doesn’t exist yet.
As William Bruce Cameron said:
“Not everything that can be counted counts.
Not everything that counts can be counted.”
Basically, while it is super important to be rigorous in your analysis, don’t fall into the trap of just doing what you can easily measure.
Cost-Benefit Analysis Prioritization
a.k.a. what the business needs
Cost-benefit analysis prioritization means evaluating the potential return on investment (ROI) for each project. This involves looking at the costs associated with implementing a project (such as development time and resources) and the potential benefits (such as increased revenue or user retention). It incorporates elements of all the previous methods, except you try to quantify the size of the benefit/problem solved, the cost and the uncertainty.
A classic way to do this is the RICE method — Reach x Impact x Confidence / Effort.
For each project, you assign a value to each term, multiply them together and use the resulting RICE score to sort the overall list. In our case, we could say Video Onboarding might score an 8 for Reach, 5 for Impact, 3 for Confidence and 6 for effort for a total score of 20. We’d then do this for all the others and see which one had the highest score.
This is the most grown-up method and, done well, can provide a rigorous assessment of each project’s potential. It helps you make semi-objective tradeoffs between different types of projects e.g. maintenance work (high reach, low impact, medium effort) vs risky experiments (low reach, high impact, high uncertainty).
However, in my experience you still end up needing to make a lot of subjective assumptions. The results can feel counter-intuitive or unsatisfying, and it’s easy to fall into the trap of massaging the numbers to favour your pet projects. Effort is always underestimated, in part because there are usually edge-cases, tech debt or switching costs you haven’t considered. Also, if you’re doing this properly it gets harder over time, because you solve all the obvious problems first.
Bonus: True Wisdom™
While the RICE method is best if you have the time and resources, it doesn’t actually contradict the other methods. Rather than sticking to one approach rigorously, I like to think of product prioritization like playing a complex boardgame, where you have an overall strategy but deviate from it if you spot opportunities for small gains.
Ultimately you need to be both flexible and greedy (for product wins). Prioritization work can never be finished — it can only be managed for a time. Don’t get attached to your roadmap, and be ready to discard previous assumptions based on new data.
In summary, there are 4 main prioritization techniques in increasing order of rigour and effectiveness:
- Stakeholder-driven
- User-driven
- Data-driven
- Cost-benefit (RICE)
In the next article, we’ll cover some sneaky product management dark arts to cheat the game — once you know the rules you can break them!
