How to Prioritize Product Features

Prioritization can be a mess in complex business and/or technology ecosystems within organizations. Due to a lack of resources new features for systems demanded by various stakeholders in organiatzion are sometimes overwhelming to manage. The question why the desired feature is still not implemented arises very quickly and has to be answered in one or another way. A transparent and effective prioritization system is at some point inevitable in the context of expectation management.

Severity or Criticality Rating

One common option to prioritize new business features for a product, system or technology is the severity or criticality ranking. It has various levels mostly reaching from "severe" or "critical" to "negligible" or "nice-2-have" on the other side of the scale. The rating is easy to grasp and can easily translated to number ratings (e.g. 1 to 5). The main problem with this type of rating is that it is not considering the estimated time to implement the feature. This means that there is no economic proof that the highest prioritized feature is the most important regarding to a value-effort-ratio.

Value-Effort-Ratio

This one dilemma can easily changed if you add the effort (cost of implementation) to the formula. This means value divided by effort and the resulting score defines the priority. Effort in this case mostly means a rough estimate, e.g. 1 week, 2 weeks, 1 month etc. In most organizations, prioritization work has to accomplished in small time, so rough estimates are favored over time-consuming, precise estimations. Also, if you have a precise estimate by the time of implementation the planned estimate could change easily to a large extent (half the time or double the time). So, why bother with precise estimates that consumes much time. The only issue in this ratio is the value that consists of only one figure. What is "value" exactly? How can I compare it with other requirements? Do I know the value for sure or is it a rough guess?

RICE Rating

In the product management and development field the so-called "RICE" rating has evolved over the last years. The formula is similar to the ratio before, but the value consists of three different parts: R = Reach, I = Impact, C = Confidence. This is summed up and divided by E = Effort. "Reach" defines how many users are affected by the new feature. The more users the higher the "Reach". "Impact" defines how strong is the impact of the new feature. This can be estimated with a scoring system (5 = massive impact, 1 minimal impact). "Confidence" supports you to control how sufficient is the data for "Reach" and/or "Impact". 100% means for example high confidence, 50% only low confidence. Below 50% means that the new feature has no supporting data at all and it would make more sense to prioritize another feature.

RICE Rating & Strategic Dimensions

Imagine you have a full backlog (= prioritized feature list) with lots of features estimated by the RICE rating. The first features are of course the most important ones, but there are for example all in the area of critical bugs or basic features. Innovative features are far away from the top. Also, there are some time-related features (dependencies with other projects) that are not on top of the backlog. In this case if you want to emphasize on innovative or time-related features you have to ignore the prioritization in the backlog.

Strategic planning could be a handy solution. Define for your team, department or organization strategic clusters that are relevant for steering the backlog in the desired direction. Examples for strategic clusters could be:

Of course, first you have to set the strategic agenda for the next development cycle. This means e.g. the four clusters above have to be weighed which one is the most and which one is the least important. For example, you can set the focus for innovation and say we do 40% innovative features, 30% value features, 20% basic features and 10% is reserved for time-related features. This could change before every development cycle. Depending on your situation and the strategic demand of your department or organization it is easy to change. If you use tools like Atlassian Jira it is easy to manage such a strategic backlog and switch or choose between factors to plan the right features for the next development cycle.

Feedback