📢 Sign up to my newsletter and never miss a beat!
Feature prioritization is an essential part of the product manager`s role and the key to building a well-grounded product roadmap, especially in an environment where resources are scarce (in most cases) and you can`t have everything developed at once. It is a process that aims to establish which features and initiatives should take precedence over others based on certain criteria. This criterion depends on the prioritization framework that you choose to implement. The many prioritization frameworks and techniques that are used nowadays across organizations take into account various factors and can apply different methodologies in measuring and weighing individual factors. The common thing between them is that they all strive to assess the value against the cost in one way or another. Apart from the data-driven methods, many companies also use other, alternative approaches that gamify the whole process of feature prioritization and allow you to get valuable insights in a more interactive way. Such is the so-called innovation games. In this article, I will show you how to combine two quite popular methods from both schools of thought to get even better results. The methods we will look at are the infamous RICE (a data-driven approach) and the product tree (a prioritization game).
RICE
The RICE framework is first introduced by Intercom. It is an acronym that stands for Reach, Impact, Confidence and Effort. Generally speaking, it measures what`s the value for the business to develop a certain feature against the cost that it takes, as most of the data-driving prioritization frameworks do. Different methods however have various definitions of value and cost and what factors are taken into account in the respective calculations. In the case of RICE, we can conclude that Reach and Impact reflect the value of a particular feature (or the value for the business), while Effort relates to the cost. What differentiates this technique from the rest, is that it brings the Confidence element into the equation. This is a coefficient measurement that aims to translate how confident we are about the accuracy of our estimations of Reach and Impact. Adding this element is sometimes necessary, as we are not always equally sure of our own assumptions regarding the different features. Let`s take a look at the four elements that make up the framework:
Reach
How many people will be affected by this feature over a particular time period (for example over a quarter, a month)?
Impact
The question you should consider here is “How much will this impact the users”. This can be tied to a certain goal or objective, such as “How much will this feature or improvement affect conversion rates”. In order for the equation to work, this,as any other factor that makes up the equation, should be quantified into a specific numeric value. In order to do so, we need to use a predefined tiered system, where each tier attaches a certain value/points against a given definition of impact. You can figure out your own tiers and point system, but you can also choose to use the Intercom`s original ones that are as follows:
Massive impact = 3
High impact = 2
Medium impact = 1
Low impact = 0.5
Minimal impact = 0.25
Confidence
As mentioned above, the Confidence element intents to convey how confident we are in our assumptions and estimations of Reach and Impact. It is necessary, as in some cases we have more information than in others and thus, can make better judgement on how many customers and to what extend they`ll be affected by a given feature. Whereas, if we know less for sure and base our numbers on a more incomplete information and gut-feeling, we may end up overpricing an initiative that can turn out to be of less impact and then wasting company resources in vain. While it`s expected that our estimations will never be entirely accurate, by factoring in the element of Confidence, we are moving a step closer to the truth. Besides, one would always wager more on what he believes is more probable.
To quantify Confidence, we normally use percentage score, where tiers are grouped in the following way:
High confidence = 100 percent
Medium confidence = 80 percent
Low confidence = 50 percent
Effort
If we look at this framework from the standpoint of value vs cost, the three factors described until now all represent the value side of the equation, while effort is the only cost taken into account when evaluating an initiative. Intercom refers to Effort as the total number of resources needed to complete a task over a period of time. Most of the times, this is normally measured by how many people will be tasked to work on this project per month. For example, if you are allocating a designer, a developer, a project manager, the respective score will be equal to three. There are of course, certain drawbacks regarding how originally this factor is accounted for by Intercom, but you can choose to modify that section of the equation in a way that you believe better suits your case and reality, as far as it is made consistent with the other parts. Remember, you don`t have to thoroughly follow the way Intercom or the others do it. You can simply choose to use them as a guideline and make your own adjustments.
Now that we discussed all of the factors comprising the RICE framework, let`s have a look at the formula for calculating the final RICE score:
(Reach * Impact * Confidence) / Effort = RICE score
As with any other cost-benefit analysis, the final score is calculated by dividing the benefit of developing a feature/product or whatever you are building, by the cost it takes to build it. The higher the score is, the better.
The Product Tree
The product tree is an innovative game that is primarily used for prioritization of features of an already existing product. It`s approach is visual and collaborative and can be implemented both in the case of research session that take place with your end-users, as well as for brainstorm sessions with your team and other stakeholders. By “pruning the product tree”, as often this activity is called, you are shaping your product and its future direction. The method is suitable for planning your next releases and deciding which features to let go by visualizing a tree with multiple branches, each reflecting different functionalities.
For this exercise you`ll need the following:
- A product tree
You can download a template and print it out in a large format, so that you can hang it up for the brainstorm session, or find a template that allow you to work on it in a digital format if you prefer conduct the session that way. Alternatively, draw a tree on a whiteboard and work from there.
- Post-its
Post-its to hang up. Can be leaf-shaped and in different colors if you like to (perfect if green)
- Markers
to write down features
- Seed basket (optional)
To represent features that need to be removed (pruned) from the tree, such that are not approved at all or are not approved for the releases you`re planning out with that game.
The product tree itself consists of the following main elements:
- The trunk
Represents the core functionalities of your product
- Branches
The different categories/ groups of features there are on your product
- Leaves
Leaves represent the different feature developments that you or the other participants have as ideas. These will be placed on the branches, part of the functionality groups they belong to
- Roots
The roots display the technical requirements needed to support your existing and new feature developments. This is an important factor to consider when planning your feature releases, as if the appropriate technology isn`t in place, that can make the development of some potential ideas impossible.
How to play the game and combine both methods?
Let`s have a look at how to make the most out of both methods when prioritizing potential initiatives and product features. For the sake of this example, I will show you how to play the game of Pruning the product tree in the context of brainstorming internally with your company`s stakeholders, rather than organizing discovery sessions with your end users The process I would stick to when combining any data-driven cost-benefit analysis (as RICE is) with the Product tree, would look something like the following:
- Collect all of your feature requests and ideas
2. Draft the RICE scoring of each of your features prior to your group session
Prior to getting together with your team, it`s important to go through your feature list and roughly calculate the approximate RICE score of each feature and idea. Remember, these are only draft calculations that you`ll be able to later polish more, during your group meeting, where you`ll have the chance to discuss each score with the other stakeholders and get a more accurate perspective and estimations.
3. Get your group together
After you`ve comprised your list with potential future feature developments and estimated what RICE score each would hold, it`s time to organize the group session where you`ll have the chance to play the Product tree game, prioritize individual feature ideas accordingly and plan your next releases/sprints. The people to participate in the activity should be the product team working on this product and other employees/management directly involved with the project. It`s best if you have one representative from each department involved. Do not invite more people than needed as you`re running the risk of having an overcrowded and unproductive meeting. Make sure you have everything prepared and in place (check out what basic items you`ll need above) and a couple of hours, perhaps even a whole afternoon, for the session.
4. Place each feature/post-it on the branch it corresponds to and brainstorm for more
Assuming that you have already written down each feature idea along with its approximate RICE score on a post-it prior to your group session, the first step to begin playing the Product tree game with is to arrange the post-its (or the “leaves”) on the corresponding branches.
After you got a picture of all of the collected feature requests and ideas next to the categories they belong to, allow your participants to brainstorm and give more suggestions. It can turn out you`re missing out on something that is worth considering. Invite them to write down their suggestions on post-its, briefly review them together and hang those that you agree are acceptable on the corresponding branches (you`ll assess their RICE scores later). You can keep the ones that didn`t make it in the seed basket or you can decide to just put them aside.
5. Discuss overall branch imbalances if there are such and prune the tree out of certain categories
Now that you have hung the leaves (post-its) on each branch, you have a visual representation of which feature categories are the most popular and wanted among end-users and the other stakeholders who participated in the idea brainstorming. Roughly speaking, these are the areas of functionality you should be investing your resources and efforts the most as they`re likely to be in the highest demand by your customers in the near future. If they don`t find it in your product, they may be switching to a competitor who will start offering it.
You can also spot that some branches are too light in compare to the overall picture, which creates obvious imbalances. This can mean that the functionality works just as expected and fits perfectly with the market requirements, but can also be an indicator that your customers are not aware of it, do not use it or need it enough. The practice shows that in most cases, it is the former. You can`t make suggestions about something you are not using and not aware of its purpose, while the more you are using a functionality, the more ideas and improvement suggestions will pop in your head and the more you`ll seek out of it. This is the perfect chance to discuss the future of these sets of features with the rest of team and, by also taking into account other factors if necessary, decide whether they`re worth having at all and if it is not better to completely “prune them out of the tree“. As the product and the audience evolve over time, it`s normal that some features and functionalities become redundant and no more needed, of course at the expense of other areas. Thus, in order to keep the product user-centric, as well as its user experience seamless and less likely to evoke confusion, it`s sometimes better to eliminate areas of functionality that are no more in demand.
6. Go through each of the branches and review the individual features and rice scores with the team
With your feature ideas already brainstormed, shortlisted, and hung on the product tree, it`s time to review them one by one and groom the RICE scores you calculated by yourself earlier in the process. Go through and discuss each feature individually. Show the other participants how you calculated the features` RICE scores by looking at the individual factors making up the total scores. As you`re probably having other managers and representatives of different teams attending the group session, now is the time to validate your calculations with them and make the respective corrections if needed. You`ll be able to double-check if certain factors are assigned with realistic values with people that can have better insights about a particular area of knowledge, or assign values to factors you did not know how to rate. As an example, you may have struggled to estimate the effort that the development of certain features would take. In such a case, having someone from the engineering team attend the meeting can shed more light on that factor and help you put a plausible value.
7. Re-order the leaves on the branches
The concept behind the Product tree is that those leaves closer to the trunk represent feature requests nearer to being developed and implemented, while those situated on the outer ends of the branches illustrate longer-term plans. By ordering your leaves in such a fashion, you`re, in practice, prioritizing your feature requests and planning for your next releases. The features prioritized for your next release will form the innermost circle that will likely encompass multiple branches.
So, the step that follows right after reviewing and discussing each leaf/feature and the respective RICE score with your participants is to re-order the leaves on the branches accordingly. The things to consider for that purpose are:
- The individual RICE scores
- How clear are the individual feature requirements
- Broadly speaking, the more defined a feature requirement is equirements
- Do we have the technical capabilities for its implementation?
and the higher its RICE score, the closer to the trunk it should be placed. Likewise, the lower its RICE score, or less defined it is (and thus needing more research), the outer on the branch.
8. Review the root system
As already mentioned, the root system represents the infrastructure and the technical requirements needed for supporting current functionalities and the development of the new ones. Thus, it is important not to forget to double-check it and make sure that what you have prioritized and planned for your next release is possible and aligned with it. In case your plans include something that is not supported by your current system, check if your technical team can find a workaround or an alternative that will make its implementation possible (if its RICE score and benefits of having it is high enough and exceed the costs).
9. Reflect decisions on the product roadmap
By now, you have gathered various feature ideas from all kinds of internal and external sources you could use, discussed them with your team, as well as assessed and prioritized them. Once your ideas got shortlisted and ordered by priority, it`s time to incorporate them into your product roadmap, so that you ensure they align with your overall business goals and you can create a clear and comprehensive plan on how and when they can be brought into life.
Want to Explore More on This Topic?
Delve deeper with these curated resources! Discover insightful articles, expert blogs, and top-rated books to enhance your knowledge and skills.
Note: Some links are affiliate links, which means I may earn a small commission if you decide to make a purchase.
“Product Roadmaps Relaunched” by C. Todd Lombardo et al.
A guide to creating flexible, outcome-oriented product roadmaps. It covers the process of developing, managing, and communicating effective roadmaps that adapt to evolving customer needs and company goals. This book highlights using a mix of prioritization techniques, such as RICE and MoSCoW, to help product managers align teams and stakeholders around a shared vision while ensuring each feature or milestone delivers tangible value.
The Ultimate Guide to Product Prioritization + 8 Frameworks: This guide provides a comprehensive overview of various prioritization techniques, including RICE scoring, MoSCoW, and Kano Model. It also discusses how to combine these methods to create a holistic prioritization framework
About the Author:
