Product Management

The prioritisation pickle.

As Product managers we love problems. We love to find ’em, we love to crush ’em. Ironically, trying to solve problems creates a new problem of knowing what to solve first and in which order. This is an issue that haunts product professionals at every level of seniority. Recently, prioritisation was voted one of the most popular topics of discussion at our Product Leaders Club round table.

A recent survey by ProductPlan of hundreds of Product Managers revealed that over 40% re-prioritise product backlog initiatives on a weekly basis! That’s a lot of time spent on prioritisation.

Source: ProductPlan

I don’t want this to be another blog post clone that spits out five prioritisation techniques like a shopping list. So before I jump into giving you the tools and techniques for prioritisation I prefer, and why they are my favourites, there are a few key points we need to remember:

  1. Be objective, with data to back your decisions as well as subjective, with experience and gut feelings supplementing your findings.
  2. Gather insights from your customers and the teams around you.
  3. Prioritise often and re-visit what you’ve prioritised. Always ask yourself Why? And Why now?
  4. Learn and get better at prioritisation.
  5. Learn to say NO.

On that note, I want to stress Point #5 a little further. There is nothing that will rain on your prioritisation parade faster than those that surround you nagging for things like a child asking for a pony. Don’t give in, learn to say no, but ask why.

Don’t buy into the feature request fallacies – know how to identify them. I’ll go into this into detail in another article but learning to say no means knowing what to say no to. Here are some red flags:

Person: We need this. Now.

Me: Why?


  • Our competitor has built it already.
  • Thousands of people are asking for it.
  • It’s a quick win.
  • We’ll lose customers if we don’t.
  • Etc…

Me: No.

I can’t stress it enough: avoid the fallacies. Ask why – in fact, ask five times – and get to the root cause, the real problem. Once you find it, you’re ready to make a decision whether or not to include it, and its priority.

Prioritisation isn’t something you can jump into lightly without any data to back up your decisions. Ensure that you’ve set up the right framework to collect the data you need to utilise these tools to make informed decisions.

Also note that prioritisation isn’t a one time activity to perform and then forget, it’s an ongoing process. Regardless of the tools and techniques you decide to use, remember to outwardly involve all necessary parties in order to accurately prioritise. Listen to your customers, support team, sales reps, tech/dev teams, and other product representatives and ensure your teams align with your company’s goals, vision and drivers. Ensure these then align with your priorities.

So now… here’s a list of tools and techniques that may help with your prioritisation needs (and three of my favourites/most used):

  1. Weighted Scoring

I’ll start with my go-to technique. Weighted scoring is very handy as its versatile and effective. Knowing how to utilise this system correctly means you can use it anytime and anywhere you need.

Weighted scoring is an objective prioritisation technique. Using a scoring method we allocate points, both objectively and subjectively, to a variety of criteria per item of work in order to rank and prioritise.

The criteria may vary and it is up to you to decide what that is. This could be a variety of objective and subjective items such as: Engagement, Operational Efficiency, Strategic Impact, Increase revenue, Increase acquisition, Add customer value, Frequency of request, etc… However, you can also have  criteria for cost which you can assign negative values to e.g. Time to develop, cost of implementation, Risk etc..

Steps to implement weighted scoring:

  1. Clean up your backlog and ensure its readiness for the exercise.
  2. Identify the group of backlog items relevant for this exercise that require weighting/prioritisation.
  3. Determine and agree with stakeholders on your set of criteria.
  4. Determine and agree with stakeholders on the weighting of each criteria.
  5. Assign a score per product backlog item.
  6. Calculate the prioritisation score by multiplying the score by the weight percentage.

Once complete, you’ll have a standardised platform in which to rank and prioritise your backlog that actually works wonders. There are various platforms out there that will allow you to implement weighted scoring as described above. Some are more simple than others allowing only a score which totals up to a priority total.

I have tried and tested the following three platforms, and even though I prefer Product Board, they all do a great job and serve their purpose for weighted scoring. Don’t forget you can always keep it simple with Excel or Google Sheets to achieve the same result.

Let me know if you have used any others that also work well.

Product Plan:

Product Board:




Other methods could include:

  1. Setting up a spreadsheet with your features and weighted priority formulae.
  2. Using Trello to add and manually calculate weighted scores
  3. Using Jira with the combination of custom fields and workflows.
  1. Kano Model

Thanks to Professor Noriaki Kano, this model is an extremely useful and effective method in measuring the impact your product and any subsequent updates/features may have on customer satisfaction. I’ve used and trained with this method a number of times and swear by it.

The Kano model works on the idea that each customer’s levels of satisfaction, feedback and feelings can be attributed, categorised and prioritised. Through analysing responses to three questions, each feature can be categorised and prioritised.

