The ultimate guide to product prioritization; everything you need to know!

In this guide, we look at 3 things 👇

1. 15 of the most popular prioritization frameworks used by product managers to prioritize features with their teams.
2. How product managers can go about simplifying the painfully long backlog refinement meeting.
3. How product managers can translate all of their product backlog into a simple product roadmap they can then use to plan, track and communicate everything!

What is prioritization in product management?

Product management prioritization refers to any process that can help evaluate the relative importance of an idea or piece of work in delivering customer value efficiently, in the fastest way possible, and given a certain set of variables.

To do that, you need to be able to answer questions like:

• Am I working on the item that has the highest value?
• Does my work align with my company’s business strategy?
• Can I deliver my product, and on time?
• Am I delivering the highest value to my customers?

How?

By using product prioritization frameworks that can help you and your team choose what to work on next.

The product manager’s dream

Product managers are responsible for a plethora of things, from market research and building personas, to prioritizing products and features whose development is then planned, tracked and managed across teams via a product roadmap that can then be used to showcase progress to stakeholders; all the while including teams in the process.

Why is prioritization tricky for product managers?

Product prioritization isn’t just about stacking a bunch of features in a certain order; there’s much more that goes into it. Shortening the list of feature requests and demands before moving on to the product roadmap is actually a very challenging feat.

Also, knowing who to involve, when, and to what degree is part of the charm that is product management.

How do product managers prioritize?

They use tools, and the tools better be good! 😆

If the teams are already using Jira, then the product manager will most probably want to use Jira as well in order to include the team in the prioritization process, while managing everything in one place. Oh yes.

The dream is to be able to do everything from one, single place.

#1 Backlog feature prioritization techniques

A product backlog is a list of every product-related task we hope to complete within a certain time frame. And in order to avoid dealing with an open-ended list (which often happens), we do product backlog prioritization - a sure way to favor those tasks that can bring in the most value.

There are various product prioritization techniques out there; here we focus on the ones product managers use the most.

Story mapping

Introduced by Jeff Patton as a great way to work with Agile stories, the Story Mapping technique is that extra step beyond the product backlog. It allows teams, partners, and clients to align on what’s happening, and defines how to gradually release product iterations.

• The horizontal axis (use) is where tasks are placed in the sequence in which they’re performed by a customer.
• The vertical axis (criticality) is where tasks are placed relative to how important they are from top to bottom; equally important tasks are at the same height.
• Activities is where related stories are grouped.

MoSCoW Prioritization

MoSCoW is one of the most popular prioritization methods in project management circles, used to communicate what needs to be included (or not) in a feature release; it uses four categories to prioritize products.

• Must: the mandatory items; if you abandon them, the current sprint will likely fail.
• Should: these are great to have; even if they don’t have much impact on delivery, they must be implemented.
• Could: essential small-scale improvements that don’t require a lot of resources; their absence will not significantly affect the release.
• Would (or won’t): these have the lowest importance; you can easily remove or reschedule them for future releases.
  

Product tree

The product tree is a collaborative game to help shape a product in such a way that it matches with customer outcomes which can bring the most value. ‘Pruning the product tree’ ensures that innovative ideas aren’t left behind.

The Product Tree process step by step:

1. Draw a tree with a few big branches
2. Ask stakeholders to write potential features on sticky notes
3. Then ask them to place those notes on the tree:

• Trunk of your tree = features your product already has
• Outermost branches = features from your next release
• Other branches = features not yet available

Once your customers have placed the features they want, you can then identify the branches with the most notes as the areas of the product to actually focus on, then find out the features you should change, as well as what to remove or keep for future releases.

Eisenhower matrix (urgent vs. important)

The Eisenhower Matrix is a simple tool used for prioritizing product tasks based on importance and urgency. It works by distributing all the activities and projects you want to tackle into four distinct quadrants.

Eisenhower matrix quadrants:

• Quadrant 1: urgent and important
• Quadrant 2: important, but not urgent
• Quadrant 3: not important, but urgent
• Quadrant 4: neither important nor urgent

Why Eisenhower?

Because former U.S. president Dwight D. Eisenhower’s daily life was filled with tough decisions and setting priorities!

