Prioritisation

The goal of prioritisation

We always have more ideas, but never seem to have the resources to execute them. Therefore, it is important (both in private and professional life) to carefully cherry-pick a couple of ideas and go all-in. However, keep in mind: it’s never wrong to pivot.

What are we prioritising?

Depending on the industry you’re in you might be prioritising different things. In my work I prioritise a software backlog, but in my private live I (consciously) prioritise in the way I’m building my house or (unconsciously) the things that intrigue me most. In all of these situations we should ask ourselves: what is the goal that I want to achieve? Without having a clear (and preferably measurable) goal in mind, you cannot prioritise.

If you’re interested in the use of goal-models and how to apply these in requirements engineering, I can highly recommend the article Reasoning About Alternative Requirements Options.

Frameworks

After you’ve defined your goals and what you want to prioritise, you should understand the available frameworks. Note that I didn’t write you should select a framework. I don’t believe there is a one-size-fits-all approach to this. Selecting the right model depends on your personality, way of working, and the context you are prioritising. The UX Collective wrote an article that lists the available prioritisation frameworks and explains the different categories.

Source: UX Collective, How to choose your Product Prioritization Framework

Let me introduce you to two of these frameworks: KANO and RICE. This combination works well for me personally. They are pragmatic, easy to explain, and easy to implement.

RICE

RICE was developed by Intercom and is an abbreviation for:

  • Reach: how many of my users will find this thing useful?
  • Impact: how much impact will this thing have on the metrics we have defined that allow us to reach our vision?
  • Confidence: how confident are we on our estimations for reach, impact, and effort?
  • Effort: how much do we need to invest to get the thing in a state that users will start using it?
Source: Productplan, what is the history of the RICE scoring model?

You should define a range for these variables before you assign values o them. Then, you can easily calculate the RICE score by R * I * C / E.

KANO Model

John Vars applied Maslow’s hierarchy of needs to product development. He came up with three layers:

  1. The foundational layer includes functionality that users are not able to live without.
  2. The value proposition layer makes a user successful or it solves a pain.
  3. The growth layer really excited a user by solving a problem that the user wasn’t even aware of. This should set you apart from other solutions as well.
Source: John Vars, the product hierarchy of needs

The KANO model uses a similar approach: it’s goal is find a balance between things that users are disappointed on if they are missing (threshold attributes) and things that excite users (excitement attributes). When excitement attributes mature their implementation depth grows and they slowly move right, into the performance attributes.

Source: Mindtools, Kano Model Analysis

Practically working with RICE and KANO

RICE results in a number. You can easily capture this in a spreadsheet and sort using the highest number. KANO results in a classification. You can easily create a simple spreadsheet to capture the things you want to prioritise. Assign the value and you get an idea of what should be important to you.

Example of the implementation of the RICE and KANO model in a simple spreadsheet.
Example of the implementation of the RICE and KANO model in a simple spreadsheet.

I recommend that you always interpret the output of the models. Ensure the theoretical prioritisation makes sense in practise.

Implementation and validation

These models require a bit of time to understand and apply. I would suggest to implement them in two steps:

  1. Use them based on experience and a couple of explicit assumptions. This immediately gives you an idea of where you stand.
  2. Once you got the hang of it and found a good way of working, start to validate the assumptions and experience with the users of the thing you are creating. This probably lengthens the prioritisation process. You need to decide if this time is worth it.

Transparency

Taking the time to explain how you came to a decision is just as important as communicating the decision itself. Both RICE and KANO allow you to visually explain how you prioritised the items you are going to work on.