Chapter 14 – How to Prioritize Product Features?


[PreviousChapter 13 – Managing Product Backlog]

[Back to content page —  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.

[PreviousChapter 13 – Managing Product Backlog]

[Next: Chapter 15 – Managing Product Development]

[Back to content page —  Product Management 101]

LIKE & SHARE if you found this article useful.
It gives me 🔋 to write knowing people find value in it.   

Share & Help others find the resource