“I have two kinds of problems: the urgent and the important. The urgent are not important, and the important are never urgent” - Eisenhower

The Eisenhower framework is the basis for all 2x2 matrices, with features allocated across four quadrants with two dimensions.

Value vs. effort matrix

The value vs. effort matrix is one of the quickest ways to prioritize a backlog.

Value

Ask "How does the task contribute to your goal?".

The goal can be anything from writing better code to making your customers happy.

Effort

Ask "How hard is it to deliver the task?".

Effort should be inclusive of all parties involved.

Tasks are defined based on how much effort you would need to spend in order to get value X.

Quick wins

• low effort, high value
• You definitely want to start with these.  
  

Big projects

• high effort, high value
• Can bring significant value to the workflow but requires time and effort.
  

Fill-ins

• low effort, low value
• These are your maybes; tasks and activities you can easily complete, but with less impact.
  

Time sinks:

• high effort, low value.
• Best to forget about these during the day.

But wait…

Quick wins matrix

When considering the real impact of a quick win, many factors tend to come into play; such as your team's increased know-how or their market knowledge, for example. So what would it mean to operate within a new framework for quick wins?

It would mean to transcend the traditional approach of the high impact, low effort quadrant. The quick wins matrix is a type of value vs. effort matrix that takes into consideration a couple of extra variables!  

The Quick Wins Framework is a 4-step process (ideate, prioritize, execute, recognize) that is great for companies looking to disrupt. One of the reasons we find disruption hard is that we’re using old business models and processes. But by asking the right questions, testing, prioritizing and aligning quick wins with existing goals, efforts can be better directed.

5 metrics values are merged together to define your quick wins score (based on the Quick wins paradox).

Health assessment

How feasible is it to deliver the item, and does it have a real collective impact?

Value vs. effort (i.e. impact vs. effort)

Choose the two metrics that work best for you; it doesn't have to be value vs. effort.

Team size and type

A rule of thumb; the more people are involved, the least likely it is to be a quick win. Also, a quick-win that can transform into something repeatable and sustainable has a higher value.

This process isn’t something you master overnight.

It is by going through the exercise over and over again, and iterating, that you’ll get clarity around the metrics and how to vote on them.

Quick wins chatbot

For a quick way to verify if your idea qualifies as an actual quick win, this chatbot can help!

As mentioned above, the value vs. effort matrix can be customized.

Value vs. complexity matrix

The value vs. complexity matrix is a lightweight methodology often used by product and project managers to evaluate new features, based on business vs. tech. It is used when starting to work on a new product, building an MVP or when resources for development are limited.  

Value can be derived from a variety of criteria such as retention, market demand, ROI, customer engagement/acquisition, and so on.

As for complexity, the team will estimate the total cost of the feature, in parallel with how complex it is to make it happen.

Value vs. cost matrix

The value vs. cost matrix is a very common method to determine priorities, and it’s popular because of how simple it is. Product features are considered based on their value vs. the cost of implementing them.

All of the features are spread out while priority ranking is displayed as a slope of the line that goes from origin to the feature; the higher the slope, the higher the priority.

Value vs. risk matrix

Risk management is a proactive planning process that allows you to stay on track by identifying risks ahead and how to handle them. The value vs. risk matrix is a simple prioritization technique that segregates product tasks based on different criteria for risk scoring.

The value vs. risk matrix is useful for addressing uncertainty:

• How long will a feature take to complete?
• How much would it cost?
• How easy is it for the team to make it happen?
• How much support will this get from executives?

The value vs. risk matrix features 4 quadrants like any 2x2 matrix:

• High-value, low-risk: items you should prioritize.
• High-value, high-risk: may have more impact than high-value, low-risk items but you could be wasting time on features you don't use.
• Low-value, low-risk: may be worth it eventually, but after you’ve prioritized high-value features.
• Low-value, high-risk: forget about these.

After all, so many risks are involved in building products; risks like security, legal or even platform stability. For example, the older a platform is, the less stable it usually gets which means that it’s now riskier to add new features to it. If the code is old and complex, adding new features on top may be so risky that you’ll decide to rebuild the platform completely before moving on.

Other risks may include the probability of your competition introducing the same features or changing price strategy, and so on.

So… how do you push for a more objective risk matrix?

