OUR RESEARCH PROCESS

Charles Du, founder of productcharles.com, has taught Product Management to over 20,000 students from over 130 countries. Charles designed NASA’s first iPhone app (10+ million downloads, 2+ million hits per day, NASA’s Software of the Year Award), Ticketmaster’s mobile apps ($3+ million in sales per day, 2 patents), and the Airbnb for cars ($1 billion valuation, Techcrunch Disrupt Award, 1 patent-pending). He has led workshops at 20+ education institutions (Stanford, General Assembly, Shanghai Jiao Tong, Singularity University). Charles’s students have landed offers and interviews from Google, Uber, Facebook, and Amazon.

Card Count Icon 6 cards
Card Count Icon 15 minutes

Prioritization is used to rank feature ideas in the backlog. As you gather feature ideas from different stakeholders and users, they are captured in a list (unranked). In order to decide what to build next, you have to prioritize them.

You are ready to prioritize features when you have a product roadmap and a backlog. If you prioritize without a product roadmap, you won’t have a focus point to make decisions. If you prioritize during sprint planning, you’ll incur waste because sprint planning often involves many people. As a product manager, it’s your responsibility to take a prioritized backlog into a sprint planning session.

Tool

Contains

Purpose

Roadmap

List of products that will be built

Communicate product strategy, bring focus, align team

Backlog (Prioritization happens here)

List of features in 1 product that may be built

Capture feature ideas, decide what to build next

Sprint Board

List of features in 1 product that will be built

Align resources, start development process

  1. Decide how to structure prioritization decision-making:
    1. PM prioritizes and decides - good for small early team, when working from a strong product vision and resources are at a premium
    2. Group prioritizes, PM decides - good for features involving diverse stakeholders, effective at providing PMs with more information for good decision-making
  2. Pick a prioritization framework
    1. Use RICE if priority is on simplicity
    2. Use Kano if priority is on customer feedback
    3. Story Mapping if priority is on identifying MVP
    4. Use Pyrami if priority is on ecosystem disruption
  3. Pick a meeting structure
    1. Pick participants
    2. Pick duration
    3. Pick cadence (i.e. every 2 weeks)
  4. Review meeting structure with key stakeholders
    1. Set up meeting
    2. Overview prioritization process
    3. Update process with feedback
  5. Execute prioritization and regularly move priority features into sprint planning
Prioritization Meeting Agenda and Facilitator Guidelines Template
RICE Scoring template
Kano Feature Survey template
Story Mapping Prioritization Template
Pyrami Prioritization Template

Decision structure

Approach

Velocity to Prioritized List

When to use

PM prioritizes and decides

High

  • Features are simple, has low impact / dependencies on other features, and/or cost for change is low
  • PM is the domain expert
  • Team has high trust

PM prioritizes with group input, PM decides

Low

  • Features are complex, has high impact / dependencies on other features, and/or cost for change is high

Note: this is the most common approach. Meeting Agenda Template here

Prioritization framework

In addition to who’s involved in the decision, companies must also choose how what factors to include in how decisions get made. Here are three of the most common frameworks for prioritizing.

Tool

Pros

Cons

RICE

Simple model

Easy to “score” each feature based on factors in a formula

  • Some factors can be very subjective and hard to measure (i.e. Impact, Confidence)

Kano

Stable model

Customer desire drives priority

Considers customers psychological adaption to features

  • Requires large number of surveys
  • Risk designing what customers want instead of what customers need
  • Won’t lead to a disruptive product

Story Mapping

Fast model

User-centered model quickly identifies MVP

  • Doesn’t take into external product prioritization factors like business value and complexity
  • Can be overly simplistic

Pyrami

Disruptive Model

Long-term, ecosystem-level approach

Prioritizes organic, sustainable growth

Relies less on marketing budget for product success

New model, requires some investment in training to train the team

There are 2 main approaches to prioritization, based on whether the PM prioritizes alone or PM prioritizes with group input.

