Chapter 14/17: How to Prioritize Product Features ?
[Prev: Chapter 13 — Managing Product Backlog ]
[Next: Chapter 15 -Managing Product Development ]
[Back to — Product Management 101]
Your Product Backlog list seems endless as the contribution comes from so many different sources — internal team, stakeholders, customer and anyone associated with your product.
You cannot build everything “right away” and you want to utilize the team’s time and resource in the most effective way.
That’s when you require prioritizing your backlog.
The Product Backlog needs to be groomed constantly to keep it updated. This is why the team regularly needs to schedule Grooming session to arrange user stories in order of priority so that the development team knows the next set of tasks they need to perform in a given sprint.
How to prioritize features (user stories)
You might have a basic idea on prioritization by going through this chapter on Defining MVP.
You can also make use of Ian McAllister’s Framework for Feature Prioritization -
A. Define the important themes for the product or business and prioritize the themes
Create a list of the most important themes. These themes could be centered around one of the business goals:
- Acquisition
- Activation
- Retention
- Revenue
- Referral
Or, other tasks e.g. Integrating with Partner’s API, Setting up analytics API for customer insights, etc.
B. Prioritize features for the current Product theme.
You could make use of any of the following for Feature Prioritization -
1. Mix of Kano & MoSCoW Technique
According to this technique, we can categorize the features into one of the following buckets -
- Must have — these are critical stories and must be implemented with top priority. The absence of any one of them could hamper user experience greatly. These are part of “Basic Expectation” as per Kano Model. For example, solving a critical bug or adding a feature without which a user’s workflow is incomplete.
- Should have — these requirements are important but not crucial for the release and can be implemented in one of the following sprints. They’re the first level of “Performance”, or “Basic Expectations” that are not time-sensitive.
- Could have — these requirements are desirable but not necessary for the release. They’re the second level of “Performance” features or “DELIGHTERS”.
- Won’t have — these are features that are not aligned with the product goals.
Read more about Kano Model in this chapter 5 — Defining Value Prop
2. Value v/s Effort
We can define the value derived from a feature in multiple ways -
How important is the need (which the features cater to) for the user?
How important is the feature to complete the workflow of the product or the task user wants to achieve?
Or we can also use Dan Olsen’s definition:
Value = Importance of User need — Satisfaction from current solution
Features are then plotted on a matrix of Value (Y-axis) v/s Effort or Cost (X-axis).
The prioritization rankings will be visible as the slopes of the lines going from the origin to each feature. The higher the slope, the higher the priority. The main goal of this method is to maximize value delivery.
One thing to note about this method is there’s a tendency to prioritize low-cost, low-value items (which have good Value/Cost ratios). This may end up with a product full of easy solutions.
This is where your discretion is required, as the method must be used as guidelines, not as a definitive answer.
3. RICE Scoring
You could make use of Scoring based prioritization keeping in following factors:
Reach — How many use-cases would the feature effect or How many people will it impact?
(Scale of 1–5 where for each score you could define the range)
Impact — How much would be the impact to any goal (e.g. impact on revenue, conversion, traffic, referrals, etc)?
(Massive — 3, High — 2, Medium — 1, Low — 0.5, Minimal — 0.25)
Effort — How many “man-weeks” required to develop the feature.
Confidence — How confident are you in your estimates?
(High — 1, Medium — 0.8, Low — 0.5)
Combine the factors into a score (RICE) Score -
RICE Score = Reach x Impact x Confidence / Effort
4. Story Mapping
If the product is in MVP stage, it is advisable to prioritize your features based on story-mapping (as shown).
Read more on how to define and prioritize MVP.
Depending on the product or the number of user stories, you could make use of any of the above techniques.
However, no matter what technique you use, you should remember that the focus of this activity is to -
- Focus on providing value to the user
- Now waste any time/resource
- And most importantly, prioritization should never be a solo effort
Next chapter, we’ll explore how to develop a product using Agile Methodology.
[Prev: Chapter 13 — Managing Product Backlog ]
[Next: Chapter 15 -Managing Product Development ]
[Back to content page — Product Management 101 ]
Want to learn more?
Enroll into Product Management:A-Z — The complete product management online course with 25+ chapters, 40+ live assignments and product interview tips . Built with inputs from experienced Product Managers working @ Top Tech firms like Google, Adobe, Amazon; the course has 500+ enrollments from 40+ countries.
Book Mock Interviews with product experts to practice your interview skills & get detailed feedback.
Check out PM Interview Questions — An exhaustive list of unique Product Management interview questions answered by product experts.
Click 👏 if you found this useful. SHARE to help others find this article.
It gives me 🔋 to write knowing people find value in it.
Originally published at zapupp.com
