Prioritizing your products and features is the most important skill for every Product Manager at any level of experience.
What to do first? The persistent question
Prioritizing is not only about organizing list of features in a certain order. Product managers also need to take various inputs from different verticals of the organization, juggle between opinions from multiple stakeholders and make trade-offs to make things work smoothly.
What should the team work on next? Which features should stay, which to cut-down? Whose opinion is more important, customer or managers? How many customers, stakeholders, team members to involve in working on the feature?
These are some questions that product managers deal with on a day-to-day basis.
How do Prioritization Techniques help?
We are conditioned to solve well-structured problems from the very start of our education. As a product manager, most problems we encounter are ill-structured. The techniques here provide an organized approach to address these problems.
By defining the metrices or assigning score, these techniques force the stakeholders and the rest of the team to think about the problem space more than the solution space.
Don’t desgin features, solve problems
Action-Priority Matrix
Action-Priority matrix is a very simple tool that helps you focus your energy on what is more important. To use this tool, we score the tasks based on their impact and effort needed to complete them.
How to Score the Tasks?
You can use any scoring technique, like grading system of A (high) to F (low) scores, 1-10 (10 being highest) or any other pattern.
In my personal opinion, scoring for impact of a project should be done in 2^n scale as the impact of projects doesn’t always show a linear scale of growth.
On the other hand, effort required should be measured in terms of Fibonacci series (1-89). In terms of technical implementation, costs involved or execution, it usually is like a domino effect. Any change in complexity at any aspect of effort also increases effort required in other dimensions.
Based on these scores, the tasks are segregated in one of the 4 quadrants as shown in the above diagram.
Quick Wins
These are the tasks/projects which require minimal effort but have a very high impact potential. Ideally, you should focus on such tasks as much as possible.
Major Projects
Major Project is a project that requires significant amount of effort in return of potentially high return.
Fill-in Tasks
These are low-impact tasks which also don’t require any significant effort. If you have bandwidth available, you can do these tasks but otherwise keep them in the backlog for a later date or if their priority changes.
Thankless Jobs
There are some tasks with little to no impact while requiring very high efforts. Avoid engaging in these tasks as much as possible as they will soak up time you should be investing in quick wins and major projects.
How to use Action-Priority Matrix?
Step 1: Make a list of all relevant tasks
Step 2: Score the tasks based on your selected scoring method as discussed above
Step 3: Plot the tasks on the Action-Priority Matrix
Step 4: Prioritize and select your tasks
- Quick Wins get the highest priority
- Focus your remaining time on solving for the Major Projects
- If you have time left, work on the Fill-in Tasks
- Discard anything falling under Thankless Jobs category
Below is a tldr; for Action-Priority Matrix, if you want to reference it or share:
RICE Method
RICE Score is essentially a measure of total impact of a feature per time worked on it. It is an acronym for the four factors that make up the score:
REACH
Reach is an estimation for how many users/customers will be impacted by the feature which is being discussed. You will have to decide on both the context and timeframe for this.
For example, in an e-commerce setup, REACH could be potentially impacted number of transactions per month. A task to streamline the checkout flow to reduce cart abandonment can result into 2,500 new transactions per month.
On the other hand, integrating UPI payment method to optimize payments could result in 500 transactions getting fulfilled per month which were earlier getting cancelled.
IMPACT
Impact defines how each of the individual users which are getting affected by this change going to be impacted.
This could be a difficult metric to calculate as you might not be able to isolate this new project to be the primary change in relation to their improved experience. This is when you have the actual numbers after the execution. Which means that estimating impact before execution is not just difficult, but also a tad bit qualitative.
There is no scientific method for estimating impact, however Intercom recommends using a 5-tier scoring scheme to keep is as quantitative as possible:
- 3 - Massive Impact
- 2 - High Impact
- 1 - Medium Impact
- .5 - Low Impact
- .25 - Minimal Impact
CONFIDENCE
The confidence score brings the qualitative aspect to the prioritisation of a product. As a product manager, you are expected to base all your decisions on data.
However, some projects might be very exciting based on data but ill-defined thus inducing low confidence. On the other hand, another project might not have a very high reach or impact. But if that project is very well defined, you can have high confidence in this project achieving its targets.
The generally adopted confidence scores are:
- 100% - high confidence
- 80% - medium confidence
- 50% - low confidence
If a project has less than 50% confidence, it would be wiser to concentrate your time and efforts on other things that that project. Such projects are called Moonshots.
EFFORT
All factors we have discussed till now discuss the outcomes of a project. Effort deals with the cost of executing the project. Effort is estimated as the number of resources needed to successfully execute a project. It includes product planning, design, development and testing bandwidth. We usually measure it in person-months, that is your effort score.
When to use RICE Scoring Method?
If your team has struggled finding the right balance with other prioritisation techniques, RICE can help you make objective decisions while also incorporating your gut feeling in those decisions. A framework like RICE Scoring would not just help you make more informed decision, but also help you defend them.
Kano Model
Kano model is a theory of product management which prioritises the features based on the likelihood of user satisfaction and cost to implement them. It was developed by Professor Noriaki Kano which classifies projects into 5 categories:
Basic Expectations
These are the basic requirements a user would expect your product to meet. Not having these is a potential deal-breaker in any product. Kano initially named them Must-Be’s and were considered as a price of entry into the market.
Your users would take these features for granted and not talk about it unless it is missing in your product. Turn indicator, headlights of a car would be the most suitable example for this.
These features would never cross above the neutral satisfaction line, but not having them has adverse impact on user satisfaction.
Neutral Satisfaction
Thses are basic features which neither take a lot of development time nor does it impact customer satisfaction. Your customers don’t care about these features. Problem with such tasks is that because they are so easy to implement, they keep building up the complexity in your product. This will in turn impact the maintainance for the product.
In any digital product, 70% of the feature is used by a very niche group of customers and not even noticed by the rest of the users. Most of these could be categorised as Neutral satisfaction tasks.
Performance Features
These are the features that increase customer satisfaction proportionally. Users rely very heavily on these features when deciding which product/service they want to use. Adding more of these features would linearly increase your chances of success by delivering user satisfaction.
An example for this would be additional free storage space with your cloud storage service provider.
Delighters
These features provide an exponential increase in customer delight as you invest in them. Users will not normally expect them to be present, so they won’t miss it even if you don’t have it. Unique innovations are usually a common source of delight features. However, smaller and inexpensive changes can also lead you to great user experience.
A very common example for this will be a well-designed 404 Error Page which tells users what to do next to get back to what they were working on.
You cannot usually get well-designed user feedback on these kind of features because your users also don’t know what they are expecting unless they see/use it. You can find these delighters by evaluating feedbacks and surveys around existing features aligned towards meeting basic expectations or one-dimensional performance expectation of users.
Undesired Features
Apart from the above 4 types of features that you could be working on, undersired features are features which will frustrate your users the more time you spend working on it. You should avoid working on these.
An example for this could be chrome wrapping on hatchback cars. People would want such cars as their daily-drivers to work and back. Having excessive bling would be highly undesirable for them.
When to use KANO Model?
KANO model is very useful for product teams who don’t have a lot of previous data to work with and have limited amount of time. You would want to go out and talk to your customers and try to map your features on one of the first 4 categories.
Once you have identified which features are basic expectations, neutral satisfaction and performance featues, you can align your bandwidth accordingly. You should always discard the undesired features. Based on the customer feedback, you can also prioritise which delighters you should research about and invest time in.
Effect of Time
Now that we understand what KANO is and when to use this method, we also need to know that these categorisations for your tasks won’t be static. The importance of a feature on customer delight decays over time as more and more products adopt these features in their product.
Consider the fluid interface of a touchscreen in a phone back in 2007 when iPhone was launched. Today, it is a basic expectation and a de-facto standard for any mobile device. Similarly, 144Hz screen, which was a WOW factor till last year is now becoming a performance feature for flagship devices.
What this means is that any analysis you do at a given point of time is a snapshot of priorities at that moment of time. You need to carefully re-evaluate these priorities down the line.
MoSCoW Method
MoSCoW is a feature ranking method used to prioritise bandwidth towards what customers feel is more useful. This tool is also useful when you want to communicate to stakeholders what the team is working on currently. MoSCoW is an acronym for the 4 prioritization categories:
Must Have
These are vital tasks without which you shouldn’t launch your product/feature. This may be due to compliance issues, business requirement or customer expectations. Missing out on these could have serious adverse impact.
To see if a task qualifies as a Must Have, try to visualise the worst-case scenario of going live without that feature. If you cannot see yourself succeeding without these features, then they are must haves.
Should Have
Should Haves are tasks that you should include in your product. Even if you don’t, you are not trotting on the road to disaster. An example for this would be an option to re-attempt at getting OTP for logging in to your system.
Could Have
Could Have tasks are those tasks that would be nice to include if you have bandwidth available, but they aren’t a parameter for success. An example could be auto-completing OTP by reading text message recieved by user.
Won’t Have
There are some tasks that are too resource heavy for what impact they have to offer. Project managers often shelve them indefinitely due to lack of bandwidth or ill-defined requirements. Labelling a task as Won’t Have doesn’t necessarily mean that the task in discussion is trash and it will never be included. It just means that THIS is not the time for it.
