Prioritization is picking what you do and don’t build

You may have noticed a swing toward CRM/business-systems content this summer. I’m bringing back more of the classic PM/PO/BA material this fall too, starting with a refresh on a topic I originally explored before moving to Substack.

An overview of priority

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.

In several issues of InsideProduct before moving to Substack, I explored prioritization from a variety of different contexts. This post sets those others up with some thoughts on key points about prioritization.

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

What Prioritization is

Perhaps it’s time, as Rich Mironov suggests, to retire the word prioritization.

Prioritization, as it’s frequently used in the realm of internal products and business systems, 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 of 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 for the problems you decide to solve.

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. Unfortunately, priorities are often vague and open to interpretation.

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

Take Target’s four growth priorities from March 2026.

Do those help you make clear decisions?

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

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 as buckets.

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

Think back to Target’s strategic priorities.

Those four strategic priorities, the way they’re worded, act as buckets. I can imagine people seeking funding for their pet projects contorting the English language in novel ways to explain how that project “meets” multiple priorities. Think how easy it is to explain how you plan to use AI to elevate the guest experience and accelerate technology. At the same time no less!

Turns out a little later in the press release, Target did provide more useful information:

Buried in this paragraph, which was probably intended as an introduction to a list of initiatives, is a clear decision filter: Will this improve life for busy families?

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 things 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 fewer things to put in order.

Start with an outcome, not a list

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

To have fewer things to consider, 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 from how you’ve tried it in the past. Admit it, you’ve been in a situation before where you’ve generated a lot of ideas, and then stared at in forlorn 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 don’t need a prioritization framework

When you 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 require you to score each feature based on a set of criteria. You then add up the scores for each feature and 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 on which group or quadrant you work on first. Who doesn’t like a good 2×2 matrix?

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 took it upon myself to describe prioritization in a few different contexts. Here’s a sample.

Hit reply and let me know about your preferred approach to prioritization. Just note the context in which it works best.