4 Prioritization Exercises To Improve Your Life as a PM (With Product Examples)

Knowing what work the development team should focus on when, and most importantly, WHY, and how this directly relates to customer outcomes and business outcomes is your main value add to the business as a product manager.

…but with product managers sitting at the intersection of UX, engineering, and business, plus other key stakeholders like marketing, sales, care, legal, finance, and more; it can often feel impossible to know how to answer these questions with confidence when they connect with so many different teams.

On top of the “bigger picture” ticket items in a roadmap, every product manager, whether brand new or with years of experience under their belt, knows the dreaded feeling of “paralysis by analysis” when faced with too many decisions in a short time frame.

It can often feel as though you’re firefighting when many teams and individuals are berating you with questions and decisions to make on a consistent basis.

Templates

Get started with
prioritization templates

Find template

While there’s a lot that can help with this, like thinking proactively, batching communication, and having a very clear product vision, strategy, and roadmap; no matter who you are or what industry you work in, small things will come up day-to-day with multiple team members that you will need to address.

Prioritization - one’s ability to arrange things by order of importance so that you can deal with the most important things first - is a crucial factor in this equation and will help you not only organize what to focus on, when, and why for your team, but also help you to be proactive in any communication around this to limit the quantity of posthoc stakeholder questions.

But here’s the thing - prioritization is a lot easier said than done, and many product managers face some barriers.

Barriers to your prioritization exercises

1. Decision paralysis: Overthinking decisions so much that you’re constantly churning, trying to gather more information, or stalling, which leaves you without having made any concrete decisions 

2. Decision fatigue: Our ability to make decisions dwindles as we face more and more decisions. Research shows that on a given day, we are freshest to make better quality decisions in the morning.

3. Poor understanding of their own swimlane (their breadth of roles and responsibilities within the larger product team): Not understanding where your responsibilities end and another product manager’s responsibilities begin can be a huge challenge in figuring out how to prioritize work because it blurs the lines of what is even being prioritized.

4. Procrastination: Delaying or postponing making decisions for a number of reasons - i.e. they are scary decisions for you to make, so you put it off, you don’t feel like you have the time to properly focus on making the decision, your self-esteem or limiting beliefs are standing in your way, etc. 

5. No mental model or known framework: This was one of my biggest challenges when I first started out as a product manager at a startup - there was no precedent for prioritization frameworks used in the organization, not as much product management content available online, and I had a hard time developing a mental model to understand what the “norm” was in terms of how to frame priority calls. 

6. Poor understanding of constraints: Limited knowledge of major milestones, resources, budget, regulatory constraints, etc. 

7. Poor understanding of the competitive landscape: Not knowing who your competitors are, what they have built that has worked well, and where opportunities and gaps are in the current market.

8. Poor understanding of customers: Not knowing the primary user persona you are focused on, and deeply understanding their needs, desires, beliefs, pain points, and general “jobs to be done”. 

(Check out the airfocus glossary section for more on prioritization and other common product management, product marketing, and agile development terms and definitions).

Newsletter

Cut through the clutter of
PM Content with our
bi-weekly digest

Sign up

4 prioritization exercises (with product examples)

Any tool for prioritization essentially boils down to value vs. effort.

How much value are you getting from the effort you are putting in?

Understanding basic prioritization frameworks and implementing some of the following very simple prioritization exercises in your days, weeks, and quarters, can help substantially.

1. The Eisenhower Matrix: 

The Eisenhower Matrix is sometimes called the “Urgent-Important Matrix” and was developed by Dwight D. Eisenhower (the 34th U.S. President) to help him organize his decision-making and determine what to focus on. This can be a great tool for product managers to filter their focus and can be applied to product features as a way of understanding what items to include in your immediate roadmap, what to schedule in for later, what to delegate, and what not to focus on or to remove from your plate.

Product examples for the Eisenhower Matrix:

• It’s the end of Q4, and you know your roadmap needs to be updated by the beginning of Q2. This work would fall under important but not urgent. 

• The platform that you manage as a product lead has unexpectedly gone down and no users are currently able to access it. The work to address this would fall under important and urgent.

• Several tickets in JIRA need to be tagged to better organize the upcoming sprint planning session tomorrow with the team. This is something that your project manager can help with and could fall under urgent and not important that you could delegate to them. 

• A member of the sales team sends you a DM on Slack to ask if you can help him find a missing adapter required for him to run a product demo for some volunteers at a conference - you don’t know where it is so you would likely not be of any help. This would fall under “don’t do”

2. MoSCoW prioritization:

MoSCoW prioritization stands for Must-have, Should-have, Could-have, and Won’t-have. It’s slightly confusing because the O’s are just added in as filler so it’s easier to pronounce. Another way to think of MoSCoW is simply - Must, Should, Could, Won’t. 

Must: Bare bones essentials to make your product or the particular focus you are working on “operational”.

Should: Things you should work on that allow you to meet a minimal threshold (i.e. in the market, in your org).

Could: “Icing on the cake” things you could work on that aren’t essential but would add value to customers, your organization, or your team if added.

Won’t: Out of scope - taking things away is the only way to focus on the things that matter most. 

https://www.youtube.com/watch?v=NJ2JM_PKXjk&t=10s

Product examples for MoSCoW:

