In a project organization, prioritization often happens when we decide what should be included in a project. We have requirements, features, or solutions and need to determine what can fit within a limited timeframe and budget.
A natural way to do this is to classify the work: High, Medium, or Low, Must, Should, or Could. This helps us distinguish what needs to be part of the delivery from what we can leave out if time or money runs short. Several things can be High or Must at the same time. There is nothing strange about that. We are primarily trying to decide what should be included in the scope we plan to deliver.
When we organize development around product teams, the question changes. We work towards desired outcomes and need to decide which outcome matters most right now and where to focus our capacity.
To make that choice, we need some shared principles for prioritization. Strategic importance may matter, as well as expected impact, time criticality, risk, or how much capacity something requires. The exact principles matter less than agreeing on them before we start arguing for the things we each care about most.
Prioritization really begins when we compare alternatives. What happens if we delay one while pursuing another? What does waiting cost us? What do we gain from the order we choose, and what do we postpone as a result? This is the kind of economic thinking behind approaches such as Cost of Delay and Weighted Shortest Job First.
But when we move from organizing development in projects to working in product teams, a familiar way of prioritizing often comes with us. Requirements and solutions may have been replaced by Epics describing desired outcomes, but we continue to prioritize them in much the same way:
Increase customer loyalty: High.
Reduce onboarding time: High.
Reduce recurring production incidents: High.
Increase self-service: Medium.
It looks like we have prioritized our Epics. But which one should we focus on first?
When each Epic is assessed on its own, it is easy for almost everything to become High. Customer loyalty is critical to the business, onboarding problems are causing us to lose customers, and production incidents cost money and create frustration. Self-service could free up significant capacity. They all have good arguments. And if Low effectively means not now and perhaps never, there is a strong incentive to make sure your own Epic is at least Medium, preferably High.
Before long, we may have five Highs, three Mediums, and one Low. We have spent a lot of time prioritizing, but we still haven’t decided what should come first.
We have classified how important things are. We haven’t prioritized between them.
A clear priority order, or stack ranking, forces a different decision. Not because 1, 2, and 3 are better labels than High, Medium, and Low, but because something actually has to come before something else. If one thing moves up, another has to move down.
Two things can both be High. They cannot both be first.
This does not mean the order becomes a new plan for the future. As we learn more, achieve outcomes, or circumstances change, the order can change too. It simply represents our best decision right now about where to focus our limited capacity.
The Classification Trap in Prioritization occurs when we prioritize each Epic on its own, when what we really need to do is prioritize between them.
More traps
The Negotiation Trap in Prioritization is one of several traps in the series Traps when moving from projects to product teams.
See the bigger picture
The classification trap in prioritization is one example of what can happen when we change the way we work without fully changing the underlying logic.
Our Project vs Product Organization in a Nutshell poster explores this shift from several perspectives including strategy, execution, governance, teams, funding, culture and organization.
