Navigating Success: The Essential Role of Prioritisation for Product Managers

Product Managers wear many hats. They need a wide knowledge base and great influencing skills to get cross-functional teams aligned behind a product strategy and roadmap.

A lot of the day-to-day work of a PM involves making prioritisation and trade-off decisions. They may involve bigger ticket items, such as product strategy options or which identified customer problems to start working on next, or smaller items such as feature improvements or bug fixes etc. These decisions need to be managed across a variety of internal stakeholders.

The good news is there are several useful frameworks. Like most things in life, there is no “one size fits all”. Also, frameworks can give a false sense of security (“here’s the answer!”). They need to be complemented with an acceptance of the ambiguities and uncertainties that every PM knows exist in the real world. In the words of Mike Tyson – “everyone has a plan until they get punched in the face”.

"The good news is there are several useful frameworks. Like most things in life, there is no one size fits all.”

Joe Coles, Founder @ JC Product Consulting

MoSCoW

MoSCoW is a commonly used method by groups of stakeholders to prioritise projects, initiatives, or tasks. It groups initiatives into one of four categories: “must-have” (essential to success, the top priority), “should-have” (important but not essential, the second priority), “could-have” (nice but not essential, the third priority to consider if they don’t impact the musts or shoulds) or “won’t have” (can be excluded at this time).

MoSCoW is simple to implement and can be used for a wide range of circumstances. It’s particularly useful for prioritising against a time-based development constraint. It also helps cross-functional teams understand the different initiatives from different stakeholder perspectives.

But, it has its limitations. If not backed up with data, the prioritisation can be a subjective and there may be conflicting views in the team about the “must haves”. Also, it does not take into account resource constraints or implementation dependencies.

Impact vs effort prioritisation matrix

Another common and easy to use technique is to estimate the implementation effort (e.g. in days/weeks or in s/m/l/xl T-shirt sizes) and market impact (e.g. $ value or high/medium/low) for each of the initiatives and then map on a simple 2x2 matrix.

Once mapped, the matrix helps the team to decide on the priorities. Initiatives with high impact and low effort are obvious “quick wins” and are the top priority. Those with high impact and high effort are important major projects and should be done next. Depending on the team’s resources and appetite for simultaneous major projects, a number of “small steps” (low effort and low impact) can be prioritised as well. Anything with low impact and high effort should be stopped.

Although, simple to understand and use, bear in mind that the impact vs effort prioritisation matrix is only as good as the underlying estimates for each initiative. There is a tendency to overestimate the market impact and underestimate the effort of things that have not been done yet. Getting things done in reality is messier and more unpredictable than planning them on paper.

RICE scoring

RICE is a scoring system, originally developed by the software team at Intercom, that helps evaluate different initiatives based on four factors:

• Reach – how many customers will be affected by the initiative, typically over a defined time period.
• Impact – the estimated business impact of the initiative on each customer. This may be conceived in terms of adoption, conversion, average revenue etc.
• Confidence – this helps the team factor in uncertainties around the reach and impact estimates for each initiative by defining a confidence rating for each.
• Effort – estimated effort based on person months.

Once all the above factors have been estimated, each initiative can then have a RICE score calculated using the equation (Reach x Impact x Confidence)/(Effort). The RICE scores for the different initiatives can then be used as the basis for prioritisation decisions.

The RICE scoring approach does help the team focus on a data-informed comparison of initiatives and allows relative uncertainties in the estimates to be factored in.

Beyond the frameworks

The frameworks give teams a common basis for prioritization decisions, but there are some other considerations when applying them in practice:

• Ensure good stakeholder involvement to evaluate initiatives from business and technical perspectives, and give transparency on prioritization decisions.
• Understand key dependencies between initiatives, otherwise you risk prioritising initiatives which can’t be done in isolation.
• Understand where the critical constraints are (it may be front-end, back-end, QA etc) and prioritise against that constraint.
• Manage uncertainties by using lean start-up principles to iterate and learn quickly before committing significant resources to an initiative.

There will be times when it is still difficult to decide between initiatives. One technique I have used in the past is to relook at the initiatives from the perspective of “what are their cons” and select based on which “cons” the team are least uncomfortable having to deal with.

Managing prioritisation decisions is a big part of the day-to-day work of a PM. Mastering it is key to surviving, let alone thriving, in product management!