Below are 4 feature prioritization models. Each of these models should be taken as loose inspirations instead of firm recipes.

Factor

Definition

Examples

Reach

# of people or events per time period impacted by feature

  • 400 customers per quarter
  • 2000 transactions per month

Impact

Amount of impact on an individual user (scale of 1 - 3, 3 being highest impact)

  • When a customer sees this feature, it will have huge impact. Impact score = 3
  • When a customer uses this feature, it won’t change anything. Impact score = 1

Confidence

% confidence in feature success and engineering effort

  • High customer desire, high confidence in engineering estimation, confidence = 100%
  • Very little data or validation to support feature idea, effort estimate is unknown, confidence = 20%

Effort

Level of effort needed from product, design, and engineering to build feature, measured in “person-months”

  • 1 week of PM planning, 1-2 weeks of design, 2-3 weeks of engineering. Effort = 1.5 person months.

The four factors are combined to make a single score that you can use to prioritize.

Feature

Kano Feature Type

Note

Shoe Details Screen

Basic

Users won’t use the app if they can’t view the shoe they’re going to buy

Load images in background

Performance

Helps users get their task done faster

Slow 360° rotational image of shoe

Attractive

Cool way of showing a product that’ll delight the user

To categorize each feature, teams send customers questionnaires surveying them how they’d feel with or without any given feature.

Image Credit: Mind The Product

For details on how to grade survey results. Check out the link here

Along a horizontal line, you create a series of sequential buckets or categories that represent each stage of the user’s journey through your product. This allows you to think about the way your customers navigate your product from signing up, to setting up their profile, to using specific features.

Here’s an example of a Pyrami Map for an eCommerce app.

View Pyrami Prioritization template here

Because prioritization can be a complex exercise that takes into account many factors, it’s often more art than science.

The most effective used model will be the one the PM creates that is specific to the product being managed.

Formula: Reach X Impact X Confidence / Effort = Score

Each feature idea contain 2 questions:

One core idea of the Kano model is that the more time you spend investing resources (time, money, effort) to create, innovate and improve the features in each of those buckets, the higher the level of customer satisfaction will be.

Along a vertical line, you then place these tasks in order of importance, from top to bottom. This allows you to prioritize the order of the features you’ll work on. In some cases, the bottom part of the axis is labeled “Backlog items” for the tasks that you decide to put on hold.

In Pyrami, the PM decides the priority of each feature by managing the cost invested in each stage. For each stage, you want to invest more in functional features than emotional features, and invest more in emotional features than ecological features.

The most effective used model will be the one the PM creates that is specific to the product being managed.

The most effective used model will be the one the PM creates that is specific to the product being managed.

View RICE Scoring template here.

  • How would you feel if the product had that feature?
  • How would you feel if the product didn’t have that feature?

Finally, you draw a line across all these stories to divide them into releases and sprints.

Pyrami is a great model if you want to prioritize growing a product that disrupts an entire industry. It places more consideration in a product’s emotional features and ecological features.

Story Mapping

The RICE Model

This model evaluates each feature based on 4 factors: Reach, Impact, Confidence, Effort. The four factors are

The RICE Model

This model evaluates each feature based on 4 factors: Reach, Impact, Confidence, Effort. The four factors are

The RICE Model

This model evaluates each feature based on 4 factors: Reach, Impact, Confidence, Effort. The four factors are

The feature can be described with a title, description, wireframe, and/or mock. The more detailed the description, the easier it’ll be for your audience to visualize.

View Kano Feature Survey template here.

Kano surveys work great for getting insights on launched products with established user base.

If a team is working on an unlaunched product without an user base, the product manager can still use this prioritization framework as a guide. User insights can be extrapolated from in depth user interviews.

Survey results are graded and plotted on two-axis grid, comparing product investment with customer satisfaction.

View Story Mapping Prioritization template here.

Story mapping is a great model if you want to quickly identify your Minimum Viable Product. The model lets you quickly see which features are needed to complete a user experience.

The Pyrami Model