1. Ask and answer these following questions:

• What could happen?
• What is the profitability of this happening?
• Which of the things that might affect are important?
• What should we do about it?
• Who will own the Risk?
• Did it work?

2. Use a risk register to input the factors influencing your risk value.

👉 Learn more on managing risks with a risk register

ICE (impact, confidence, ease)

Initially developed to prioritize growth experiments and MVPs, the ICE method is now popular among all types of projects. ICE stands for Impact, Confidence and Ease.

The ICE method is great if you’re just starting or if you want to implement a discipline for your prioritization with the team. It’s best for building new products, as well as prioritizing MVPs, growth experiments and feature requests.

In contrast to the related framework RICE below, you don’t need to have access to product usage or customer behavior data when prioritizing with ICE.

Impact

How much does this contribute to your goal?

Confidence

Think about how confident you are that this will work based on: previous similar tasks, how impactful they were and what worked for others.

Ease

Ask yourself how hard it is to implement. Think about the task as a whole, i.e. how difficult it is for all parties involved, not just the development team.

RICE (reach, impact, confidence, effort)

RICE is one of the most popular techniques for prioritizing product backlogs; it uses metrics such as reach, impact, confidence and effort to calculate priority scores for each item in the backlog.

Developed by Intercom, the RICE framework is an objective scoring system mostly used by product management teams when prioritizing features as they create their product roadmap. This backlog prioritization method also helps remove bias from backlog refinement meetings.

Aside from the three metrics similar to the ICE method, RICE includes reach.

Reach begs the question: “how many customers does this task impact within time period X?”; X being any time frame you choose based on your data.  For example, if you’re planning to upgrade a feature, then reach would be defined as the number of users to have used the feature in the last quarter for example.

WSJF - weighted shortest job first

Weighted Shortest Job First (WSJF) is a prioritization model that allows you to calculate the financial impact (cost of delay) of not finishing a task or failing to implement a solution sooner than later.

This prioritization technique is designed to help speed up the delivery of value, especially in large projects with big issue queues and long waiting times!

To calculate the Cost of Delay and WSJF score, we assign four metrics to our priorities:

• Business value: how does it impact your business?
• Time criticality: can you lose customers if it’s not completed on time?
• Risk reduction: is there a negative impact when delaying?
• Estimated size: how difficult is it to deliver?

Kano model

The Kano model is great when you’re trying to decide on product improvements and add-ons. It can be implemented differently as per context, but essentially, it is based on various levels of user satisfaction and requires conducting surveys and interviews before prioritization.

The model was first described by its author, Japanese researcher Noriaki Kano back in the 1980s.

One known version of the Kano model separates user backlog items such as features, in this fashion:

• Must-be features that have to be there for the customer to consider the product functional.
• One-dimensional features which aren’t “must-have” but that seem to be desirable.
• Attractive features which are usually unexpected but nice to have as they add that extra satisfaction.
• Indifferent features that don’t really have value as they’re the ones to have the least possible impact on customer satisfaction.
• Reverse features that will usually have a negative effect on customer satisfaction.

Opportunity scoring

The Opportunity scoring model (or opportunity analysis) is a prioritization technique that comes from Anthony Ulwick’s Outcome-Driven Innovation concept. The premise is this: customers buy products and services to get a certain job done.

While unable to come up with a solution to their own problems, customers do however provide key feedback that can bring about the desired outcome.

The Opportunity scoring approach looks at two variables while ranking opportunities: satisfaction and importance. Once you’ve put together a list of ideal outcomes, you can then survey clients by asking them two questions:

1. How important is feature X?
2. How satisfied are you with the solution?

Once you plot your answers on the chart, you’ll be able to see which features matter most to people, but also, which features they’re unhappy with. These items are then added to your next sprint!

PIE framework- potential, importance, ease

The PIE framework is an idea prioritization tool we use in A/B testing or split testing, created by Chris Goward to help businesses identify the ideas or features they should test first by monitoring conversion rates.

The PIE framework involves 3 metrics to identify and queue your most important experiments first.

• Potential: can improvements be made?
• Importance: how valuable is the traffic?
• Ease: how difficult is it to run an experiment for this?

Product backlog items are chosen as to how hard they are to test based on technical and economic ease; each candidate is basically quantified as a business opportunity.

