A guide on Prioritization for Product Managers

Product Managers at a party. This meme is in Hindi, you can still understand it. If you can’t then I’m sure you have that Indian friend who can help you.

For a Product Manager there are many situations where they use some form of prioritization to be more productive or effectively manage between all the projects that they undertake.

Even in the interviews, candidates need to prioritize between user personas, pain points and solutions. Here, in some high pressure situations candidates at least need some frameworks on how to prioritize them.

So, there are three types of use cases where prioritizations come in to the picture.

1. Personal time management
2. Product road mapping (which problem to solve first)
3. Product Interviews

Types of Prioritizations

Let’s start with Product roadmap problems. But before that let’s understand what prioritization actually is.

WHAT IS PRIORITIZATION?

At its core prioritization is nothing but doing things that are the most important first. Time from a product management perspective, prioritization is nothing but doin an activity that will create the most value for your customers.

But prioritization is not easy. Prioritizations are generally performed as an exercise in every organization. They are done at all levels and departments. But from a Software engineering and Product Management perspective, prioritization can be done by engineers, designers, product managers internally. It can also be done individually or even by department heads. So, all in all prioritization is not that simple. It may seem that it is objective in nature but it can be very subjective most of the times.

WHY IS PRIORITIZATION SO HARD?

As stated earlier, the problem lies at the sheer number of teams that are involved in a particular project. So, naturally prioritization becomes more and more complex as more and more teams are involved.

There are other problems involved too.

So, let’s first understand the problems of prioritization and then we’ll dive deep into the basics of prioritization.

1. Prioritizations can’t be done alone: This requires inputs from Sr stakeholders, Engineers, Designers and Users.
2. Quantifying the effort to estimate man hours and days is challenging as it’s easy to overestimate and underestimate these numbers. Also, there’s a lot of back and forth with several teams at a time.
3. Estimating impact is very hard: As a PM, every problem you find is the next big thing but how does it stand to other problems in the product and organization. There are some ways to tackle them, keep reading to know more.
4. Making a prioritization is easy from a framework is easy but it never really suffices. Generally, PM’s mix a match different frameworks to make something that works well for their organization. Frameworks are just frameworks, they are generic and do not take in the many things into consideration.
5. Urgencies and externalities create havoc: There are many things which are not not under our control. When these things happen all the prioritizations go for a toss.

With these pre-requisites out of our way, lets start with Prioritizations for Road mapping.

PRIORITIZATION FOR PRODUCT ROADMAPS

A generally accepted framework for prioritization is dividing the prioritization between the projects and within the projects. This is the mother of all the PM frameworks. All other frameworks are made from these building blocks.

1. Between the projects: This is used to find out what project you and your team should do next.
2. Within a project: This used to complete a given project in the most timely manner by prioritizing between the problems/ pain points or ideas for solutions.

Let’s start with Prioritizing between the projects

When thinking about what projects does one need to tackle first, they need to answer “ What will my team invest in next?’

So, to answer this question we need three types of data to make the decision making easier.

1. Estimating the impact to the user: This requires a lot of honesty. Among all the projects that you know of you’ll need to estimate how much value will this project create if the underlying problem of the user is solved.
2. Estimating the the effort required to complete the project (time, manpower) : This self explanatory.
3. Real life constraints ( Dependencies (time, labor), Timelines, Team composition (experience in years))

Prioritizing within a Project

To work most efficiently, We need to ask can I live without this thing or without this I’ll be dead?

1. Build systems to let go of things that are not of the utmost importance: As a PM, its your job to take care of the user’s problems. But many a times PM’s are stuck with bugs rather than features. It’s very important to differentiate between bugs and features. Bugs are part and parcel of any software, so it’s better to give your maximum attention towards solving user problems. But sometimes bugs can be fatal so we need a system to prioritize them.

2. Make good assumptions on speed vs quality on the different aspects of the project: What is invariably means is PM’s need to quickly take a call on things that need to be done fast with some compromises in quality or when quality is of utmost importance. Also, we live in an iterative world. We do not make the perfect product/ feature at once. We make shitty products at first and then gradually make them better.

So, we need to take a call on things which needs to be absolutely perfect and other things which can be done fast.

That’s if for this framework.

Now lets move into some other frameworks. These will be like children frameworks.

POPULAR FRAMEWORKS

We will go through these very quickly as these are very common and you can read about them later too.

1. RICE: Known as Intercom’s internal scoring system for prioritizing ideas, RICE allows product teams to work on the initiatives that are most likely to impact any given goal.

This scoring system measures each feature or initiative against four factors: reach, impact, confidence and effort (hence the acronym RICE). Here’s a breakdown of what each factor stands for and how it should be quantified:

RICE FRAMEWORK

Then, those individual numbers get turned into one overall score using a formula. This formula gives product teams a standardized number that can be applied across any type of initiative that needs to be added to the roadmap.

Formula for RICE Score

2. Value vs Effort: This simple approach to prioritization involves taking your list of features and initiatives and quantifying them using value and effort scores.

With this method, it’s important to keep in mind that the final scores are just an estimation. A lot of guesswork and opinions (backed with as much applicable data as possible) are involved in the process of quantifying the big question prioritization aims to answer: “Will this feature/update push our goals and metrics forward if we build it? Can we feasibly build it with the resources we have?”

