Product Prioritisation The Easy Way

The Backlog of a Thousand Tasks

The product manager was on a mission to create the most innovative product. He knew that diversity was the key to success, so he hired the best developers, designers, and project managers to work on his vision. He encouraged everyone to contribute ideas, from the developers to the users. The team was happy to oblige, and soon the backlog grew into a giant beast of a thousand tasks.

The product manager was drowning in a sea of tasks, with no easy way to prioritize in sight. He knew he had to act fast to save his project from this perilous situation. He searched high and low for a solution, and finally, he stumbled upon a blog post that promised to help him prioritize his backlog once and for all…

~ AI 2023

Ideas are easy, good ideas are hard

If you want to be a good leader, you should consider everyone's ideas. However, if you have been open to ideas and have given each of them a chance, you may have experienced backlog overflow. It is not uncommon for teams to have hundreds or even thousands of tasks in their backlog.

During our Zump team retreats, we have brain dump sessions where the entire team writes down suggestions, improvements, or whatever they would like to change in the company using post-it notes. Even in a short amount of time (<10 minutes), we can end up with a collection of 50+ tasks to work on.

This blog post explores different prioritization systems based on assumptions and collaborative scoring. If you want to learn about other methods, Rok has already written about them in his post titled "How to Make World-Class Product Decisions."

The Basic Principle Behind Prioritisation

To decide which task to work on, it's important to bring structure to your decision-making process. First, let's ignore task dependencies and preconditions, assuming that all tasks are ready to be worked on right now. As a business, it's important to consider how much money each task will bring, but unfortunately, you can't know that for sure until you execute it. However, you can still get close by prioritizing based on a simple scoring system.

Similar to planning poker, the team can estimate various factors and use an equation to determine which tasks are worth working on. While this method is not bulletproof, it can eliminate a significant amount of work and save $$$.

Simple Scoring: Value / Cost

To make prioritization better and more consistent, you can explore the simplest process by dividing just two factors: value and cost. With these factors, you can quickly score a lot of tasks.

For value, 0 means it won't bring you any closer to your desired goal, while 10 means it will provide all the benefits you can think of.

For cost, 0 means it's free and can be done in a few minutes, while 10 means it will take many months and a lot of resources.

However, since it's fairly ambiguous, it's important to discuss and refine what value and cost mean to you. It's worth noting that money is only used as an example, and there are different factors and examples available for advanced scoring.

I recommend you score the first few tasks with values/cost around ~5, and then go higher or lower comparatively. This way you don't need to spend ages debating what specific numbers mean, because as long as you score them relatively correctly the prioritisation order will be correct as well.

To start, ask relevant team members for their scores. For example ask developers how for time estimation and ask business analyst for a value estimation.

Once you have the scores, just divide average value with average cost and you will get prioritisation score.

Using just these 2 factors you will be able to split your tasks into several different buckets.

Advance Scoring

You can push scoring really far and the nice thing is, once you get used to it, you can do it pretty fast and have tasks well estimated and refined.

So what are some of the other factors you can consider? Let’s build on top of our simple example.

ICE Model

The ICE model uses just 1 more factor than simple Value/Cost model discussed above. It stands for Impact, Confidence, and Effort. Impact is similar to Value and refers to how much the task will benefit the company. Confidence refers to the level of certainty that the task will have the desired impact. Finally, Effort refers to the resources required to complete the task.

RICE Model

The RICE Model is another prioritization framework that builds upon the ICE Model by adding a fourth factor: reach. Reach is a measure of how many people will be affected by the task. By including reach, the RICE Model accounts for the potential impact a task could have on a larger audience, making it a more comprehensive framework for prioritization.

Don’t complicate

It's easy to overcomplicate and add too many factors. The equation below is at the limits and already way too much for most teams I reckon. Keep the number of factors to a minimum, and make sure they can be answered by several people, not just one. This will ensure you can always prioritise tasks in a timely manner.

I'd love to hear about the other factors you use to score your tasks. Feel free to tweet me @OtivDev with your ideas.

Otiv Model

The Otiv Model was developed as a response to the shortcomings of the RICE and ICE models. I felt that these models were only suitable for a limited set of tasks and did not adequately address issues such as bugs and their severity. Additionally, ICEand RICE do not come with a specific set of values or a scale, which can lead to ambiguity. With the Otiv framework, our team tried to eliminate as much ambiguity as possible while keeping the process simple and flexible.

So how is it different from Rice?

• Value is broken down into a set of specific questions

• Urgency is added that works as a “priority override” and can also handle bug severity, legal requests and more

• Comapny's goal/north star is part of the consideration

What to be careful of

• Lack of Consistency: It's crucial to establish clear guidelines and definitions for each factor to ensure everyone is on the same page. Usually the same people should score the same factors, or at least 1 person should be there to “anchor” it to team’s standards.

• Focusing on Precision: Scoring is meant to be a quick and relative estimation technique, not an exact science. Overanalyzing and striving for precise measurements can defeat the purpose and slow down the prioritization process. Meaning you should still trust your gut feeling sometimes.

• Skipping Collaboration: Prioritization using different factors should involve collaboration and input from multiple stakeholders. Making decisions in isolation without seeking diverse perspectives can result in biased prioritization and limited buy-in from the team.

• Using Score as the Sole Criterion: Scoring is just one technique among many for prioritization. Relying solely on scores without considering other factors like dependencies, preconditions, etc… can result in suboptimal prioritization decisions.

• 100% Trusting the Equation: No matter what type of equation you use, you will most certainly not cover all the factors. So if you have a good reason to ignore the score, do it! But let it not become an excuse.

Learn with other developers

I just started a new unique newsletter system for developers. Weekly insights into other dev teams.👇