• You’re building a mobile banking app, and some of the features you’re considering include:

  • Must-Have: 

    • Account creation // editing // deletion

    • Secure log-In 

    • 2-Factor authentication

    • Within-bank transactions (i.e. One account under one user to a different account under that same user)

    • Bank-to-bank transactions

    • Add-a-payee

    • View basic account information (i.e. profile information, transaction limits)

    • View transactions

    • View payment history

    • Basic analytics

    • Protection of PII

    • Security alerts

  • Should-Have: 

    • Basic notifications

    • E-transfers

    • View and print tax documentation

    • Transfer money cross-border

  • Could-Have:

    • View credit score

    • Smart visualization tools

  • Won’t-Have:

    • Investing and trading Functionality

    • Credit Card Functionality 

    • Tap-to-Pay

• You’re organizing your week, and it looks like this:

  • Must-do:

    • Scope review deck and meeting agenda

    • Prepare backlog

    • Update roadmap

    • 3 Customer interviews

    • Provide feedback on updated UX prototypes

    • 1:1s with direct manager and key team members

  • Should-do:

    • Product discovery framework

    • Sync up with sales and marketing

    • Finish PRD for purchasing flow

  • Could-Do:

    • Update the product development process document

    • Sync up with sales to gather feedback from prospective customers

  • Won’t Do:

    • Sync with the care team (can do this next week)

    • Create opportunities deck (can do next month)

    • Update product pillars (need feedback from design first)

    • ML deep-dive (come up with a better game plan for this next week)

    • Update Asana Format (can do this next week)

    • Explore alternatives for payment partners (can do this next week)

3. The 2-minute rule: 

As humans, our reality is largely shaped by our perception - of events, people, and the world around us. This can cause there to be large gaps between the changes we want to make and actually making them.

One simple way to approach avoiding both procrastinating and “paralysis by analysis” is to break things down into actionable steps to help us move towards our desired outcomes that can be completed in less than 2 minutes. 

In the words of habit-forming expert James Clear, “Read before bed each night” becomes ‘Read one page’. ‘Do thirty minutes of yoga’ becomes ‘Take out my yoga mat.’, ‘Study for class’ becomes ‘Open my notes.’.” If you can master the act of showing up to make decisions, even small ones, you’ll make this an ingrained habit vs. something that you avoid like the plague.

Product examples for the 2-minute rule:

• Problem: Misalignment within your team; Solution: TLDR update sent out weekly that you can write in 2 minutes or less that includes: “Headline”, “Priorities Right Now”, “What I’m Blocked By”, “What I’m Concerned About”

• Problem: New work items keep coming into your work stream/product area that don’t fit with the current priorities; Solution: Keep a saying no template handy that you can use to limit the effort you’re putting into responding to ad-hoc requests like this (i.e. Here are 7 saying no email templates and templates to help you say no in any situation).

• Problem: Unfocused meetings are eating up way too much of your time; Solution: Draft a simple meeting agenda that outlines: 

1. Why the meeting is happening (what is the purpose of it?)

2. The desired outcome

3. What invitees are expected to do to prepare in advance (i.e. read a document, bring in outstanding questions)

4. What invitees are expected to contribute (i.e. feedback in a particular area, action items assigned to them)

4. The 80/20 rule:

Also called “The Pareto Principle”, named after the economist Vilfredo Pareto, the 80/20 rule is frequently applied in business and economics and can also be applied in product work, states that 80% of outcomes (or outputs) result from 20% of all causes (or inputs) for any given event. Another way of viewing this through a product lens is:

“80% of delivered value usually comes from 20% of your efforts.”

Or, even more simply, “More work does not always mean more value.”

Working smartly and pausing to identify where the 20% is coming from, can help you figure out where to focus and why.

A great example of this is products that have actually increased their value and top-line product metrics by removing features and doubling down on the ones that work. i.e. Slack “unshipping” their remote screen control feature due to its low adoption, high cost, and complexity to maintain.

This can also be applied to team productivity and decision-making.

Product examples for the 80/20 rule:

• Bug reports: Which bugs are causing most of the problems customers are having with your product? Do some of them overlap or stem from the same root cause? That’s where you should focus vs. trying to fix all of them at once.

• New Releases: With your recent releases, which product features are being used the most vs. the least? Which of the least used features require the most overhead and ongoing maintenance? Consider removing these from the product.

• Processes: Which of your internal product development processes are helping the team the most? Which are hindering or causing unneeded overhead work? Consider streamlining processes so that the processes that are in place are helping the team significantly and the overhead processes are removed. 

Additional tips for prioritization exercises

• If you are prioritizing with a team, ship your prioritization framework around so others know how decisions are being made so it’s clear and transparent

• If you try one method of prioritizing and find that it doesn’t work for you, don’t be afraid to experiment and try new methods to find something that does

• Don’t be scared to adapt any of these exercises to better mesh with your unique context and constraints

• Make prioritization exercises fun! I.e. Check out our Priority Poker Guide

Prioritization checklist

1. Pick one of the prioritization exercises above to try implementing this upcoming work-week

2. Schedule one 15-minute time slot where you are planning your week (for yourself and your team) using your chosen prioritization exercise

3. Schedule one 15-minute time slot to de-brief and understand what went well with your prioritization decisions, what didn’t, why, and what you can do differently going into next week

Additional Prioritization Resources

• Product Prioritization Tool by airfocus

• Product at hypergrowth: prioritization for fast-scaling startups by Ketki Duvvuru

• The Ultimate Guide to Prioritization by airfocus

• Timeboxing: Why It Works and How to Get Started in 2023 by Nir Eyal

• How to Prioritize Product Tasks Effectively by Sami Rehman

• The First Rule of Prioritization: No Snacking by Des Traynor (Intercom)

• How to Prioritize When Everything Seems Important by Zapier

• Prioritization Shouldn't Be Hard by Melissa Perri

• 20 Product Prioritization Techniques: A Map and Guided Tour by Folding Burritos

Templates

Get started with
prioritization templates

Find template