RICE Framework in Practice
A Traveller’s Guide — A Step-by-Step Handbook — for Daily Use.
We’ve all been there — “we need a way to understand what to work on next in our Product and Engineering organization, so that we aren’t wasting time, money, and effort.”
So, you circulate this need throughout the org, and you land on the tried and true RICE Framework. You spend a few weeks aligning everyone on what it is, how it works, and you’re ready to begin the process of prioritizing that ever-growing backlog of items that likely have dust and cobwebs caressing their descriptions.
Now what?
There are so many articles, blogs, videos, diagrams, etc. on how to use the RICE framework — how to calculate Reach, what constitutes Impact, formulas, etc .— All of which end with the lovely disclaimer of “find what works for you and feel free to tailor any of this.”
None of this outlines the practice of using RICE on the day-to-day.
This is helpful to get the ball rolling, but what you do with a RICE framework is what makes RICE valuable.
So, I want to give you handbook — to set you up for success — by showing my failures and successes with this on the day-to-day.
Let’s answer the question of “Now what?”
I’f you’re a Product Manager, I believe there are 5 steps that can help you work effectively with RICE.
- Prepare the troops
- Prepare yourself
- Score + prioritize
- Communicate your prioritized list
- Dealing with changes in prioritization
Prepare the troops
(via your messaging tool, e.g., Slack/Teams so there is a paper trail)
Specifically the following people:
Your Engineering Manager, Design Lead, Owner of your success (Director, VP), and your stakeholders who will want to see success.
You’re going to send a message with some bullets (specific to the point bullets, not a novel) to everyone in this group/channel.
Bullet 1: Recap the RICE framework launch and why you are doing it (see the top 2 paragraphs of this article).
Bullet 2: Schedule the official kickoff to launch this prioritization effort at X day and Y time, and send the invite for a later date by EOD (include the Stakeholders and Owners from above as optional). Additionally, set the expectation that this is not a one time meeting, this will be the first of many, until prioritization is “done.” — (I’ll define “done” toward the bottom of this article).
Bullet 3: Layout what to expect in this kickoff call. Try to be as specific as possible for the agenda, items like:
Breaking the backlog into themes respective to your org (e.g., Product Offerings, Channels, Growth, Retention, Operations, Enhancements, etc.), bucket the respective items, trim the fat of what is and is no longer needed — as this list is likely one giant conglomerate of backlog-days-past — define what problem each item is solving, rid the dupes, then, and only then will we start to assign RICE scores that will lead us into prioritization.
Attach a Google Doc: This doc should have the definitions of each letter of RICE and how you will be calculating, so that you can reference it on your kickoff. (the below descriptors are common and can be seen on Intercom’s website)
- Reach = How many customers will this project impact over a single quarter (represented as whole number).
- Impact = How much will this project increase conversion when a customer encounters it? (Massive — 3x, High — 2x, Medium — 1x, Low — 0.5x, Minimal — 0.25x)
- Confidence = How confident are we about the optimistic estimates for reach, impact, and effort? (High — 100%, Medium — 80%, Low — 50%, Moonshot — 20% or less)
- Effort = Estimate the total amount of time a project will require from all members of your team: product, design, and engineering. Estimated as a number of “person-months”, or the work that one team member can do in a month (anything less than a month should be represented as “0.5).”
**Pro-tip —people tend to get hung up on effort scores, and that’s expected — a way to negate this is to keep this lens: The effort score is not saying ‘oh it’s going to take 8 months to do this.’ It’s allowing us to estimate the effort required so that we can prioritize”
Prepare yourself
Great, you sent the message. Now, in the time between your message and the meeting, you’ve got some preparation to do because you want to maximize the output of this meeting.
“Painting a house is 90% prep, and 10% paint” — My Dad
*Pro-tip — There is a difference between working in a vacuum and prepping for team collaboration, so fair-warning, this line can get blurry as a Product Manager. Be careful not to assume too much during preparation.
- Find your backlog items and put them in a single table view (ideally in your product tool and not a Google Sheet, but hey, it’ll work).
- Your table view should have a few key things, in order —
1. Title of Project — with ability to click into for more information
2. RICE Columns — Use preset number drop-downs to avoid ambiguity
3. Final RICE Score — Use a formula for each row (=R*I*C/E).
- That’s it for the necessities, but we’ll get more nuanced later. - Get a user-story and acceptance criteria for every item.
WHAT?!? Yep, this is a requirement to score and prioritize effectively.
WHY? Because engineering cannot give an effort score without understanding what it is they should be expected to build (If I ask you to build a house, you would probably have questions like — how big, how many rooms, bathrooms, down to the minutia of what your house should be, right? Same premise).
This is where I don’t want you working in a vacuum, so ask yourself this question — Am I certain of the anticipated outcome and problem to solve of this project. If the answer is anything less than “YES,” you can place notes for further discussion, but gain alignment from the submitter of the request (if known) and the squad before completing the user story and acceptance criteria so that everyone understands not only the “What” but also the “Why,” (AKA: backlog refinement).
Score + prioritize
You did it — you sent the message, you’ve prepared yourself, now you’re on the kickoff call, and ready to prioritize, right?
Let’s get this out of the way right now — assigning scores is different from prioritizing. Tricky, I know.
Assigning Scores = The Process (yes, capital “P” Process) of defining what the Reach, Impact, Confidence, and Effort of each item is.
Prioritizing = Taking these scores and ranking them so that you know what to work on next.
In this lens, prioritizing is the easy part. The hard part is assigning scores because that takes effort, communication, problem definition, data, and so much more.
As a Product Manager, you may have some sense of what is on your backlog. However, if that backlog has the aforementioned cobwebs, you may need a refresher on quite a few items — and that’s ok, because there’s a very high probability that everyone on your kickoff call has no clue what these things are — and in my experience it would behoove you to assume just that.
So, just as before — let’s lay out the steps here and pretend your meeting started at 10am:
10:00am — Make sure everyone understands why they are here, and that they read the google doc you put so much effort into.
10:01am — Because no one read it, quickly share your screen, and recap the Slack message and the Google Doc.
10:15am — Now that the stragglers have joined the meeting, and you’ve read out the Google Doc + Slack message, it’s time to begin the fun part of assigning scores — and yes, it will feel awkward for the first few .
**Pro-tip — review the backlog before the meeting and find what you would consider an easy one, and move it to the top to raise the spirits of the team before you dive into the monsters buried deep.
10:16am — Click the first project. Read the title and user story out loud. Ask this open question to everyone — “Does everyone understand that problem we are trying to solve with this project?” — and I would encourage you to add a safety net for your notoriously quiet individuals whom you need to chime in today. Something like “It’s ok if you don’t know this project, I’m not going to know them all either, let’s talk about it.”
Once you feel confident that everyone understand the problem to be solved, move on to the next step — scoring.
10:20am — Great! We all understand the problem, let’s identify our “R” in RICE, our Reach. This is where you audibly ask the question to the group, “How many customers do we think this project will reach in a given quarter”
and I must warn you…You may think this is a quick answer…but negative. This question should be met with DATA — you want your forecasted projection of customer reach to be data driven. A good example may be something like this from your design lead:
“Well, today, with X product we only see 150 customers a month, and I bet if we implement this project on it, we would see an uptick of 50 based on the data we have from marketing showing Y folks drop off at point Z…**Pulls up spreadsheet** — and if that’s over the quarter, that’s an uptick of 150 customers in the quarter, and likely need to adjust for launching it mid quarter.” Then attach the sheet to the project!
Then ask if others have conflicting data, other thoughts, etc. if so, talk about it. Identify the source of truth for the data, and use that throughout if possible.
10:30am — Reach number agreed upon at 150. Huzzah!
(We’re actually doing it!)
10:31am — Impact…Oh Impact, so many ways to calculate, but for the purposes of this article, i’m going to keep it simple.
Keeping that same project you clicked on at 10:16am open, ask this question: “how much will this project increase conversion rate when a customer encounters it?”
And we’re not looking for a hard-data number like we had in the Reach section. We’re looking for a selected number between 0.25 and 3.
3 being massive, and 0.25 being minimal.
Have the conversation with your squad. Discuss it openly, why you think this is the impact score. Encourage others to chime in that are being silent, get them engaged.
I personally like the impact number to be based on a combination of data available today and gut-feelings. Squad members may get defensive for higher or lower numbers here, and that’s ok. Just be steadfast in the outcome you are looking for — a number that helps us prioritize — and when you have assigned scores to all the projects, you’ll find you may have scored impact inappropriately compared to others, which allows you to further converse prior to shifting rankings. Let’s say our impact score lands at a medium or “1.”
10:45am — The same project is still open, and we have marked the R, and the I.
**Pro-Tip — Instead of moving on to the Confidence (C)score, jump to the Effort score (How can you assign confidence to your numbers if all the numbers aren’t there yet?)
Now ask the question: “Thinking of this project in the lens of not only engineering, but also design, support, training ramp up, how many person-months to do we think this will take”
10:46am — I hate to break it to you, but you’re going to have repeat what a “person-month” is here. As much as you don’t want to, spend the next 10 minutes making sure everyone knows what it is. It will serve you better in the long run.
I would also encourage you to reiterate that the score assigned to effort does not mean that it will take this long to complete.
11:00am — Now that you have that out of the way, let’s get back down to scoring it. Repeat the above question, and pause to see who answers. I’ve got $10 that says it was an engineer that chimed in. Cool, right.
The engineer says “well, I can only answer based on what we have here in this task/project, so based on that it would likely take a sprint to build out once we were ready to build”
Great! But that’s just a part of the puzzle, what about tech scoping, design, etc.
“Thank you Mr./Ms. Engineer! What do you think design team?”
You get the idea.
From there you take the total of all the teams — and say it was:
2 Weeks of planning, 2 weeks of design time, 2 weeks of tech scoping, and 2 weeks of build with one engineer’s time. I’ll give it an effort score of 2 person-months.
11:15am — YOU DID IT, you got the three hardest letters out of the way. R, I, E. Now time for the easy one, C — Confidence.
**Pro-tip — Use the lens of “how confident are you in the numbers you have placed for R, I, and E, not your confidence in the project.”
If you ball-parked all the numbers with no data, and no conversation, your confidence is low. If you have uber-confidence because it’s only a small update, or your team has all the historical and projected data to-boot, confidence number is high.
So in our example, we talk about it and no one is really uber-confident but think it’s has potential that needs to be validated..we’ll go with a 50% confidence and if it gets more or less confident throughout the Discovery process, we’ll update it accordingly.
11:25am — Confidence score = 50% or 0.5
11:26am — R*I*C/E = 150*1*.5/2 = 37.5
11:27am — Take a moment to celebrate, you actually did it — you have a rice score. Now you only have to repeat this about 87 more times…You can see how this can get time consuming. It took us an hour and a half to get one score on our first kickoff call. However, with time and repetitiveness, it will get faster.
11:28am — I would encourage you to try and get at least one more fully scored on this meeting and then let everyone back to their daily lives.
However, if there isn’t time, that’s fine — be sure to communicate to your stakeholders that this is the process to expect on future meetings and if they would like to join they are welcome to as their voices will directly impact the scores, however, if you have a trusting leadership group, they may opt-out and leave you and your remaining squad to score and priotize on future meetings.
12:00pm — Hopefully you squeezed one more scored project in and you can put the top scored item in position 1, followed by the second item in position 2, and so on.
Now we adjourn the meeting and make sure everyone knows when the next meeting is — not more than a week away, ideally asap.
**Pro-tip — don’t be afraid to push the envelope here with meetings scheduled. No one likes doing this, just like no one likes working out. You have to do this so that you can have a healthy understanding of what to work on next with little ambiguity.
This also serves as your meeting agenda to include in step 1 (Maui voice ~ You’re Welcome ~)
Communicate your prioritized list
Wahoo! You’ve done it, you spent the next few days and weeks scoring and with each score, you ranked them from highest score to lowest, and you have “The List.” All the while, you are still doing your daily tasks as a Product Manager and the meetings have added up, you’re tired, you’ve even considered prioritizing asynchronously, but thought better of it because you’re a team player. I’ve been there too, but you’ll be glad you stuck with your team throughout this journey.
The hard part is over, so-to-speak. Now, we need to take our list and validate it with stakeholders (ideally, they joined the meetings occasionally, and have visibility into what is in the upcoming quarters as you choose what to work on).
So, back to the same slack group from Step 1. Send a message that states the good news of the rankings being in place. Send a link so everyone there can access. Most importantly, make sure everyone understands the implications of this prioritized list. This means that the number one thing you should be working on (based on this score) is at the top of the list, and that should anyone disagree with that, they should speak now. When that item is done, or the appropriate team is assigned, we will take on the second item, and so on.
Reiterate that the purpose of this prioritization is so that we are working on the highest scored items first and that we know what to work on next, so that no one is left in the dark as to what or why we are working on something.
Ask for feedback on the message or for everyone to give the 👍 / 👎 emoji by end of week. If anyone has a “thumbs-down” ask them to articulate their criticism in the slack thread, and if more context is needed to ask for it so that you all can see the feedback. Once everyone gives the “thumbs-up” — it’s time to orient your teams to start working in this way.
**Pro-tip — Don’t break the current sprint or current projects in flight, let those continue unless something was extremely low on the list or it just started. Finish out the sprint, re-align the team, and while that sprint is on-going be preparing your Epics, PRD’s, etc. for the highly ranked items.
Dealing with changes in prioritization
Changes happen, and everyone in your squad, including stakeholders, should find comfort that you can now adapt to changes in priority by asking the question of “does this new project have the perceived impact or reach that it should trump anything in this list?” — Discuss it openly on your daily standups or backlog refinements, and report back in the slack message the results. If someone has a concern of the result, ask them to articulate the reason why. If you have a culture of open and honest feedback, this shouldn’t be a big deal. If you don’t have this culture, accept their one-off meeting invite and try to encourage that open communication on the thread moving forward.
I could continue on this journey with what to do when you get a new item on your list or you complete an item — or the dreaded “we’re shifting focus as an organization” and you’re forced to make sure everything you just did ties to the respective new business goals and re-orient where needed.
Maybe that’s chapter two.
For now, I hope this helps! Let me know what you all think and if you’d like to see more — or if you disagree with my thoughts, I’d love to know how you’ve seen RICE be successful in your squads and organizations.
-Eric