What's next?

Now that we’ve looked at these 15 prioritization techniques, one thing must be said:

Never rely on prioritization results only; after all, these are techniques designed to help you decide, not make your decisions for you. For optimal results, always discuss priorities with the team before starting any sprint and don’t be scared to adjust manually.

Ok, so…

Most product backlog prioritization techniques are about using metrics to calculate a final priority score for each and every single backlog item, as a way to ensure you make data driven decisions; especially when prioritizing more complex work! Right?

Question remains; who decides on what metrics to use and who gets to vote on priority scores?

#2 The art of backlog refinement (a Jira case)

(previously known as backlog grooming)

Backlog refinement (or sizing, backlog management) is the process by which a product owner or product manager adjusts and prioritizes backlog items to ensure that the work being done is actually bringing the most value.

Backlog refinement is all about keeping the product backlog up-to-date (with items ready for upcoming sprints) while aligning stakeholders.

How can I optimize the backlog refinement process?

There are ways to optimize the backlog refinement process which is essentially a meeting session where product owners/product managers discuss and prioritize backlog items with the rest of the team. It’s a great way to improve development processes for product teams so they can deliver better products.

After all, product prioritization frameworks are a way to get everyone on the same page, assessing the many possible outcomes that can be created around any given feature or idea.

The case of the HiPPO

