The RICE Method

Episode #5 of the course Product management toolkit by Rich Headley

 

Welcome to lesson five. We previously went over the Hook Model, which helps you think about how to build habit-forming products. Along with the Kano model, value proposition canvas, and your value hypothesis, you most likely have come up with a bunch of features you want to build. Maybe along the way your customers have submitted a bunch of feature requests. Perhaps your boss also just swooped in and dropped an idea bomb on you, or your sales team is telling you that you’ve got to build this thing into your product so they can sell it. One of the hardest, most painful parts of being a Product Manager is that you have to say “no” a lot more than you get to say “yes.” Or, being the motivated and enthusiastic product manager you are, maybe your beautiful mind just won’t stop churning out brilliant ideas.

A helpful way to decide what to do first (and maybe what never to do) is to have a simple, easily explainable, hard-to-argue with prioritization methodology. Today, we’ll go over one of the most universally used and understood methods. It’s called RICE, and it’s part of a balanced PM diet. Just kidding—RICE is an acronym for Reach, Impact, Confidence, and Effort.

Let’s break this down. First, you want to know your feature’s Reach: how many people can it impact? If it helps, you can think of it as a percent of your customer or user base. It’s usually the case that not everyone sees the same value or has the same use case for your product. Even something as simple as pre-slicing freshly baked bread can cause a dramatic rift in your customer base. Some people like the efficiency of having their bread pre-sliced, while other people like to rip off a chunk caveman style. Then, you have the health-conscious people who want thinner-than-normal slices so they don’t blow their daily carb allowance just from their sandwich at lunch. So if you were going to pre-slice your bread, what percent of your customer base would think this is helpful? This is your Reach.

The next part of Rice is Impact. Of the people your feature would reach, what is the relative impact to them? I just used the word relative for a reason. The impact is a very abstract concept, and it’s often difficult to quantify. This is why it may be best for you to use a simple scale from one to five for impact. One means it’s a noticeable impact, and five could mean game-changing value never before seen.

Back to the RICE acronym, we’ve done R and I. I’m going to skip C for a moment and tell you about E, which is Effort. This one’s usually the most straightforward. How long is it going to take, or how expensive is it going to be, to make this feature? Is there any extensive R&D you need to do? Do you have to build a bunch of prototypes before you have a minimally viable product? Is it going to take your entire engineering team six months to build this or can one engineer with a six-pack of mountain dew crush this by the end of the night just for bragging rights?

Now, I skipped C because it’s typically the one you’ll want to think about last. It stands for Confidence. How confident are you in what you’ve come up with for Reach, Impact, and Effort? Depending on your experience in your domain, your knowledge of your customers, and your familiarity with your development team’s abilities, or even the feelings of your engineers themselves in terms of how hard of a problem this is to solve, what is your level of Confidence in the numbers you’ve come up with? I often do this as a percent. For instance, 100% could mean that you are certain of your feature’s reach, impact, and effort, and 50% means you’ve got a good idea but there is a serious possibility that you misjudged something. Anything less than 50% might be something you want to spend more time thinking about before you even bother putting it on your list.

OK, so you have your four RICE numbers for a few feature ideas. Reach, Impact, Confidence, and Effort. How do you make sense of them to arrive at a prioritized list of what you do first? Generally, you want to maximize your effort-to-value ratio. What I mean is that you don’t necessarily just want to do the quickest things first. That’s not putting first things first—just the easiest things first. “First things first” means doing the most value-added things first, based on the amount of relative effort in doing them. So how do you figure that out?

Here goes: You multiply your Reach, Impact, and Confidence scores together, to get an overall business value score. Then, you divide that by your Effort to get a value-to-effort ratio. If two different projects have a similar business value score, but one of them is going to take twice as much effort as the other, then the harder one will have half the score of the easier one. Sort by highest to lowest, and you now have a pretty good starting point for defending your feature prioritization. It’s also sometimes really fascinating to see when features have a relatively smaller reach, impact, or confidence scores but also have super-low effort scores. Those little nuggets may end up higher on your list than big-bang, market-changing features that you’d otherwise think are the best things to do right away, at the expense of all the small things. By the same token, sometimes you’ll see that the big feature you’ve been waiting for a chance to build has such broad reach, high impact, high confidence, and quite a high level of effort, still ends up at the top of the list. Now’s your chance to convince your stakeholders that spending the time to knock that one out is worth ignoring all the little things for a while.

In summary, the RICE method is a great way to prioritize your stuff. A caveat that I’ll end this lesson with is that as you become more experienced, and you develop your product gut over time, you should feel free to use RICE as a guide to point you in the right direction, but still weigh the intangible things that make you believe that maybe the second or third thing on the list is still better to do than the first. You can then check your premises to see if some of your numbers should be adjusted. Just be careful not to go down the slippery slope of confirmation bias and cognitive dissonance in the vain effort to convince yourself and others that it’s best to work on the thing you want to work on when it may not be the right thing to do right now.

So now, you’ve decided on the right feature, but we need to make sure we build the feature right. In our next lesson, we’ll talk about design sprints, a process of design thinking that will help you maximize the value you deliver with your next project.

 

Recommended reading

RICE: Simple prioritization for product managers

 

Share with friends