How to prioritise a backlog of features

What are the best ways to prioritise a list of features?

This is the ultimate question for product or project managers, startup founders, indie hackers, technical leaders and product designers. What should I build first? How should I prioritise the features in the backlog?

We’re going to explore:

Impact vs Effort: quick and simple but inaccurate
ICE or RICE: more detailed but open to manipulation
Kano Model: based on customer feedback (jump to this part)

Prioritising your backlog is about making sure the most valuable item is at the top and gets worked on next. That’s the ultimate goal. Ideally your backlog should always be roughly prioritised so you can quickly glance at what’s coming up.

Let’s explore a few ways to prioritise your list of features, starting with something simple and then move on to something more complex.

1. Impact vs Effort

Every item on your backlog will take some amount of effort to complete. And each item will deliver some amount of impact, or value. If you could quantify these two things, you could work on the highest impact, and lowest effort items.

For each item, estimate the effort to get it live. This could be design & engineering effort, sales or marketing, or legal, or whatever it takes to make it happen. Then estimate the impact you’ll see once it’s live. Impact can be thought about as revenue, or improvement in customer experience, or whatever you’re looking for. To keep things comparable though, estimate on a general scale of just “High” and “Low”. If you want more granularity you could use a t-shirt size scale: XS, S, M, L, XL.

Once you’ve estimated the backlog items you can plot them on a 2 dimensional graph, with effort on one axis and impact on the other. You can see in the diagram that the items in the top right quadrant are the highest impact and lowest effort - start with these! Then work your way up the effort axis, always focusing on backlog items that have high impact.

2. ICE or RICE

These two prioritisation models are very similar and operate in the same way. Essentially the idea is to gather a bunch of data about each backlog item, and then combine it with a formula to produce a prioritisation score. Then you sort your backlog by the score to see the prioritisation.

ICE is simpler and doesn’t need as much insight into an existing product. ICE stands for:

Impact: this could be measured in terms of revenue, or a 1-10 scale for impact on customer experience. Maybe if Net Promoter Score (NPS) is a key metric for you, you could estimate the increase you’d get in your NPS score and use that as your Impact value. You can find anything you like but it must be the same for all backlog items.
Confidence: use a percentage (%) to represent your confidence in whether the idea will deliver the impact. 100 for something you’re absolutely sure of, and 0 if you have absolutely no idea whether it will work!
Ease: a simple scale of 1-5 for how simple this will be to achieve. 5 means it will be super easy.

The formula for calculating the ICE prioritisation score is: I x C x E

RICE adds an extra field to increase the accuracy of the scoring model:

Reach: how many people will feel the effect of the backlog item - this could be measured in pageviews or sessions, or number of users. Whatever you choose it must be the same across all backlog items.
Impact: same as ICE
Confidence: same as ICE
Effort: similar to ICE but this is the opposite, measuring how much effort has to go in rather than how easy something is. So think about the overall effort (design, engineering, marketing, etc) and give a high score where it will be a lot of effort. Use a 1-5 scale.

The formula for calculating the RICE scoring model is: (R x I x C) / E

You can extend either of these frameworks with your own criteria. Perhaps you want a column for “strategic alignment”, or “level of innovation”. You can add more in and update the formula to suit.

The risk to watch out for is twiddling the numbers until they say what you want them to. It’s easy to add another column or adjust the formula to create whatever prioritisation you want. So think very carefully about the criteria and once you’ve committed try to stick to it.

3. How to use the Kano model backlog prioritisation framework?

Where the above prioritisation frameworks fall down is that they don’t take customer feedback and opinion into account. They’re almost entirely based on the view of the people inside the company who are working on the product.

The Kano Model is a different and complementary way of prioritising your feature backlog that can be used to replace or augment one of the other approaches.

Kano prioritisation works by asking certain questions to your customers or users of your product. For each of the features you’re interested in prioritising, you ask how they’d feel about having the feature and not having the feature. The results of the survey are processed and each feature is categorised:

Delighter: users love these features, but don’t mind if they’re absent
Performance: the better the feature is implemented, the most users like it
Must-have: the product is not complete without these features
Reverse: these features will spoil the product
Indifferent: users don’t care if the feature is present or not

As you can see the Kano categories are incredibly powerful to help you prioritise your backlog. You know exactly where to focus based on what your customers want, rather than what you’re guessing about things like reach and impact.

Advanced Kano analysis also offers insight into how much each feature is likely to affect overall customer satisfaction (or dissatisfaction) with your product. Learn more about how Kano works for product development.

The Kano questionnaire format is pretty easy, but it can be hard and time consuming to conduct the analysis. Try an interactive widget to see how categorisation works, and try our Kano analysis tool for free.