Prioritization for product people

Prioritization, or more specifically deciding what you will and will not build, is a key product management activity.

It’s equally important for a tech product that your company sells as it is for an internal product that enables your company’s business processes.

You could even say that it is the most important activity that product people do.

But how you do it varies widely depending on your context. You take a different approach to deciding what you do when you’re building a new product than when you’re rebuilding an existing product that supports a key business process.

Here are some key points about prioritization in general.

I've included links to my newsletter on Substack that explore different scenarios.

Along the way, if you have questions about something I wrote, or disagree with it, let me know. You can also suggest a specific context you’d like to see me cover when talking about different ways to prioritize.

What Prioritization is

Prioritization, as it’s frequently used in the realm of digital product development, is an explicit decision about what your team will and will not do. When you’re determining the “right thing to build” you’re making a prioritization decision.

Actually, to determine the right thing to build, you should make a couple decisions. First, you need to decide the outcome you want to achieve, whether it’s a problem to solve or an opportunity to exploit. Then you decide which solution you’re going to try first.

That’s an important distinction. Most teams don’t consider the first decision and often forget they can make the second decision. That leads to an overflowing backlog where stuff doesn’t get done, but it’s not because the team explicitly decided not to do it. They just couldn’t get to it.

Now, let’s look at some key points about prioritization.

Prioritization and Priorities

A concept that frequently gets muddled with prioritization is the idea of priorities.

When organizations identify priorities, they are trying to communicate the most important actions, activities, products or services that the organization delivers.

Theoretically, you should consider your organization’s priorities when you’re trying to decide what to do and not do. The difficulty lies in that priorities are often vague and open to interpretation.

It also doesn’t help that most organizations identify multiple priorities. That has always seemed counter intuitive. How can multiple things be the most important?

If your organization has identified organizational priorities, it’s worth a conversation with your leadership to make sure you’re clear on what that collection of priorities are intended to convey.

Use priorities as filters, not buckets

Once you sufficiently understand your organizational priorities, they can be helpful for prioritization, if you use them in the right way.

You need to use them as filters, not buckets.

You use a priority as a filter when you use it to explicitly include or exclude an item from your roadmap.

Let’s say you have an organizational priority of “Fix Customer Support” and you’re trying to determine if you should undertake an initiative. Ask the question “Will this help us Fix Customer Support?” If the answer is (believably) yes, then you’d include that initiative on your roadmap.

If the answer is no, throw the idea in the trash bin.

When you use organizational priorities as buckets, your priorities become categories that you try to fit initiatives in. Often more than one. And it doesn’t matter what kind of contortions you have to go through to make them fit. You find yourself saying things like:

Oh sure, buying fidget spinners for the customer support agent fits in Fix Customer Support. Because, you know, they’re for customer support…

Riiight.

Hopefully you can see where trying to justify initiatives by categorizing them doesn’t necessarily help you decide which ones you will and won’t do.

Prioritization is not sequencing

I’ll admit I realized fairly recently that sequencing is not the same thing as prioritization (hat tip to Saeed Khan), at least how I’ve defined it above.

Both are important, but they accomplish different things.

Remember, prioritization is deciding which thing you’ll do and not do.

Sequencing is deciding what order you’ll do the things that you decided to do.

To make your sequencing job easier, make some prioritization decisions first - you’ll have less things to put in order.

Start with an outcome, not a list

Just like have fewer things to consider makes sequencing easier, prioritization decisions are easier when you have to decide between fewer things.

One way to have fewer things to consider is to start by deciding what outcome you’re going to achieve, then decide the first thing you want to try to reach that outcome.

This is probably different than how you’ve tried it in the past, where you’ve generate a whole lot of ideas, and then stared at in forelorn silence, wondering where you should start.

The trick is not to create your list until you know what you’re trying to accomplish. That will look different depending on your context, so I’ll go into that more when I discuss how to prioritize in different contexts.

You probably don’t need a prioritization framework.

When you do have a lot of things to prioritize, it can feel quite daunting. That’s where prioritization frameworks came into being.

There are several frameworks you can use to prioritize features.

Some frameworks have you score each feature based on a set of criteria. You then add the score up for each feature and then rank the features based on their scores. Voila! You have a stack ranked list.

Other frameworks have you group features based on some sort of criteria, or map them on a 2×2 matrix. Then there’s guidance which group or quadrant you work on first.

Prioritization frameworks may give you the appearance of an objective approach, they’re all fooling you. In order to come up with a score, or pick which group to put a feature in, you make a series of subjective choices.

And because those choices are subjective, when you do the math the framework calls for, they layer uncertainty on top of uncertainty, making any resulting score practically useless.

How do you prioritize without frameworks?

Well, it depends.

Are you creating a brand new product? Are you optimizing an existing product? Are you rebuilding a legacy product? Or do you have to make a slew of unrelated changes based on requests from your users?

The approach you take for one context will, by necessity differ from the approach you take for a different context. The secret to making effective priority decisions requires knowing what context you’re in and the useful prioritization techniques for that context.

Unfortunately, most articles about prioritization assume a certain context (usually one the author has experienced) and implies the prioritization technique that works in that situation will work anywhere.

I’ve found that’s not usually the case. So, I explored a few different scenarios in my email newsletter:

• A portfolio of epics
• Rebuilding a product
• New Product
• Product Optimization
• Feature refinement
• Stakeholder requests

If there’s a specific context you’d like some advice on, let me know in the comments.

Thanks for Reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.

Kent