Prioritization
Whether creating a roadmap or deciding what items you should work on during the week, it is important for a product manager to be familiar with methodologies for prioritizing feature requests.
Some prioritization frameworks (such as the ROI Scorecard and the Cost of Delay) allow you to estimate the value to the organization of delivering some features. Knowing the value of each item in the product backlog, you can then prioritize those items which add the most value.
The MoSCoW model is a model that allows stakeholders to specify which backlog items are “must-have”, “should-have,” and “could-have”.
The Kano model is a model that allows you to understand and define each feature as "must haves" or "delighters." It also allows for a balanced mix of features that are required to do the job and some that are unexpected features that help the product stand out from the competition.
Product Discovery Trees allow you to examine a group of solutions that tackle a particular problem or opportunity so that you can evaluate the best candidate. This is particularly useful when working with themes.
Below are five prioritization models:
ROI Scorecard
Cost of Delay
MoSCoW
The Kano Model
Product Discovery Trees
ROI Scorecard
The ROI (Return on Investment) is a ratio that calculates the net gain of an investment in relation to the size of an investment.
In product management terms, you can look at the expected ROI of a list of features by asking yourself, "What would the return of building this feature be?" or "How valuable is this feature?" and allocating a score to that value.
In many situations, the cost of the feature is based on tech team salaries. You can calculate the estimate by considering the time it takes the developer to build, test, and release the feature.
The resulting ratio tells you which features will yield the greatest expected return per developer day (i.e., which features you think would be the most valuable).
Cost of Delay
The Cost of Delay is an approach to prioritization that examines the cost to the business of not having a given feature built.
If Feature A costs $10k per week it is delayed and takes one week to build, and Feature B costs $5k per week it is delayed and takes one week to build, then which feature should you build first? Obviously, the answer is Feature A!
By building Feature A first, you still "lose" $5k per week for not having Feature B built. But the overall "cost" of not having any features is minimized.
Prioritizing features becomes more complex when they each have different values and time taken to build them. However, there is a formula to help you decide which one is a priority. Calculate the Cost of Delay and the time taken to build each item (see Duration in the table below), then compare the ratios of the two. The highest priority feature is the one where Cost of Delay and time taken is the highest.
In the table above, the highest priority feature is Feature 2, which has the highest value of $75k per week for Cost of Delay divided by duration.
MoSCoW
The MoSCoW model involves stakeholders assigning one of the following priorities to a list of features:
Must-have
Should-have
Could-have
Won't-have (this time)
"Must have" items need to be delivered for a project to be considered a success. The tech team will then attempt to deliver the "should-have" and "could-have" items if possible within the available time. However, these items will be the first to be removed from the project if there is not enough time to do everything. The "won't-have" items will not be tackled.
This simple approach to prioritizing can be useful when dealing with stakeholders who don't have a technical background.
The Kano Model
The Kano model proposes that product features can be thought of in terms of how customers will react. Features can thus be classified as:
Must-haves: features which are expected by the customer. Having these features doesn't necessarily make the customer happy, but their absence will certainly make them unhappy. You can think of these features as being the basics - what must be present for customers to find the product usable.
Delighters: features that surprise and excite the customer. A delighter creates an emotional reaction in the customer and is often a welcome surprise. Having these features helps you to stand out from the competition and creates that emotional attachment between the customer and the product.
Indifferent: features that the customer just doesn't care about. These features carry no benefit and elicit no reaction from the customer. They are unlike must-haves which could upset customers if they were missing from the product and delighters which excite the customer by their presence. Avoid these features because they have no real value.
Sometimes, you will see the Kano model feature types illustrated on a set of axes where the horizontal axis denotes the amount of functionality and the vertical axis denotes overall customer satisfaction. The way to understand this graph is to think of the customer asvbeing more satisfied the higher the amount of functionality offered by the features.
One way to determine which features are considered must-haves or delighters is to ask customers how they would feel (using a scale of "very unhappy, unhappy, neutral, happy, very happy") if they:
Had a certain feature
Did not have that feature
You can then regard features which users are very happy about having (but not unhappy about not having) as your delighters. Conversely, you can regard features that users are not particularly happy about having (but are very unhappy about not having) as your must-haves.
Product Discovery Trees
Product Manager Theresa Torres suggests Product Discovery Trees as a way of batching product backlog items depending on the opportunity that they offer to achieve desired outcomes.
For example, onboarding emails and live chat with the support team on your website could both be features that you are considering. Both of these features offer the opportunity to help customers who have questions about how your site works. In turn, helping users with these questions can help you achieve your desired outcome of "90% of users complete onboarding."
In this example:
Desired Outcome = 90% of users complete onboarding
Opportunity = Help customers who are confused or have questions
Idea 1 = Onboarding Emails
Idea 2 = Live Chat
If you identify that "Onboarding Emails" and "Live Chat" are both ideas (features) that help you with an opportunity, then it might be that you do not need to do both or that you implement one feature first and then check your data again and only implement the second feature if necessary. The real question to ask is, "Which of onboarding emails or live chat will best help you to achieve 90% of users onboarding?" - and the result is the feature that you prioritize.
Summary
In this section we have looked at five prioritization models: the ROI Scorecard, Cost of Delay, MoSCoW, the Kano Model, and Product Discovery Trees.
Prioritizing is important for product managers because there will always be more suggestions and feature requests. Learning to choose the features that add the most value and help you reach your objectives is an important skill.
Prioritization allows you to avoid a conversation about whether a certain feature is valuable, and instead discuss whether Feature A is more valuable than Feature B which is more effective.
Additional Resources
Some nice scenarios on why the Cost of Delay model (rather than a calculation of cost of delay / Time Taken) does not always result in the most valuable feature first.
Read more about the Kano Model.
In the next chapter, we will learn about how to use Trello, which is an ideal tool for creating and sharing roadmaps.
