Prioritisation in Product Management

Product management involves a lot of tools, techniques and methods that need to be applied to solve a given product or business challenge. One of the main tasks of the product manager is to prioritise the initiatives or features that are requested by the business, marketing, UX, customers or even by the development team. Product managers are responsible to sort out what is the most adequate prioritisation method and to bring answers to the following questions:

• Where do I start?
• Which order will I choose to solve the challenge?
• How can I maximize the value of my product?

Photo by Brett Jordan on Unsplash

Prioritisation methods can help to answer those questions by breaking down complex topics into more tangible ones and to get a direction of what needs to be done first in order to maximize the product value.

The decision about what has higher priority can be based on the following criteria:

• Value — What brings more value to the customer or business?
• Risk — What can bring a higher risk if not early addressed?
• Dependency — Are there any dependencies that need to be addressed earlier?
• Releasability — What can be released first?

The following methods can help you with the prioritisation of a given set of initiatives or features.

Methods for Prioritisation of Initiatives

1. Rocks, Pebbles and Sand

This framework is based on the analogy of trying to fill a jar with rocks, pebbles and sand. If you start by filling the jar with sand and then pebbles, you will not be able to fit the rocks inside the jar. However, you will be able to fill everything in the jar if you start by filling it with rocks, then pebbles and finally with sand.

Cretid: https://www.realestatezebrablog.com/2021/10/07/prioritizing-your-rocks/

In Product Management this framework incentivises to identify and prioritise first initiatives that have a bigger business and customer impact (the rocks), e.g. a brand new feature, then prioritise initiatives that have some impact (the pebbles), e.g. a feature redesign. Finally, minor improvements (the sand), e.g. minor effort tasks with low impact, are prioritised. In this way, resources (the team), which have a fixed size (our jar), are focused on what is most important first.

This framework is suitable to prevent filling all of our priorities with minor improvements while delaying bigger initiatives that may have a stronger impact either on the business or customers.

2. MoSCoW

The MoSCoW prioritisation method aims at prioritising a set of initiatives within a time-boxed project. It is helpful to categorize initiatives into:

• Must-have — All initiatives that the product really needs to have, which are non-negotiable.
• Should-have — Initiatives that are important for the product, but not mandatory to have.
• Could-have — Nice to have initiatives with less impact when left out of the product.
• Won’t-have — Initiatives that are not a priority, at least for now

Credit: https://www.techtarget.com/searchsoftwarequality/definition/MoSCoW-method

The engagement of key stakeholders with the product team is of the utmost importance for the success of this method implementation since a common base understanding is needed for a correct categorisation of the initiatives.

The following questions can help to decide to which category belongs an initiative:

• What can happen if this initiative is not included in the product/release?
• Will the product be usable or valuable without this initiative?
• Will it be legal or safe without it?
• Are there simpler alternatives for this initiative?

3. Impact-Effort-Matrix

Usually, more than one possible solution exists for a given challenge. The Impact-Effort-Matrix is a 2×2 matrix that takes into consideration both the impact and the effort criteria. It is helpful to prioritise initiatives and to decide which solutions to follow.

Credit: https://www.flickr.com/photos/davegray/5172059225/in/photostream/

This matrix is intended to be filled jointly in a team session. Each post-it represents an initiative or solution for a given challenge and the team discusses how much impact it can bring and how much effort is involved in the implementation. The result is a four quadrant matrix, where:

• Upper-left: Represents what brings high impact with the lowest effort. These should be the first topics to tackle.
• Upper-right: The topics that provide high impact, however with an high effort involved. The team can further discuss whether the effort is worth the impact it can bring.
• Lower-left: The topics in this quadrant does not bring a rewarding impact, so they should be considered only after having the most rewarding topics implemented.
• Lower-right: This quadrant represents the topics that have a lower impact and a high effort involved. The team should further discuss if it really makes sense to spend effort on it.

4. Value / Risk Matrix

This framework prioritises the initiatives according to their value and risk. It is useful for knowing which initiatives bring more value and how much risk is involved if not addressed.

Credit: https://foldingburritos.com/blog/product-prioritization-techniques/

The team discusses what is the business value of each topic and the associated risk of not implementing it, and places it in the matrix. Examples of risks are:

• Implementation risk: It can cause unmanageable technical debt.
• Assumptions risk: It can put the business at risk if not early addressed.

The result is a four quadrant matrix, where:

• Upper-right: The initiatives that bring high value and have a higher risk if not addressed earlier. These topics should be the first priority.
• Lower-right: High value initiatives that present lower risk. These can be tackled after the ones that bring higher risk.
• Bottom-left: Initiatives that provide lower value and have a lower risk are here. These should only be addressed after higher value initiatives.
• Upper-left: The initiatives in this quadrant should be avoided as they provide a lower value.

