Setting priorities is an inseparable way to reach the set goals, no matter if we’re talking about work or everyday life. But no worries, we won’t play the life coaches here. What we will be talking about is how to prioritize features during product management, as this is our thing.
Knowing how to prioritize the ideas, features and processes efficiently is the first step in getting more out of a given time and providing the product that is the answer to your customer’s needs. But it often happens to be a nightmare, even for the experienced product manager.
Sometimes it’s a huge number of tasks, and it seems impossible to choose those most important for the product development. In other cases, the product managers are focusing on smart features, instead of those that directly impact the overall goals. Or maybe the desperate need to dive into new features instead of the ones that would have a bigger impact on the product and user experience.
We would be able to go on and on with all the possible reasons, but we will stop here.
And from now on, we will help you understand how to correctly prioritize tasks, features and other elements in the product management process, so it won’t keep you awake at night anymore.
Why you should prioritize features during product management
The base of the successful product implementation is a well-defined strategy, that will guide you like a route from point A to B. But only with established priorities, which are sort of road signs you will reach the destination safe and sound.
The prioritization will help you to:
- Tackle the obstacles easier
- Focus on the main goal
- Save time
- Set the framework
- Save money
- Prevent from getting lost in a high number of tasks
- Avoid confusion
- Remain on track
But how to start? Check the list below – we’ve chosen the most effective methodologies of product prioritization (and believe me, we’ve tried many of them before creating that list).
Prioritization in product management – methodologies
First and foremost – remember, that you can use different methodologies in different projects. Development processes are so various, that it’s impossible to use the same approach in each of them. More options available make you better at adapting, so let’s dive into those 5 different methodologies:
- Kano Model
- MoSCoW method
- Lean Prioritization
Have you ever used any of those methodologies?
Kano Model was developed by Japanese professor Noriako Kano in 1984. Based on customer needs, it aims to reach the highest customer satisfaction.
The core idea behind the Kano model is the linear dependence of customer satisfaction and the level of the feature’s functionality. Features can be classified into four categories:
Also called Linear or One-Dimensional attributes, shown as the proportional relation between functionality and satisfaction. The growth of features determines the satisfaction level. The simplest example can be the speed of the internet connection.
Of course, it sounds amazing, and in the ideal world, we would deploy only features like that. But we have to remember that not only satisfaction level grows here – the investment we have to do, too.
Also called Basic Expectations – features, that are expected by customers, and a product without them is considered as bad or incomplete.
Those solutions are not influencing the satisfaction – customers just won’t be disappointed.
An example here can be as trivial as this: a car should have wheels. Having them won’t make us happy, but a lack of them would make us furious.
Those are the features, that are not expected by the customers, but when present, make them happy. They are also called Exciters or Delighters.
They don’t have to be huge to be in this section. They should make the customer think: “hey, that’s nice”.
A good example here can be a cup that has the ideal size for your expresso. You don’t expect the mug to be exactly like this, but when it is, you feel satisfied.
Features that don’t change anything in the reaction to the product – no matter how much time and effort we spend on it, the customer’s satisfaction won’t change a bit.
Early detecting the indifferent features and deleting them from the backlog save us time and money.
Categories are not static
One thing to remember here, especially if you are working on the second phase of the project or a similar one – the features in categories are changing over time.
The customer’s feelings about the feature will probably change over time. Think about smart TVs. When they reached the market they were amazing, something totally new that brought much satisfaction to the users. And now, they are so popular, that when you’re buying a TV you assume that it will be a smart one.
Get help in building your product from top developers
As we can see, everything in this methodology is based on customer feedback. So how do product teams gain it? Simply – by asking the users.
The questionnaire should cover two questions (asked multiple times, same for each feature):
- Functional question: How would you feel if you have the feature?
- Dysfunctional question: How would you feel if you don’t have the feature?
They should have some options to choose from, like:
- I like it
- I expect it
- I dislike it
- I am neutral
Once you have all the answers, you can start the prioritization process by creating evaluating table. Based on the chosen answers, you can decide on which features are the priorities and which you can get rid of.
Once you choose the main features, you can reach the market earlier with the MVP (Minimum Viable Product) and gain the feedback about the real product.
Check out our video on How to build the MVP.
RICE is an acronym for the four factors helpful in creating the product roadmap and evaluating the priorities: Reach, Impact, Confidence and Effort. It is a scoring system that lets you compare different ideas in a consistent way.
How many times did you choose to work on the feature you thought was best instead of those that became the most useful in customers’ opinion?
I think all the product managers have been there. But we all know that it’s not the best way to create outstanding products and it’s rather time-consuming.
We can avoid that by measuring the possible reach. It’s the number of people/events per time period. That might be “customers per year” or “transactions per quarter”.
The most important thing is using measurements from product metrics that are close to reality.
An example can be a new pop-up showing up on your company page. If the average number of users per quarter on your page is 2000, then the assumed reach is 2000.
This is the impact of the feature on the individual person. It’s difficult to measure precisely, so it’s on you to set the scale. It can be even as simple as: 3 points – huge impact; 2 – big impact; 1 – medium and 0 – no impact.
If we stay with our example – the new pop up on the website, and it presents the outstanding sale, prepared as an eye-catching banner, we can assume that it will have a rather big impact – the score is 2.
This is a percentage indicator that shows the level of certainty in your estimates. If you think that the impact will be huge, but you don’t have any data to back them up, this indicator lets you control the decisions.
Here you also should set the multi-choice scale: 100% is “high confidence”, 80% is “medium”, 50% is “low confidence” and all below that is “uncertain”.
In our example, we have the data about the number of users from previous period. We’ve tried a similar banner before (and it was very impactful), we can assume it’s 100%.
This is the only indicator in the RICE methodology, where the factor increase is a bad thing. It’s an estimated number of ‘person-months’, so the work that can be done by one person in a month.
In our example, we can assume that the sales team will spend a week on establishing the promotion, a designers team a week on creating and amending the banner and the developers will spend two weeks on deployment. So the score here is 1 person-month.
To prioritise the features we have to run the analysis and count the total score for the initial idea. The formula is quite simple:
In our example it will be:
R – 2000
I – 2
C – 100% – 1
E – 1
RICE is (2000*2*1)/1 = 4000
RICE can be used in comparing even totally different projects, as it lets you think about the impact of the idea on the customer and the effort of the team. Once the scoring is in place, you can sort the list and re-evaluate the priorities.
RICE methodology also lets you reconsider the project – is it even worth doing? Maybe spending hours on the idea that will have a rather insignificant impact on the customers (and your earnings) is simply not worth it.
ICE score model is similar to the RICE approach, but the formula is a little simpler.
Like in the RICE formula, ‘I’ goes for impact and ‘C’ for Confidence. But instead of Effort, ‘E’ stands for Ease, so easiness of implementation. It is an estimated effort in combination with required resources.
In this methodology, values are rated on a relative scale of 1-10. You can add the values for those numbers by yourself, just remember to stay consistent.
The key goal of the ICE approach is getting the job done without spending too much time on the product evaluation. The method is quite simple and doesn’t require any deep analysis, so it’s great for urgent or daily tasks prioritization.
MoSCoW is one of the easiest methodologies for requirement prioritization. It was first announced by Dai Clegg in 1994, and lets you categorize the features or ideas (or anything you want) into the following categories:
- Must-have – features that are necessary for the product’s existence, so it will work and look as it should.
- Should have – features with high priority, but not critical to launching. They will be in the second place on your priority list.
- Could have – features that are desirable but not necessary, so the product can be recognized as complete without them.
- Won’t have – features that won’t be implemented in the final version of the product, but can be added in the next releases.
An example here is the structure of the Contact page on your website:
Must have: Address and contact information
Should have: Contact form, so it’s easier to reach you
Could have: Links to your Social Media accounts
Won’t have: Live chat with sales
The MoSCoW approach helps you rank and classify the features or products to get satisfying results. It is based on your team’s expertise, so it’s quick and easy to use.
It’s associated with the classic Eisenhower matrix, but instead of focusing on time and importance, it’s concentrating on Value vs Effort, which makes it more effective for product management.
To start the evaluation, you have to quantify the value and complexity of each feature or idea.
- Value – it can include anything you consider as a value, like lead generation, more traffic or more savings.
- Effort – the overall efforts spend on the feature (like time, cost, risks, technical challenges)
Once you evaluate the ideas considering those two attributes, you put them on the right quadrant in the matrix and discuss them with the team.
Ideas that have high value and require low effort are quick wins. You should execute them to win customers easily.
Those with high value and requiring high effort, are usually big projects that help achieve strategic goals. They should be executed, but only when you are sure you have all the resources to do this. Maybe it’s worth splitting them into smaller projects?
The features with low complexity and low value – they can be done, but are not your priority – that’s for sure. Consider realization later on.
In the last quadrant, we have ideas that require a high effort but won’t bring value to the business. You can skip them right away and don’t spend any more time or resources here.
Those 5 methodologies are the most popular and can be used in different projects, so your toolkit should fullfil all your needs now.
Of course, you can join them, especially in the biggest projects. I.e. start the product evaluation within the team with MoSCoW approach to evaluate the initial idea and once you establish the features ask the customers and use the Kano Model.
We know that sometimes a number of tasks can look horrible, but with the right prioritization, you can limit the losses.
Build your product with top developers