3 Prioritization Techniques All Product Managers Should Know
Carlos Gonzalez de Villaumbrosia
CEO at Product School - Global leader in product training
Prioritization and how to do it right remains one of the biggest questions for Product Managers. In our weekly AMA sessions, top Product Managers across the board are asked for how they approach prioritizing features, and how to communicate priorities for stakeholders.
If you’re completely confused about prioritization and how to make it work for you, these are three of the most common and popular methods.
1. The MoSCoW Method
Known as the MoSCoW Prioritization Technique or MoSCoW Analysis, MoSCoW is a method commonly used in Agile PM to understand what’s important and what’s not.
It’s a particularly useful tool for communicating to stakeholders what you’re working on and why.
The name is an acronym of four prioritization categories: Must have, Should have, Could have, and Won’t have.
Let’s take a closer look at what these categories really mean:
Must have
‘Must have’ represents the features that you absolutely should not launch without.
This could be for legal reasons, safety concerns, or business reasons. If it’s something that has been promised to your users and is a huge driver for the buzz around your upcoming release, it would be a terrible idea to launch without it.
To work out if something qualifies as ‘Must have’ think about the worst and best-case scenarios for not including it. If you can’t picture success without it, it’s a Must have!
Should have
‘Should have’ is for things that would be better to include, but you’re not destined for disaster without them.
Could have
‘Could have’ things would be nice to include if you have the resources, but aren’t necessary for success. The line between ‘Could have’ and ‘Should have’ can seem very thin.
To work out what belongs where, think of how each requirement (or lack thereof) will affect customer experience. The lesser the impact, the further down the priority list the requirement goes!
Won’t have
Many seasoned Product Managers have said, “we’ll include it in V2!” When we say ‘Won’t have’ we don’t mean ‘this requirement is trash and it will NEVER be included’, we just mean ‘not this time.’
It could be for a variety of reasons, like a lack of resources or time. In any case, it helps you and your stakeholders agree what won’t make it in your next release, which greatly helps to manage their expectations.
You might also be interested in: How I Created A B2B Customer Lead Prioritization Model
2. RICE Scoring
Another key prioritization methodology is the RICE scoring system, which again has four categories to help assess priority; Reach, Impact, Confidence, and Effort.
Reach
To start, Reach helps us bring the focus back to the customers by thinking about how many people will be impacted by a feature or release. You can measure this in number of people in a certain period of time. So you can ask yourself, “how many customers will this impact per month?”
As with all things in Product, make sure your answers are backed up by data and not just off the top of your head.
Impact
Now that you’ve thought about how many people you’ll reach, it’s time to think about how they’ll be affected as individuals. To do this, think about the goal you’re trying to reach. It could be to delight customers (measured in positive reviews and referrals) or reduce abandonment.
There’s no real scientific method for measuring impact. Intercom recommends a multiple-choice scale:
- 3 = massive impact
- 2 = high impact
- 1 = medium impact
- 0.5 = low impact
- 0.25 = minimal impact
Confidence
So much of Product Management has to be unscientific. Although data should be used as much as possible, sometimes you have no choice but to rely on intuition and gut-feeling.
A confidence percentage will help you with that. You can give your estimates a percentage to boost its priority-level when you’re lacking the data to prove its importance. You can also use it to help de-prioritize things you’d rather not take a risk on.
Generally, anything above 80% is considered a high confidence score, and anything below 50% is pretty much unqualified.
Effort
You’ll need information from everyone involved (designers, engineers, etc) to calculate effort.
In an ideal world, everything would be high-impact/low-effort. Although this is so rarely the case, it’s what we should be aiming for.
Think about the amount of work one team member can do in a month, which will naturally be different across teams. Estimate how much work it’ll take each team member working on the project. The more time allotted to a project, the higher the reach, impact, and confidence will need to be to make it worth the effort.
Calculating a RICE Score
Now you should have four numbers representing each of the 4 categories. To calculate your score, simply add Reach, Impact, and Confidence, then divide by Effort. (Reach*Impact*Confidence/Effort)
Your final score represents ‘total impact per time worked.’ The higher the number, the closer you are to high impact/low effort.
You might also be interested in: How to Use OKRs for Roadmap Prioritization and Planning
3. Kano Model
The Kano model is best represented by a graph:
- Delighters: The features that customers will perceive as going ‘above and beyond’ their expectations. These are the things that will differentiate you from your competition.
- Performance features: Customers respond well to high investments in performance features.
- Basic features: The minimum expected by customers to solve their problems. Without these, the product is basically useless to them.
The main idea behind the Kano model is that if you focus on the features that come under these three brackets, the higher your level of customer satisfaction will be.
To find out how customers value certain features, use questionnaires asking how their experience of your product would change with or without them.
As time goes along, you may find that features that used to be delighters move down closer towards ‘Basic Features’ as technology catches up and customers have come to expect them, so it’s important to reassess periodically.
You might also be interested in: Product Strategy and Prioritization with ServiceNow Group PM
Which Model Should I Use?
Knowing which model to use is tough! The Kano model is useful for making customer-centric decisions and focus on delight, but it can take time to carry out all the questionnaires needed for your insights to be accurate and fair.
Many people like the RICE framework as it takes confidence into account in a qualitative way, but there are still a lot of uncertainties.
MoSCoW focuses on what matters to both customers and stakeholders, which is particularly useful for Product Managers who struggle with managing stakeholder expectations. It’s also the simplest to understand for non-technical stakeholders. However, there’s nothing stopping you from putting too many things into ‘Must have’ and overextending your resources.
Of course, these aren’t the only three methods out there, and many talented PMs have their own ways of doing things. All you can do is test, test, and test again! A Product Management career is long and full of adventures, you’ll have plenty of time to find what works for you.
Check out the Art of Making Impossible Product Decisions by HSBC Senior Digital PM from #ProductCon London 2019:
What prioritization method/framework would you recommend? Leave your comments!
CEO at Product School - Global leader in product training
3 年Here’s a visual summary of this article https://www.dhirubhai.net/posts/villaumbrosia_prioritization-for-product-managers-activity-6783049907965063168-KOLK
Leader, Content Management Systems - Lixil | UX/UI & Digital Design Expert | Founder & Consultant with 25+ Years of Merging Creativity and Business Strategy for Global Brands
4 年Great share.
ML/AI Product Manager @ Capital One | Personalization/Recommendation Engine | ML Infrastructure | ex-Deloitte, Coca-Cola
4 年Hey Carlos González de Villaumbrosia thank you for the article! Shouldn't the x-axis of the Kano model diagram be flipped? If the product doesn't satisfy the "must have" features, the overall product experience must be aggravatingly impacted.
Corporate Innovation / Cloud Computing / INSEAD
4 年Philipp Bouzid Zhanggir Januzakov
Scaling Products | SaaS | Experimentation
4 年These techniques are good to start with but they dont work that well at scale with huge backlog. Would love to know more about techniques which are not based on a defined “framework”