Let’s start with a diagram, it may not make sense at the beginning but you’ll certainly come back to it for reference and it will begin to make sense.

We start with the five categories:

1. Must-Have/Threshold

As the name suggests, these are the features that users feel have to be there for your product to work. Have a look at the Must-Have line on the graph above. As you can see, these are the features customers expect, but don’t really provide high levels of satisfaction. You would be pretty upset if your bicycle came without wheels, but on the other hand you wouldn’t be overly excited if it did.
Example: Wheels on a bike

2. Performance/Linear

As you can see from the graph, the more functionality/features you add of this category the higher the user satisfaction will be. Generally speaking, as Product Managers we aim to find the right balance here between new features/enhancements and satisfaction when it comes to prioritising work.
Example: A basket to carry items on a bike

3. Excitement/Attraction

We can see on the graph even at the lowest level of functionality, adding these features will generate high levels of satisfaction. When prioritising, it’s important to not completely focus on this category, as tempting as it may be. By pushing out these features/functionality you’ll increase satisfaction, but at the cost of the Must-Have features and Performance features.
Example: A wireless charging system that charges all items in your basket, powered by your bicycle ride home.

4. Indifferent

These are the features or functionality that if provided will have little or no influence on user satisfaction. They simply won’t care if you do it or not.
Example: The type of leather used on the bike seat

5. Reverse

These are the features that take away from user satisfaction as you add more and more functionality.
Example: Another seat so your friend can co-ride with you.

All of your features will fall into one of these categories after you’ve analysed the answers to the following two questions (with an additional optional question):

  1. How would you feel if (the product) included (a particular feature)?
  2. How would you feel if it did not?
  3. (optional) How important is (a particular feature) to you?

For the first two questions you’ll want to provide a set of responses for your users, of which they can pick one, such as:

  • I like it
  • I must have it
  • I don’t mind if it’s there (I don’t care for it)
  • I wouldn’t ask for it, but I don’t mind if its there. (Neutral)
  • I hate it

For Question 3 a response would be a number from 0-10 (0 being ‘not important’ and 10 being ‘very important’)

Now that we have the responses, it’s time to analyse them. Based on the responses to your two questions, you can categorise a feature as per the table above.

E.g. If one user said for a particular feature they would ‘Like it’ if it was included but ‘Live with it’ if its not there, you’ll classify that in the ‘A’ category (Attraction).

Here is the full list:

A – Attraction
O – One Dimensional (Performance/Linear)
M – Must-Have (Threshold)
I – Indifferent
R – Reverse
Q – Questionable (These are the anomalies, perhaps the user didn’t understand the feature or the questions, disregard these)

Once you’ve collected all your answers and categorised your features, the last part is prioritisation. The order of prioritisation is (from highest priority to lowest):

  1. Must-Have/Threshold
  2. Performance/Linear
  3. Excitement/Attraction
  4. Indifferent

Note: Discard the features that fall into Reverse categories and ignore the

Questionable ones until you’ve gathered better feedback.

  1. User Story Mapping + MoSCoW (for MVP)

Kano and Weighted Scoring can be tedious and require some effort to implement. Just as effective is a combination technique between User Story Mapping and MoSCoW as a means of getting to MVP.

Use Story Mapping puts us in the shoes of our customers, helps us identify their interactions with our product and highlight noteable tasks. The journey is broken down into Epics at the high level, tasks below and the user stories to break down the detail.

Once we’ve got our user stories we can prioritise and group them using the MoSCoW technique. MoSCoW sorts stories into four categories:

Must Have – Critical to the success of the product. We must include these stories.

Should Have – Important but not necessary. A delay may be acceptable here while there is a workaround.

Could Have – Desirable but not necessary. These are the stories that may delight your customers, but should only be considered if higher priority stories are complete.

Won’t Have – Absolutely unnecessary, won’t add delight nor value. These can be discarded.

The benefits of the MoSCoW method is its ease of implementation and the understanding of the technique. The downside tends to be in its execution. I often find that unless I (as the Product Manager) drive and manage the execution, a lot of items incorrectly end up in the Must-Have categories.

Once you’ve prioritised the user stories the path to MVP becomes clear. Draw a line under stories that need to be included, for the minimum product to be considered of value to your customers.

In conclusion

So there you have it, prioritisation tools and techniques that I’ve personally tried and tested. If you’d like to discuss further how to set up and use these tools and techniques, please get in touch and I’d be happy to talk about one of my favourite topics! I hope I’ve sliced the prioritisation pickle well enough for you to digest.

Leave a Comment

Your email address will not be published.

You may also like

Read More