Impact vs Value

3. Kano Model: The Kano model plots two sets of parameters along a horizontal and a vertical axis. On the horizontal axis, you have the implementation values (to what degree a customer need is met). These values can be classified into three buckets:

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

On the vertical axis, you have the level of customer satisfaction (the satisfaction values). They range from the needs not being met on the left, all the way to the needs being fully met on the right (the implementation values).

The way you get this customer insight is by developing a Kano questionnaire where you ask your customers how they’d feel with or without any given feature.

The 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.

The Kano Model

4. The MoSCoW: The MoSCoW method allows you to figure out what matters the most to your stakeholders and customers by classifying features into four priority buckets. MoSCoW (no relation to the city — the Os were added to make the acronym more memorable) stands for Must-Have, Should-Have, Could-Have, and Won’t-Have features.

• Must-Have: These are the features that have to be present for the product to be functional at all. They’re non-negotiable and essential. If one of these requirements or features isn’t present, the product cannot be launched, thus making it the most time-sensitive of all the buckets.

Example: “Users MUST log in to access their account”

• Should-Have: These requirements are important to deliver, but they’re not time sensitive.

Example: “Users SHOULD have an option to reset their password”

• Could-Have: This is a feature that’s neither essential nor important to deliver within a timeframe. They’re bonuses that would greatly improve customer satisfaction, but don’t have a great impact if they’re left out.

Example: “Users COULD save their work directly to the cloud from our app”

• Won’t-Have: These are the least critical features, tasks or requirements (and the first to go when there are resource constraints). These are features that will be considered for future releases.

5. Opportunity scoring: The idea is that, while customers aren’t very good at coming up with the solutions to their problems, their feedback is still important. This feedback is what the product team will use to come up with the desired outcomes for a product or feature.

Opportunity scoring uses a Satisfaction and Importance graph to measure and rank opportunities. After you come up with a list of ideal outcomes, you then survey your customers to ask them the following questions:

• How important is this outcome or feature? Ask your customers to rank them.
• How satisfied is the customer with the existing solutions?

After you plot these answers along the chart, you should be able to see the features that matter the most to the customers (the outcomes) yet currently have low satisfaction scores within your product. These are the features you’ll prioritize for your next sprint.

Opportunity scoring.

OPPORTUNITY SCORING FRAMEWORK IS BEST USED FOR PRIORITIZING PROBLEMS WHERE AS OTHER FRAMEWORKS MORE SUITED TOWARDS SOLUTIONS

Now let’s talk about prioritizations for

INTERVIEWS

In a way we have already talked about them above. But lets talk about it anyway.

If are are giving any PM interviews or preparing for one or have faced earlier you might know that there are several types of product questions that one has to prepare for. Some of them are

1. Product design questions
2. Product improvement questions
3. Product metrics questions
4. Favorite product questions
5. Root cause analysis questions

The best and the most tried and tested framework is to follow the CIRCLES Framework. This is the holy grail of all the design interview questions,

Let’s talk a bit about it.

CIRCLES is nothing but

1. Comprehending the questions by clarifying
2. Interpret the user segments / personas
3. Report user needs: from the above user personas (min 3 for each persona)
4. Cut through the user needs by prioritizing (Choose any 3 from above)
5. List solutions (for the above 3 user needs, ideally 2 for each)
6. Evaluate tradeoffs ( for all the solutions)
7. Summarize your recommendation

In the steps 2,4, 6 we need to prioritize User personas, Pain Points and Solutions respectively.

Here are some tricks that might help you.

1. User cohorts — Scale Vs. Scope Vs. Impact

When prioritizing the User cohorts think about the sheer size of that user group and what is all that you can do with that group to help them. After that think about the impact that you can provide by solving their problems. Each cohort will have it’s own strengths.

Use high/low/medium scale or 1–5 rating scale to find out the best user cohort, Pain points, solutions)

2. Pain Points — Impact Vs. Urgency Vs. Ease of Implementation

For pain points we again we need to consider the impact of solving that problem (this is purely subjective). After that we need to think about how urgent is the problem. Consider referring to the image in the previous section.

Ease of implementation or effort is something we need to estimate from our own understanding of Software development so that we can judge the amount of time or effort that will be required to build that solution.

3. Solutions — Impact Vs. Effort

This is simple and self explanatory. Also, explained in earlier sections.

Now let’s move on to the personal prioritization

PERSONAL TIME MANAGEMENT

Ok I’m kidding. I am not that a productive person. I am a tinkerer, dreamer and thinker. Although when I’m busy, I love to time box myself using any calendar app(google, notion etc) and plan a week’s schedule ahead.

But still I don’t do anything extra. My best work comes to life when I give myself enough time to tinker and think.

But if you want some content on Time management here are a few:

How to Prioritize Your Time: Growth, Building Product | Y Combinator

The Most Meaningful Things You Can Do With 2, 5, 15, 30 or 60 Minutes

Ok that’s it from my side. Till next time.

References:

Ruthless Prioritization

Product Prioritization Frameworks: The 9 Most Popular

Also, do like on this post if you liked and help others too.