A HiPPO (or Highest Paid Person's Opinion) is the relevant opinion of individuals in decision-making positions. It goes without saying that such a position is achieved with a set of skills, management capabilities and a certain knowledge, as well as hard work along the way, but that’s not all there is to it.

The downfall is that somewhere, someone may think that their instincts are infallible; therefore, they must be accepted by everyone.

One way to look at it is; good product prioritization frameworks exist to silence the loudest voice in the room by using actual data, charts and matrices that are directly connected to strategy and customer feedback.

Product backlog prioritization is a team event

Strategic decision-making can easily turn into an efficient group activity by using the right prioritization tool; voting seems to work in the bigger scheme of things.

Turning a prioritization session into something of an opportunity for people to collaborate and enjoy themselves as they come together as an organization, not only enhances product prioritization; it enhances various other aspects such as teamwork.

The dark side of backlog prioritization

The bigger the team, the longer the backlog refinement meeting; and at times, it can turn into such a tedious process that everyone will dream of avoiding it. So, how do you go about calculating priority scores as a team without wanting to die?

You need a tool..

The curious case of backlog prioritization in Jira

The next part of this guide is dedicated to teams and product managers who use Jira as their work management software.

Why? Because the tools we’re introducing are Jira Cloud plugins that work brilliantly, alone or together, to maximize the outcome from any Jira backlog prioritization process.

As mentioned already, it is every product manager’s dream to have everything in one place.  

How to solve the prioritization problem in Jira?

Let’s face it; prioritization in Jira is basic and more often than not, companies choose to prioritize their backlogs elsewhere.

They might try out prioritization methods outside of Jira, then end up plugging priority scores manually in Excel. Or with hope in their hearts, they might attempt to use a Jira field that they’ll probably end up having trouble tracking.

A built-in prioritization tool that would allow them to prioritize issues directly in Jira, with a way to nicely present their results to stakeholders. Is it too much to ask 😓?

🦊 Foxly: the ultimate backlog prioritization tool

Foxly is a backlog prioritization tool built for Jira Cloud, that brings prioritization back to where it all started; in Jira!

What does it mean?

Foxly is fully integrated with Jira, which means that you can manage your priorities directly in Jira and make use of some cool automation rules to help simplify and improve your prioritization process, and remove the manual overhead.

Foxly helps align everyone on the team by allowing them to participate in the prioritization process. Not only do stakeholders know what features to look forward to, they also understand the why behind them.

What can I do with Foxly Jira backlog prioritization plugin?

• Prioritize existing Jira issues directly in your projects
• Prioritize multiple projects in one place, if you so wish
• Filter through projects in order to segregate
• Calculate priority scores based on factors you define with the team
• Choose from a set of existing prioritization techniques
• Customize your own set of metrics and scoring formula
• Get an update to your priority score as soon as a metric value is changed
• Use labels that mean something, as opposed to numbers only
• Select the styling for your metrics
• Use different prioritization templates for different projects
• Access a priority matrix to visualize your backlog items
• Push all issues to development through bulk import

👀 There’s more…

How can everyone participate in the prioritization process?

With Foxly, all you need is the internet (currently); and of course… Jira. 💙

Priority planning poker for inclusive prioritization

Priority planning poker is a fun and easy way to get everyone on the team to equally contribute to the prioritization process by removing bias through voting; it’s a feature included in Foxly.

The premise is simple:

• The session admin leads the game
• The team votes on metric values for every item being introduced (based on the prioritization technique agreed upon)
• The final results are accepted, or votes are retaken  
  

While playing Foxly priority planning poker, you’ll be able to:

• View all issues up for prioritization
• See the people who have joined
• Access ticket details
• View the metrics panel
• Skip turns
• Submit votes

Once the backlog has been prioritized with the whole team, then comes the communication process.

How can I share results with my stakeholders?

Product managers manage the “why” behind the product strategy. They make sure that the strategy is driven by data they can show for, but that’s not all. They also need to communicate that strategy across the entire organization.

A product roadmap tool helps to:

• visualize and share backlog items based on stakeholder interest
• show, manage and analyze customer feedback
• assign tasks and track progress across the organization
  

This leads us to our second Jira plugin, a roadmap timeline app by the name of Swanly!

#3 Creating the product roadmap timeline

Every product manager has had to create a product roadmap at one point in time, in order to communicate the way their product vision should come to fruition. Now, whether they choose to showcase it in a simple PowerPoint presentation or through a more advanced product management standalone app is besides the point; both key problems remain:

• the information gets outdated rather quickly
• teams barely access the tool given the headache adoption usually is

Why use so many tools to do one thing?

It makes sense that most product managers would choose to manage their roadmaps in Jira itself, if the organization is already using it. Jira’s default roadmap is great for day-to-day work, plus teams are already used to working with it, i.e. very little adoption is needed.  

A Jira roadmap is actually the simplest way to track your Jira product backlog.  After all, the product roadmap would have to be adaptable to the constant changes in priorities; no spreadsheets, no documentation, nothing.

Just dear old roadmap and I.

How do you move backlog priorities into the roadmap and communicate progress with stakeholders?

Swanly: the product roadmap timeline app you didn’t know you needed

Your product data may be everywhere but why waste time looking for it?

Swanly is fully integrated with Jira, which means you get to skip on the absolute nightmare of moving the backlog back and forth by importing it entirely into this one roadmap; then go ahead and filter as you like to manage the information.

Once you’ve imported your data with the click of a button into this centralized hub that allows for cross-product, cross-team reporting, then you’re set. Yep, that’s how simple it is!

And as challenging as it may be to create a cross-product issue roadmap in Jira itself, Swanly makes it very simple; manage multiple products as separate projects, then select those products you wish to work with and plan stories for each of them in a single roadmap.

What can I do with Swanly - Jira Roadmap plugin?

• Visualize stories with templates and define your stages
• Separate story types with different colors for easier visualization, for example ; improvements to an existing feature or a completely new feature
• Customize your roadmap view by using filters to get, for example, stories only or epics in the view
• Use the zoom view to communicate different information:
• monthly zooming goes well with high-level overviews dedicated to stakeholders and customer success teams
• weekly zooming, with all of the stages expanded, goes well with development teams interested in the current phase of a feature and what’s coming next
• Use the reporting section to understand work progress; track anything from progress scope (status tracking, story points tracking, time tracking and burndown chart) to connected projects
• Create reports for teams and stakeholders on the spot and share easily
• Store stakeholder/customer feedback in a Jira project called “product feedback” then link them to relevant stories

And so it is…

We hope to have shed some light on how to go about prioritizing your product backlog in Jira, in a way that is simple, straightforward and that makes life easier for everyone involved; especially product managers.

Once every item on your backlog has a strategic reason to be there, reviewing that list regularly will be easy. Also, it’s rare that you’ll get the perfect prioritization framework match from the get-go; you may need to experiment a bit at first before locking in your process.

Once your backlog items are prioritized, simply import them into your product roadmap timeline so you can communicate the work, as well as plan, track and manage it.