9 Prioritization Techniques For Product Managers

The way that we use our time is one of the most important questions we face, in our personal and working lives.

This question is essential to product managers – because the way time and people are organized directly affects the outcomes these teams can provide.

Prioritization techniques help product managers and their teams bring structure to the way work is planned and actioned.

I’ve been fascinated by the various options available to sharpen our focus through prioritization.

In this post we’ll look at 9 prioritization techniques to help you plan work better and make teams happier in the process.

While the focus of these is product teams, these techniques can be adapted to projects, departments or wider business goals.

IMPACT

Impact stands for Interesting, Meaningful, People, Actionable, Clear and Testable.

As Product Plan states, “IMPACT is a mindset for ensuring you’re doing things that matter.”

You can use IMPACT as a rough assessment tool as well as to gauge the dimensions of any opportunity your team plans to work on.

You can also assign a scale to each letter of IMPACT (eg. 1 – 10), to score and rank ideas more rigourosly against this framework.

MoSCoW

MoSCoW stands for Must, Should, Would, Could. This prioritization technique is most useful for specific requirements / features / sub-ideas of a larger theme.

It translates to:

• M – we Must have this to fulfil the requirement / customer need / solution (in other words, “without this fundamental item we cannot launch!”).
• S – we Should have this to fulfil X.
• C – we Could have this to fulfil X.
• W – we Would (in a perfect world) have this to fulfil X.

I have used MoSCoW at least fifty times across various products and projects. It is quick, well-known, and effective, at least for a first-cut of priorities.

Once teams have classified features against MoSCoW, the attention focuses on the Musts and Shoulds. Often the Coulds and Woulds are ‘nice to have’ and are addressed in future releases.

Value / Effort

Value and Effort product prioritization is a powerful tool to bring focus to what matters most.

Value can be a combination of what is valuable to the business (new revenue, repeat revenue, new customers, increased engagement) and Effort is comprised of what draws on a team’s time (complexity of feature, resources required to work on the solution, ambiguity of the problem).

With value / effort, ideas are ranked against these two dimensions (out of either a 5 or 10 point scale).

The tool is most useful when results are then plotted against four quadrants (1. time sinks, 2, big projects, 3, quick wins, 4. fill ins) as shown in this post from Jexo on the Value vs Effort method.

Product Tree

The Product Tree allows product teams to engage in product and strategy planning in a fun and engaging way.

Using the metaphor of a tree – teams group, prioritize and sequence product features based on the tree’s trunk, branches, roots and leaves.

In this model, the branches represent core functionalities, roots are technical requirements and capabilities, and branches and sub-branches are feature themes and ideas.

The tree can be used as the primary metaphor for this exercise; Miro has a great template for Product Tree planning. Or, it can be used more loosely, allowing the tree to be more like a fish bone diagram.

One of the best examples I’ve seen of this techniques is the Product Tree from Up Banking, which is a highly useful example as it’s published online.

RICE

RICE stands for Reach, Impact, Confidence and Effort for any idea on the pipeline.

As an example:

• Reach – how many customers will this idea/feature reach and over which time period?
• Impact – how much impact will this idea/feature have on a specific and important metric? Here, the metric could be measures like “uplift in conversion as part of the acquisition funnel”, “increase in customer engagement with the mobile app,” or “reduction in customer churn for online customers.” Again, often impact against the chosen metric is scored against a 5 or 10 point scale.
• Confidence – this is the level of confidence we have on the idea/feature’s ability to provide the outcomes (usually of Reach and Impact) when it is delivered. This lens helps us guard against unrealistic or overoptimistic expectations.
• Effort – Effort is based on the total project time an idea / feature will take to release, based on “person months.” A person month is the effort expended by one person in a month. So, if an idea / feature takes a week of planning, two weeks of design and five weeks of engineering / development / testing time, it would score 2.

Once we have these variables for each idea / feature, we multiply the first three (Reach x Impact x Confidence) and divide by the fourth (Effort).

The output of this provides each idea / feature’s RICE score, which is a proxy for total impact against total effort.

Those items with the highest score should be those that have greatest impact.

What is great about the RICE framework is that it includes consideration of ‘confidence’ for outcomes, which is not always present in other prioritization techniques.

Story Mapping

The true value of Story Mapping lies in its focus on jobs/customer needs and also developing a ‘view of entire journey contexts’ before breaking epics and features into releases.

I first learnt about Story Mapping many years ago when attending a course by Jeff Patton on ‘Passionate Product Ownership’.

Of all the methods included in this post, if time is available to populate the Story Map, I would lean on Story Mapping as a preferred tool.

Jeff Patton has very well regarded book on this topic. This post from Digite on story mapping is also highly useful.

Weighted Shortest Job First

WSJF (often pronounced Wiz-Jif) is from the Scaled Agile Framework (SAFe). It can be used to prioritize and sequence epics, features, and capabilities that create maximum economic benefit.

WSJF estimates the Cost of Delay and divides this by the Job Duration (or Size), with the view that those items with the highest score, should be prioritized first, to provide the greatest overall value.

The value of this method is that it brings a higher degree of rigour and process to evaluating items of work. This should support the highest customer and economic value in the quickest timeframe possible.

The downside of this prioritization technique is that it requires a significant degree of process, that teams understand (and are not overwhelmed by) the method, and can take people a while to get into the rhythm of planning releases in this way.

Speed Boat

If WSJF is higher on process, speed boat prioritization is perceived as light, quick and fun.

In Speed boat prioritization, we start with a drawing.

Sketch a speedboat with an anchor, tell the group that the anchor represents all the features that are stopping the boat from going as fast / be as strong as it could, and ask the group to draw and label more anchors that represent features that are preventing the product from being awesome.

Often this visualization of problems / issues / constraints permits teams to provide constructive criticism of a product, in a highly visual and productive way.

Criteria-Based

Sometimes projects and products require wider prioritization lenses than can be provided by the models above.

An example I’ve seen often is when a company has 5 strategic objectives (eg. customer experience, compliance, financial return, platform, etc) and some or all of these would be useful to include in prioritizing product features.

In these cases, criteria-based prioritization can be valuable as the only (or an ancillary) method of prioritization for ideas in the pipeline.

This method involves:

• agreeing on the criteria to be used (ideally 5 – 7);
• determining a scoring system for these criteria (this is where a rubric is highly useful);
• scoring ideas/features against this framework;
• discussing the results to then determine the sequence for these items to be delivered.

This technique is much like the IMPACT technique we started this list with, only here, we are defining the criteria to be used, instead of using the acronym of IMPACT.

The upside of using this approach is that it is highly flexible and can be bespoke, based on the needs of the business.

The downside is that it can take time to reach agreement on the criteria (and the way they’re weighted), but once in place, it is a solid framework.

These are a slice of the many prioritization techniques available to plan and deliver work effectively. Many of these I learnt through my own lessons as a product manager. They are highly useful in combination with a strategy process.

I hope this list helps you. If you have a preferred method, consider letting others know which one it is, by leaving a comment below.