Pyrami is a prioritization framework that models the features of a product like a life form growing in an ecosystem, successful products tend to build enough features to satisfy a lower level stage before progressing on to the next stage. If a product does not invest enough time at the lower level stages and attempts to move to the next stage prematurely, the product will either fail or hinder its potential. The Pyramid is separated into 3 stages:

  • Functional: The functional stage is where you build the “must have” features to power your product’s engine? What features help your users solve their problems? Functional features also include features related to performance. Is the product reliable? Is the app fast? How often does it crash?
  • Emotional: After the functional features are built, we can focus on how we want the user to feel. This is the skin of the product. How it looks, how it sounds, how it moves, how it feels. Apple is incredibly good at building products that make people feel a certain way. The iPhone is a great example of a product filled with emotional features.The animated transitions between one view to the next gives off a feeling of speed and familiarity. The rounded corners on the iPhone casing makes the iPhone feel approachable.
  • Ecological: To grow a long lasting product, you need to build features that will create a thriving ecosystem for your specific product. The iPhone has the app store. Ticketmaster has ticket transfer. Uber has the referral system. All of these features help these wildly successful products grow their ecosystem and keep it thriving. Users in a thriving ecosystem feeds the ecosystem with attention and resources.

Unlike other models where the product relies on marketing to grow, the Pyrami model encourage the product to build features that help expand its own ecosystem.

The Kano Model

This model classifies features into 3 categories:

  • Basic: If you don’t have these features, your customers won’t even consider your product as a solution to their problem.
  • Performance: The more you invest in these, the higher the level of customer satisfaction will be.
  • Attractive: These features are pleasant surprises that the customers don’t expect, but that once provided, create a delighted response.

Consider an eCommerce app that lets you buy shoes.

This model focuses on the user’s experience, rather than on the internal opinions of team and stakeholders.

Here’s an example of a storyboard for an eCommerce app.

Who should be involved

The Product Manager should own and lead the prioritization process. The PM should gather input from business stakeholders (upper management), engineering, and other stakeholders (PMs of other impacted products).

How often should you prioritize?

The backlog should be groomed at regular periods. Depending on the velocity of the team, it can be groomed as often as every sprint to as often as every quarter. Avoid re-prioritizing during a sprint at all costs.

The backlog should be groomed at regular periods. Depending on the velocity of the team, it can be groomed as often as every sprint to as often as every quarter. Avoid re-prioritizing during a sprint at all costs.

The backlog should be groomed at regular periods. Depending on the velocity of the team, it can be groomed as often as every sprint to as often as every quarter. Avoid re-prioritizing during a sprint at all costs.

How to manage prioritization

The prioritized feature backlog should be as transparent as possible. In most cases, all immediate team members and stakeholders should have view access to the backlog. The PM can post the prioritized backlog to a physical board or wall. Radical transparency will lead to better team alignment. Any questions, concerns, and comments can be addressed immediately

How to manage prioritization

How to manage prioritization

The prioritized feature backlog should be as transparent as possible. In most cases, all immediate team members and stakeholders should have view access to the backlog. The PM can post the prioritized backlog to a physical board or wall. Radical transparency will lead to better team alignment. Any questions, concerns, and comments can be addressed immediately

The prioritized feature backlog should be as transparent as possible. In most cases, all immediate team members and stakeholders should have view access to the backlog. The PM can post the prioritized backlog to a physical board or wall. Radical transparency will lead to better team alignment. Any questions, concerns, and comments can be addressed immediately

The prioritized feature backlog should be as transparent as possible. In most cases, all immediate team members and stakeholders should have view access to the backlog. The PM can post the prioritized backlog to a physical board or wall. Radical transparency will lead to better team alignment. Any questions, concerns, and comments can be addressed immediately

At the product level, teams typically use a spreadsheet tool like Google Sheets, Numbers, or Microsoft Excel. At the feature level, teams typically use the same tool as the tool used to manage a feature backlog.

See article on how to create and manage a product backlog here.