Prioritization for Product Managers

Why do we need prioritisation?

If you’ve put the effort into brainstorming new ideas, finding opportunities for improvement, and collecting feedback, you’ll have a solid product roadmap full of good ideas. But the order in which you tackle those ideas and solve problems deserves just as much thought. You need to take the time to prioritize well.

Prioritisation is a difficult problem, but why?

• It’s satisfying to work on pet ideas you’d use yourself, instead of projects with broad reach.
• It’s tempting to focus on clever ideas, instead of projects that directly impact your goals.
• It’s exciting to dive into new ideas, instead of projects that you’re already confident about.
• It’s easy to discount the additional effort that one project will require over another.

This is where a scoring system comes in. A good prioritisation framework can help you consider important factors about a project idea and combine those factors in a rigorous, consistent way.

RICE Score: A simple tool for Prioritisation

RICE is an acronym for the four factors we use to evaluate each project idea: reach, impact, confidence and effort.

Reach

To avoid bias towards features you’d use yourself, estimate how many people each project will affect within a given period.

Reach is measured in number of people/events per time period. That might be “customers per quarter” or “transactions per month”. As much as possible, use real measurements from product metrics instead of pulling numbers from a hat.

Example: 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.

Impact

To focus on projects that move the needle on your goal, estimate the impact on an individual person. Impact is difficult to measure precisely.

So, choose from a multiple-choice scale: 3 for “massive impact”, 2 for “high”, 1 for “medium”, 0.5 for “low”, and finally 0.25 for “minimal”. These numbers get multiplied into the final score to scale it up or down.

Choosing an impact number may seem unscientific. But remember the alternative: a tangled mess of gut feeling.

Example: For each customer who sees it, this will have a huge impact. The impact score is 3.

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.

Confidence is a percentage, and I use another multiple-choice scale to help avoid decision paralysis. 100% is “high confidence”, 80% is “medium”, 50% is “low”. Anything below that is “total moonshot”. Be honest with yourself: how much support do you really have for your estimates?

Example:

1. We have quantitative metrics for reach, user research for impact, and an engineering estimate for effort. This project gets a 100% confidence score.
2. I have data to support the reach and effort, but I’m unsure about the impact. This project gets an 80% confidence score.

Effort

To move quickly and have impact with the least amount of effort, estimate the total amount of time a project will require from all members of your team: product, design, and engineering.

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 I keep my 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.

Example: 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.

How to calculate the RICE score?

Once you’ve estimated these factors, combine them into a single score so you can compare projects at a glance. Here’s the simple formula:

Formula for RICE score

MoSCoW Framework

The MoSCoW method is a technique used in project management to help prioritize requirements or deliverables. It is an acronym derived from the potential prioritization categories into which each requirement can be assigned.

The categories are:

Must Have

1. Requirements labeled as Must Have are critical to the current delivery timeline of the project. If even one Must Have requirement is not included, the project will be considered a failure. These are the top priority requirements.

Should Have

1. Requirements categorised as Should Have are important but not absolutely necessary for delivery in the current timeline.
2. They represent the second priority level. All Should Have requirements should be implemented after the Must Haves if it is possible given constraints like risk, resources, and schedule.

Could Have

1. Could Have requirements are those that are considered desirable but not necessary. These will be included in the project if time and resources permit after the Must Have and Should Have requirements are completed.

Won’t Have

1. Requirements designated as Won’t Have have been identified as the least crucial or least viable for the current project scope and timeline. They are given the lowest priority and will not be implemented for the present delivery, though they may be reconsidered for future releases.

By filtering requirements through these prioritisation categories, the MoSCoW framework provides a rational model for optimal implementation of the most critical requirements within the constraints of a project. It aligns teams and stakeholders on which functionalities are essential versus optional for each delivery cycle.

Of course, these frameworks shouldn’t be used as a hard and fast rule. There are many reasons why you might work on a project with a lower priority or 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.

Do you want to become a Product Manager?

For starters, you can follow me, go through the other stuff I have written, and learn as much as you can from here.

If that isn’t enough or doesn’t help, you can checkout this toolkit I created for beginners like you to get started with PM topics, learn the skills they really need to become PMs and prepare for PM roles.

Get the PM Toolkit

If you want a more personalised learning experience, consider joining our Product Management cohort at Crework — Apply now