Prioritization (with RICE)
Last updated
Last updated
The key responsibility of product is to identify the biggest problems that are stopping the company from succeeding and to prioritize development requests to maximize impact with the available resources of the team.
At (example) company success is measured in participations as they are the best signal for us delivering value to our customers. The number of participations is made up of 6 key factors as described in the growth model:
Introducing RICE
Any feature that we are building should have a direct or indirect effect on increasing participation and scalability of the company. The bigger the effect the more value it brings - this aspect is measured by the Reach, Impact, and Confidence Level of the RICE model. At the same time, we need to consider that we do not have unlimited resources and should always prioritize by “value” for “money” or better “reach & impact at confidence level” for “effort”. This can be summarized in one score, the RICE score, with this formula:
See more details on the website of the inventors of RICE here
Reach
To avoid bias towards features you’d use yourself, estimate how many people each project will affect within a given period. For my team, it’s “how many customers/ coaches will this project impact over a single quarter?”.
Reach is measured in number of people/events per time period. That might be “customers per month”, “sessions offered per quarter” or “participations per month”. As much as possible, use real measurements from product metrics instead of pulling numbers from a hat.
Project 1: 500 customers reach this point in the signup funnel each month, and 30% choose this option. The reach is 500 Ă— 30% Ă— 3 = 450 customers per quarter.
Project 2: Every customer who uses this feature each quarter will see this change. The reach is 2,000 customers per quarter.
Project 3: This change will have a one-time effect on 800 existing customers, with no ongoing effect. The reach is 800 customers per quarter.
Impact
To focus on projects that move the needle on our north star ask the question: How much will this project increase participation when a coach/ customer encounters it? Think about the impact of the feature on one or several key factors of the growth model
Select between:
3 - massive impact
2 - high
1 - medium
0.5 - low
0.25 - minimal
Example:
Project 1: For each customer who sees it, this will have a huge impact. The impact score is 3.
Project 2: This will have a lesser impact for each customer. The impact score is 1.
Project 3: This is somewhere in-between in terms of impact. The impact score is 2.
Confidence
To curb enthusiasm for exciting but ill-defined ideas, factor in your level of confidence about your estimates. If you think a project could have huge impact but don’t have data to back it up, confidence lets you control that.
Select between:
100% - High confidence
80%, - Medium confidence
50% - Low confidence
Examples:
Project 1: We have quantitative metrics for reach, user research for impact, and an engineering estimate for effort. This project gets a 100% confidence score.
Project 2: I have data to support the reach and effort, but I’m unsure about the impact. This project gets an 80% confidence score.
Project 3: The reach and impact may be lower than estimated, and the effort may be higher. This project gets a 50% confidence score.
Effort
Effort is estimated as a number of “person-months” – the work that one team member can do in a month. There are many unknowns here, so keep estimates rough by sticking to whole numbers (or 0.5 for anything well under a month). Unlike the other positive factors, more effort is a bad thing, so it divides the total impact.
Example
Project 1: This will take about a week of planning, 1-2 weeks of design, and 2-4 weeks of engineering time. I’ll give it an effort score of 2 person-months.
Project 2: This project will take several weeks of planning, a significant amount of design time, and at least two months of one engineer’s time. I’ll give it an effort score of 4 person-months.
Project 3: This only requires a week of planning, no new design, and a few weeks of engineering time. I’ll give it an effort score of 1 person-month.
Rule of thumb here: How to roughly estimate as PM & Designer
How to use RICE effectively
We noticed already in the past that the main difficulty in using RICE in our BEAT81 marketplace oriented model is the comparability between coach, customer or infrastructure-related features. In case conflicts arise it makes sense to sort features into themes (e.g. the growth model key factors) and prioritize the themes in general and then use RICE to prioritize initiatives within each theme.
In general, RICE scores shouldn’t be used as a hard and fast rule. There are many reasons why you might work on a project with a lower score first. One project may be a dependency for another project, so it needs to happen first, or another feature might be “table stakes” to sell to certain customers.
Sometimes you might want or need to work on projects “out of order”. And that’s okay! With a scoring system in place, you can clearly identify when you’re making these trade-offs.
A prioritization framework such as RICE will help you make better-informed decisions about what to work on first and defend those decisions to others. Coming up with a RICE oriented argumentation, trying to measure reach by looking at numbers, and evaluate impact by talking to users will help to form better decisions in general.
