How to prioritise your app roadmap more effectively with RICE

When developing apps, prioritising what to do next can be tough. You've probably got a thousand roadmap items you could run at any time, and most of them are probably good ideas. You might be a tech leader or product director under pressure from stakeholders who all want different things; what do you prioritise?

This article takes a look at RICE - a framework that can help product leaders prioritise more effectively. 

First of all, let's look at the "too much stuff" problem.

The "too much stuff" problem

The other day, I spotted this question on Reddit:

As the product owner for an app, I’m constantly getting feedback and ideas for new features. It’s a challenge to decide what to prioritize while keeping development manageable and user-focused.
How do you handle this in your role? What’s your process for deciding which features to prioritize on the roadmap, and how do you communicate this to your team?

I advised them to try RICE, and that created some interesting discussion. I thought I'd share how we do that and a few tips and tricks from the trenches. We've used RICE at Pocketworks for a while, and it's been a great feature prioritisation framework.

How RICE helps you prioritise

Hundreds of ideas. Multiple stakeholders. Not enough time. Not enough resource. These are the problems that product directors and tech leaders face today.

Modern product managers are expected to listen to multiple channels to find their potential next items. This means potential roadmap items can come from many places.

• Stakeholders across the business
• Helpdesk complaints
• Customer surveys 
• Market research
• Competitor research
• User interviews and qualitative research
• The product team working on the app

To put this in perspective, one product we manage has a roadmap of over 140 items. These ideas have come from all sorts of different places, including helpdesk, doctors, customers, stakeholders, and the product team and more.

There is a lot to prioritise.

So, what is RICE and how can it help?

What is the RICE prioritisation framework?

In short, RICE is a way of prioritising roadmap items. 

Let's say you have ten potential roadmap items to run at. How do you prioritise them? If you're like most, you'll either:

• Pick the items that customers shout the loudest about
• Pick stuff that you feel is likely to be well-received by customers
• Pick stuff that stakeholders shout the loudest about
• Pick stuff that feels affordable.

RICE means doing it differently. You take a bunch of ideas and then look at...

• Reach: how many of our user base will benefit from this feature?
• Impact: For the ones it benefits, how much value will they get out of it?
• Confidence: how confident are we that it's worth building? We use both gut feeling and data-driven approaches to this.
• Effort: how big is it to implement? We use T-shirt sizes.

That's RICE in a nutshell. The nice thing about RICE is that it's helping you prioritise based on different angles.

Now, how do you use it?

How do you use RICE?

When it comes to prioritising your roadmap, you simply discuss RICE for each item you have and give each item a score.

Here's an example:

Roadmap Item:
Allow customers to optionally sync their data from phone to cloud, so they can use the app on different devices, and have a backup of their data at all times.

Reach:  40% (our user reserach tells us about 40% of customers will use this)
Impact: High (prevents data loss, facilitates switching to new phone, much more convenient for families with multiple devices)
Confidence: 60% 
Estimate: Extra Large (it's going to be a lot of work to implement) 

A trick to speed up doing RICE

You might think, "Doing this for every roadmap item will take ages!"

And you're right.

Doing RICE for fifty items can be tiring, so we recommend first doing a sweep based on what's most important to you.

For example, we just look at reach and impact and then worry about the rest once we've narrowed it down.

It turns out that it can be quite hard and "fuzzy" to decide what the impact is for any given item. So, let's take a closer look at different ways to do that.

Using S-RICE to allow for strategic alignment

If you have a product strategy, you'll want your next actions to align with that. A simple way to do that is to do a quick check for this whilst doing RICE. It looks like this: 

• Strategy: Does this item align with the product strategy? 
• Reach: how many of our user base will benefit from this feature?
• Impact: For the ones it benefits, how much value will they get out of it?
• Confidence: how confident are we that it's worth building? We use both gut feelings and data-driven approaches to this.
• Effort: how big is it to implement? We use T-shirt sizes.

It might be obvious, but you also support the business strategy here because your product strategy should align with that.

How to get more value from RICE with OKRs

Someone pointed out to me that the "Strategy" element won't be required if you take the time to define OKRs for your strategy. 

For example, if you're mobile strategy for the next year is to double down on app subscriptions, then you might have some OKRs like this:

Objective 1: Drive up subscriptions via paid acquisition
Key Result: 10,000 new subscribers from paid channels

Objective 2: Drive up subscriptions via organic acquisition
Key Result: 20,000 new subscribers from organic means 

So when you come to do RICE on your potential roadmap items, you assess "Impact" based on how well it will support these OKRs. 

Fixed definition of impact for your product

For some apps, it will make sense to have a fixed definition of impact rather than assessing it against strategy or OKRs.

For example, if you're building enterprise employee productivity tools, you might say that money and risk are the most important elements.  

How much more revenue and profit will this feature generate? How much money will it save in costs or productivity? 

What is the risk to the business if we don't build this feature? One product manager mentioned that they use a scale for that, ranging from "productivity" at the lower end, "churn" in the middle, and "regulatory fines and lawsuits" at the higher end.

You don't have to work this way, but if your product team has a fixed view of what impact is, then you can use that globally rather than basing it on your OKRs or current product strategy.

Do you apply the same weight to all your RICE elements?

Not every business will apply the same weight to all the RICE elements. If your app is an internal one that improves employee productivity, then impact and effort might deserve the heaviest weighting, leaving strategy and reach in 2nd place.

It's useful to figure out what your team thinks the weighting should be.  

Next Steps

• Consider if you want to use fixed impact, base your impact on OKRs, or simply do a strategy check for each item you apply RICE to.
• Consider if some elements of RICE carry more weight than others for your product.
• To move faster, try doing a sweep based on impact or reach first

I hope you found this helpful. Feel free to leave a comment below or connect with me on LinkedIn to discuss further.