Prioritization methods for Product Management — Part 1

By Sergey Prihodko, CTO at clevergig.

Choosing what to do and when to do it during the product development process should not be a deeply complex matter. Speak to any product manager and they will have their own special way of guiding product development through the various stages of a build. Having said that I do believe there is a solid way to take the guesswork out of the whole process by using the prioritization methods I have detailed in the article below. For part 1 of this series, I’ll be looking at value, cost and complexity as key variables and then I will go into a brief description of the RICE score model.

So without any further hesitation let’s get into it!

1. Value vs cost

This is one of the most commonly used methods because of its simplicity.

We begin by evaluating tasks by value and cost of implementation. Those with higher coefficients have a higher priority respectively. Generally, you would be looking for a rating where value supersedes cost of implementation. Which, in turn means that a sprint team would focus on the tasks that have the highest value during each sprint first.

Using the graph below you are able to visualise this method. The y-axis represents value and the x-axis represents cost. Priority ranking is indicated by the angle between the x-axis and the straight line’s point of origin and its corresponding end-point. The larger the angle the higher the priority.

2. Value vs complexity

This technique allows you to evaluate each task based on the business value and relative complexity of implementation. This approach is quite common and many teams make an assessment instinctively.

Business value includes everything from income generation and greater savings to greater visibility and traffic. The complexity of implementation varies from time to cost, risk, effort, and technical problems, etc. The principle of this methodology is simple: tasks with the highest value and lowest costs are a priority in a roadmap.

Once again, for a more detailed visualisation, we’ve constructed a graph. The y-axis represents complexity and the x-axis denotes value. We then divide the graph into quadrants. The we Arrange the tasks on the grid by placing them in one of the four quadrants. This allows us to discuss and analyse each quadrant and its respective tasks separately.

• Tasks that have low complexity and high value for the business are of paramount importance.
• Tasks in the upper left quadrant (high complexity/low value) can potentially be removed. However, It is important to review these and see if they hold any value in the future. If they don’t then don’t waste your time on them going forward.
• The tasks in the lower left corner are fairly simple, but they do not really matter to your business. They can be left for future discussions
• The tasks in the upper right corner determine the way forward for the business and will help achieve strategic goals, as such they should be revisited directly after the ‘do first’ tasks

3. The RICE score model

The RICE model is an abbreviation that includes 4 components: Reach, Impact, Confidence and Effort. In accordance with this principle, you need to ask the team the following questions and then prioritize using their answers as your method for evaluation.

Reach. How many users will this functionality affect over a certain period of time? How many users will see the changes? (Estimated over a period of time)

Impact. How will this functionality affect users? Perhaps they will feel the changes or notice significant improvements in everyday use. (Massive = 3x, High = 2x, Medium = 1x, Low = 0.5x, Minimal = 0.25x.)

Confidence. How confident is the team in their assessment? Is there evidence to support their assessment? (High = 100%, Medium = 80%, Low = 50%.)

Effort. What amount of work will the team have to complete for this functionality? This includes development, design, testing, meetings, research, and so on (whole numbers are used)

Once these factors are evaluated, they are combined into one assessment so that they can compare tasks more easliy. Here’s a simple formula:

(Coverage * Effect * Confidence) / Efforts

The higher the score, the higher the priority.

These three methods represent only a few of the prioritization methods available to you when you’re deciding on what to move forward with first. In next week’s article we’ll dive a little deeper into the topic, looking at some more useful and convenient techniques available to product building teams who need to find a data-solid method for prioritizing their projects.

Mario Grunitz

Previous story

Best design programs, apps and plugins for 2018

Next story

Meet Ruslan, our QA bug exterminator