77: The only article you’ll ever need on prioritization

I’m writing about 100 things I’ve learned the hard way about product management. You can catch up on the previous entries if you like.

When faced with an overwhelming number of things you could be doing, all with good reasons for doing them, it can be tremendously hard to decide which to do, let alone which to do first.

In this article #

• Introduction
• First things first – or not
• Context matters
• Try to avoid bending the rules
• Effect versus effort
• Intercom’s RICE method
• Remember what prioritization is for
• Further reading

Whether you’re looking at your roadmap, sprint backlog, or just your personal to-do list for the day, you can’t do everything simultaneously, nor should you try to. You need a way to decide the order in which you’re going to tackle them, and by the same token, to filter out anything that’s going to distract you from your goal.

Prioritization is all about deciding this as objectively and transparently as you can.

You can use any system you like to assign relative scores to things – it doesn’t have to be complex – and there are plenty to choose from.

Doing things in alphabetical order would be both an objective and transparent prioritization system, albeit an odd one to use.

First things first – or not

“Logical” ordering could play a part, say, if you need to build the ground floor of a house before the upper floors, but you should challenge received wisdom if your users’ needs are pointing you towards an unorthodox solution. Just because other people do things in a particular way doesn’t mean you have to copy them.

I used to live and work very close to the site of what became The Shard in London. Each day over its three-year construction I would walk past and see the tower emerging piece by piece from the building site. In an engineering first for the UK, a method of top-down construction was used, primarily to save construction time. This meant that they were digging downwards to form the foundations of the tower at the same time as they were building the concrete core upwards. Whoever said you have to build things in logical order?

Building and releasing aspects of your product in a completely different order could help to set your product apart – assuming the differentiated order helps to solves a user problem. There’s no point in being obtuse for its own sake.

Context matters

The thing to realise about effective prioritization is that context matters. Whichever system you use to prioritize, it should correspond to whatever your focus is at the time. If your quarterly OKRs (objectives and key results) are geared towards increasing user numbers, your scoring system should result in roadmap items that will help with this ending up higher up the list.

Assuming it does this successfully, you then need stick with your system as long as you have those OKRs, even if one of your (or your boss’s) personal favourites gets deprioritized as a result.

Try to avoid bending the rules

Changing the prioritization criteria should be a deliberate act that says “we need to focus on different goals now”. If you bend the rules too much, or dramatically alter the prioritization criteria, you’ll no longer have a system and chaos will reign (albeit in a very limited way).

Equally try not to fall into the trap of thinking your prioritization system is infallible. The halo effect (a cognitive bias) will lend it unjustified authority. Just because some you’ve multiplied some arbitrarily-chosen numbers in a spreadsheet doesn’t mean it’s any more useful a system than flipping a coin or deciding order alphabetically.

So you still have to assess whether the prioritization system is doing its job. If you’ve been prioritizing roadmap items that are meant increase user numbers and they’re not increasing as a result, then you need to figure out why. Was it the fault of the selection process, the implementation of the roadmap items, or more realistically because what you thought would increase user numbers, didn’t?

Remember, putting a bunch of things to do into a running order has zero effect on the likelihood of the success of those things. Invest more time into user research, experimentation and validation to increase your odds of success.

Whatever the reason, don’t just disregard the results and plough on prioritizing in the same way without at least some reflection.

Effect versus effort

So here’s a quick example of a simple system that scores items based on your best guesses about their anticipated effect on increasing user numbers versus the effort required to build them

It’s pretty subjective as both of the scores are based on guesswork, and it doesn’t mean any of the things you build will necessarily have the desired effect. But at least it helps you to decide more quickly on what to build now, next, later and never in a slightly more informed way than pulling cards out of a hat.

Intercom’s RICE method

Another fairly common system for prioritization is the RICE (Reach, Impact, Confidence, Effort) method popularised by Sean McBride, who was a product manager at Intercom.

Reach might be an estimate of something like the number of customers per quarter affected by the thing you’re building, or transactions per month, but it should be quantifiable and consistent across all the things you’re comparing.

Impact is a subjective measure – a bit like the effect in the previous example. It should be informed by user research. As this will be a multiplier, McBride suggests the following values: minimal (0.25); low (0.5); medium (1); high (2); and massive (3).

Confidence is again a subjective assessment based on the evidence you’ve gathered from your user research, basically a choice of high, medium, or low expressed as 100% / 80% / 50%. Anything below that rarely worth working on – go and do more user research first.

Effort is again a subjective estimate and imprecise, so McBride uses whole person-months (one person working for a month on it), or 0.5 for anything well under a month.

To get your magic number, multiply Reach × Impact × Confidence, then divide by Effort. Bigger scores are better.

Whatever calculation you use, be wary of the temptation to futz around with the numbers in the spreadsheet to get your favourites scoring more highly. At the same time, don’t be a slave to the spreadsheet. If you and your team agree it’s a good idea to do things in a different order for a good reason, that’s absolutely fine.

Remember what prioritization is for

In the end, prioritization is about helping to break the deadlock when you’re deciding which things to do now, next and later, and which not to do at all, in the context of your current set of goals. It can help you to say “no” or “not now” Like any tool or process, it’s there to serve you and make your life easier. Try not to overthink it.

Further reading

“RICE: Simple prioritization for product managers”, Sean McBride, Intercom, 5 January 2018 (retrieved 17 October 2020)

“The Problem with Prioritization Frameworks”, Jens-Fabian Goetzmann, 1 September 2019 (retrieved 17 October 2020)