Reading Time: 5 minutes

As a Product Manager, It is easy to fall victim to scope creep. It is very tempting to dream up cool features/improvements and want it all delivered yesterday. However, in actuality, we cannot have everything we want and get them all done in a limited time frame. Therefore, we need to be ruthless about prioritization and make sure that teams are working on the most important tasks at any given moment.

Prioritization means that you and your team are focused on working and delivering on the most important task at any given moment. By prioritizing efforts appropriately, a product manager also garners trust from the team by protecting them from burning the candle at both ends.

In other words, working on the item that creates the most customer value first.

Why Prioritize?

  • There are often limited available resources of
    • People
    • Time
    • Money
  • Too many potential features/ideas

Prioritization begins with Company Strategy

Product Prioritization begins with company strategy

Company Strategy should drive the Product Strategy. Once the Product Strategy is in place, then a Product Roadmap should be created. The Roadmap addresses the product team’s commitment of deliverables to customers and the company over a particular period. The Roadmap is then further broken down into the Product Backlog which contains features and product improvements that are planned for the immediate and next few releases.

As a PM, making priority calls is an on-going effort. Therefore, it is important to understand the company goals and work with the executive team to translate those goals into a solid product strategy.

Good Prioritization comes down to getting the biggest bang for your buck

As a PM, you should always ask: 

What is the Highest Return on Investment (ROI)?

There are many prioritization tools readily available to assist as you make priority calls. Depending on the outcome you are expecting to achieve, any of them should suffice.

Here are 6 of my favorite prioritization frameworks:

  • Value/Risk
  • Ian McAllister’s Framework
  • Kano Model
  • MosCoW
  • RICE
  • Opportunity Scoring

Value/Risk

This technique is particularly useful when building a new product/feature. Building a product/feature of high-value often comes with high-risks. I am a big believer in tackling the high-value/high-risk items first. The upside of this is potentially significant market success. At the very least, it also aids in proper risk assessment and mitigation of a product/feature.

Evaluating risks typically fall under the following buckets:

  • Technical Risk: Can this be done? Is this technically possible?
  • Cost Risk: Can this be done with allocated budget and resources?
  • Schedule Risk: Can this be done within the expected timeframe?

As far as grading Value, utilizing some other prioritization frameworks such as Kano or Opportunity Scoring can be beneficial here.

The main goal of the Value/Risk prioritization technique is to provide a balanced approach such that High-Value/High-Risk are done first. This is followed by High-Value/Low-Risk and Low-Value/Low-Risk respectively.

Value vs. Risk Prioritization

Value/Risk

Low-Value/High-Risk items should be avoided at all costs. This results in wasting valuable resources and time to work on products/features that will provide little-to-no value to customers.

Ian McAllister’s Framework

Ian McAllister was a former Director of Product at AirBnB. Below is the framework he used during his time at AirBnB:

  • Define the important themes for the product or business: Create a list of the most important themes (e.g. Retention, Engagement, Customer acquisition, NPS etc.) and select the top three
  • Prioritize and resource the themes: Define the relative priority for each theme and how much resources (team, money) you want to invest in each
  • Generate project ideas: Use projects ideas you already have for each theme and come up with new ones. Remember Pareto principle and focus on the 20% of the project that will get you to 80% of the desired outcome
  • Estimate each project’s potential impact: Work out the impact you expect from each project, in very broad terms (think order-of-magnitude-similar)
  • Estimate each project’s costs: Utilizing your team’s and relevant stakeholder’s help, come up with an estimation for each project’s costs
  • Prioritize project within each theme: Set priorities considering the projects with the best impact-to-cost ratios

Kano Model

Kano Model

Kano Model [Source: career.pm]

  • The Kano Model classifies features into four categories, depending on how customers react to the provided level of functionality. 
    • Attractive: Customers like having a feature that is not expected
    • Performance: Customers like having them and dislike not having those features
    • Indifferent: Customers are neutral
    • Must-Be: Customers expect to have certain features and dislike not having them

In order to uncover the customer’s perceptions towards the product’s attributes, use the Kano questionnaire. This consists of a pair of questions for each feature that needs to be evaluated:

  • Ask customers how they feel if they have the feature
  • Ask customers how they feel if they did not have the feature

General rule of thumb:

Must-Be > Performance > Attractive > Indifferent

MoSCoW Method

This is a quick and simple tool that aligns company stakeholders on what is important for their customers:

  • Must Have: Critical and must be included in release. Product won’t ship without it
  • Should Have: Important but not critical for release
  • Could Have: Desirable but not necessary for release
  • Won’t Have: Not critical and possibly not aligned with product strategy

While this tool is quick and fairly easy to use, it does get tricky to distinguish between Should Have and Could Have. As a result, I tend to lump Should Have and Could Have together further simplifying this technique.

Opportunity Scoring

Opportunity Scoring Prioritization Framework.

Opportunity Scoring; Outcome-Based Approach Framework

  • This is an Outcome-based approach that focuses on which customer values should drive product decisions
  • Via user research, the product manager should build a list of jobs –tobe-done/desired outcomes of the product from the customers’ perspectives
  • Ask the customer to score each outcome on a scale of 1 to 10:
    • How important it is for the customer?
    • The degree to which it is satisfied?

Opportunity = Importance + max((Importance – Satisfaction), 0)

RICE

RICE requires making estimations across the following variables and calculating a score that determines the priority.

  • Reach: How many customers/users will this impact?
  • Impact: How much will this impact each person? (Massive = 3x, High = 2x, Medium = 1x, Low = 0.5x, Minimal = 0.25x)
  • Confidence: How confident are my estimates? (High = 100%, Medium = 80%, Low = 50%)
  • Effort: How many person-months will this take?

RICE Score = (Reach * Impact * Confidence)/Effort

Prioritization based on RICE Score

Prioritization based on RICE Score

This is a framework I use often for prioritizing bug-fixes. To make sure not to underestimate, a good rule of thumb is to double the effort and halve the impact.

Product Prioritization Takeaways

The aforementioned are just 6 of over 20 different frameworks that are available in your daily efforts as a PM. These frameworks serve as a guide for prioritization conversations and should not be leaned on as crutch. As such, sound judgement in evaluating trade-offs is still required when making these priority calls.

Whatever the priority is, make sure to communicate with the team, stakeholders, other PMs, and interested parties how that decision came about to ensure everyone is in alignment.

As a reminder:

  • Keep Strategic goals at the forefront of all prioritization efforts
  • Strive for delivering the most value with the least amount of effort
  • Priority = Value/Effort
  • Communicate and make sure everyone is aligned on the priority
  • Prioritization is not a one-and-done but an ongoing endeavor
  • Being a PM is rarely about saying “yes” and more about saying “no” frequently


Liked the post and think someone else will? Please share 😃