Notwithstanding, this framework can have a different configuration if the risk is interpreted as the risk of implementing the initiative. Examples of this type of risk are:

• Risk of changing a core feature of a product.
• Risk of expanding to a specific market.

In this case, top priority initiatives are the ones located in the high-value/low-risk quadrant, corresponding to low-hanging fruits, followed by the high-value/high-risk quadrant.

5. Kano Method

The Kano method is based on questions to identify which features customers expect in the product, those considered indifferent, what would satisfy them and what would surprise them.

The Kano model takes into consideration the customer satisfaction and the feature functionality, which can be translated as the development effort of each feature (can also be translated into resources or, simply, money).

Credit: https://foldingburritos.com/blog/product-prioritization-techniques/

The Kano model provides two questions that need to be applied to each feature under evaluation and to be answered by the customers:

• Functional: How do you feel if you have the feature?
• Dysfunctional: How do you feel if you do not have the feature?

Based on this, each feature can fall into four categories:

• Attractive: An unexpected feature that, if released, causes a positive reaction. It can be considered as a delight for the customers.
• Performance: A type of feature that is characterised by an increase in customer satisfaction with an increase in the involved effort.
• Must-be: Features that customers expect to be in the product. These features really need to be in the product for its viability.
• Indifferent: Features that do not bring additional value are here.

6. Weightest Shortest Job First

The Weightest Shortest Job First (WSJF) is a quantitative method used by the Scaled Agile Framework that aims to produce the maximum economic benefit.

Credit: https://jobling.medium.com/wsjf-in-azure-devops-adbb754876db

This method takes into consideration:

• User-business value: What is the relative value of the feature to the customer or business?
• Time criticality: How does customers or business react to waiting for the feature?
• Risk reduction and/or opportunity enablement: Does this feature reduce the risk of the current or future delivery?
• Job size: A proxy for the estimated duration of the feature implementation.

The WSJF method should be applied to each feature, resulting in a table that can be used for feature comparison and prioritisation definition. The highest WSJF is the next most important feature to be implemented.

Credit: https://www.scaledagileframework.com/wsjf/

7. Cost of Delay

The Cost of Delay method is useful to understand what is the cost of delaying a feature implementation or a release. This method combines urgency and cost and generates insights that the product manager can use to present it to the key stakeholders in order to decide the right priority.

Credit: https://xprocess.blogspot.com/2016/04/cost-of-delay-profiles.html

There are four main patterns:

• Expedite: This represents work that appears unexpectedly and needs to be addressed immediately to mitigate the cost of delay.
• Fixed date: This type relates to work that needs to be done until a certain date, otherwise the cost will not be avoided.
• Standard: This is the most common pattern. There is no urgency on a given implementation; however, the sooner is the implementation the lower the cost is.
• Intangible: This pattern is characterised by work that can be delayed without additional cost; however, needs to be addressed until a certain date to avoid costs.

8. RICE

RICE is a quantitative method that takes into account the Reach, Impact, Confidence and Effort factors.

Credit: https://www.productplan.com/glossary/rice-scoring-model/

• Reach: How many people will be affected by this initiative within a fixed timeframe?
• Impact: How much impact will it cause on each customer? Intercom suggests the following scale for impact measurement: 0.25 (minimum), 0.5 (low), 1 (medium), 2 (high) and 3 (massive).
• Confidence: How confident are we about the other estimates? Confidence is a percentage that represents the level of confidence we have in the data that supports our estimates: 100% (high confidence), 80% (medium) and 50% (low).
• Effort: How much time will the initiative take from all of our resources? It can be estimated in “person-months”.

The RICE score can be calculated as follows:

Credit: https://www.benchmarksixsigma.com/forum/topic/39068-rice-scoring/

The highest the RICE score the most priority should an initiative be.

Summary

There are several frameworks and methods to prioritise a feature or an initiative in a backlog. The decision of which to use should depend on the resources, time and current constraints.

Never forget that behind each decision there are customers, stakeholders and other team members. Convincing everyone about the decisions to be made is not easy; however, adequate data can help to justify the decisions.

I hope that this brief introduction to the most common prioritisation methods will give you a good overview of where to start.

Thanks for reading. I would love to hear your feedback, feel free to drop me a message.

Resources:

• https://medium.com/craft-ventures/the-cadence-how-to-operate-a-saas-startup-436aa8099e8
• https://dragonboat.io/blog/rock-pebbles-and-sand-product-and-portfolio-management/
• https://www.productplan.com/glossary/moscow-prioritization/
• https://www.sixsigmadaily.com/how-to-use-the-impact-effort-matrix/
• https://foldingburritos.com/blog/kano-model/
• https://www.scaledagileframework.com/wsjf/
• https://www.3cs.ch/priority_cost_of_delay_and_kanban/
• https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/