The Simple Elegance of Priority Stack Ranking

Teams are already prioritizing their roadmaps; but often with incomplete data and flawed assumptions

Photo by Chris Lawton on Unsplash

There’s a nameless prioritization system which defines roadmap, project or features using a system resembling the following:

• p0: Must-ship
• p1: Should-ship
• p2: Would be nice

One of the amazing things about this system is that it can be implemented in a manner which tells teams almost nothing.

I have been a part of multiple organizations which use this system to steer engineering roadmaps, where the labels are decided strictly by the accompanying product manager or feature owner. The stakes are high, especially when working with over-leveraged engineering teams relying on this guidance for roadmaps.

Naturally, the end state was that everything was a p0 and any well-intentioned and honest project owner who labeled a task as p1 learned quickly that we have no time for p1 projects.

The lack of a central authority for this prioritization meant it was leveraged for peoples’ own localized objectives. When some p0 project couldn’t be delivered, escalations and arguments ensued. In an attempt to make it appear that teams were doing their best supporting the suite of must-ship projects, engineering managers smeared fractional engineers across the entire portfolio of dependent projects, to their own detriment.

This situation led to endless handwringing about how to “do less”, while failing to do anything structurally significant about the planning system which imposed these conditions on the organization.

The reality is, there’s always more work to do than what can be reasonably completed, and projects get dropped. Dropped projects tend to be either the less important, or less urgent projects — even if they are a p0.

Projects A-D are all must-ship p0s; we might have a vague understanding of their relative importance but likely need to go consult with others to be sure, if we need to pull resources in to surge-fund one of them

What this means is that even within the broad swath of high-priority efforts, there’s an implicit project-by-project ranking. It often just takes effort to uncover what that is, usually during conflict. Imagine the time that could be saved by making those decisions upfront and communicating them transparently.

Priority stack ranking is the process of precisely laying out the specifics of which projects are more, or less, important than others. This prioritization system should follow a strategy. There are three reasons this approach is effective:

1. It eliminates any ambiguity within teams about the most important work to be done. For a given time period if project A is listed above project B , everybody understands where we should spend more time and attention
2. It clearly identifies the least important work being done. If we need to pull in resources to support top-priority project A above, modulo expertise and timing issues, we’d pull from bottom-ranked project Z , and we wouldn’t need a reprioritization exercise to do it. Absent the clarity of this stack ranking, it feels somewhat arbitrary to declare a project defunded in favor of another, so it rarely gets done
3. It forces a principled approach to establishing and communicating the most important outcomes and supporting projects for the organization; something organizations can sadly get by without, as described earlier. This requires, and reinforces, solid cross-functional partnership between engineering, product, design, and others.

Within the band of previously-labeled must-ship p0 projects, we’ve identified the relative importance of the projects within that bucket; its clear where we’d cut scope or pull resources from

Principles and clarity are key; and make for an efficient and effective organization. When building a roadmap, it gives clear signal for how to cross-prioritize potential projects and initiatives. We can fund roadmaps with the project list from top to bottom; and if any of the truly must-ship projects are underfunded, a conversation can be had about pulling from the bottom of the list.

Priority stack ranks can be contentious, especially if you or your team tend to live near the bottom. While that’s a tough spot to be in, benefiting from prioritization obscurity produced by less clear systems doesn’t help the broader organization.

Common pushback includes:

This system is too complex for our portfolio of work

Perhaps; as with any system or process, it should be balanced against the needs of the org. But my earlier point still stands: there’s already an implicit and probably inefficient work ranking in use, it’s just locked up in peoples’ heads or Slack DMs, and inconsistent across the organization.

This system reduces team autonomy

The work being done by teams should already be aligned towards global outcomes. If ranking individual projects or features is too specific, the stack ranking could instead focus on time-bounded strategic outcomes, or a level lower focusing on the initiatives, which can then be used to influence how teams allocate their time. In my experience, the theoretical autonomy allocated to teams without explicit prioritization guidance from leadership is instead eroded by localized prioritization and resource contention lower in the org chart.

This system is too expensive to build or maintain

I think there’s benefit in defining a stack rank of just the top-N objectives or outcomes, where N is context-dependent. Sometimes just the major strategic outcomes require this kind of clarity, while other work can be left to the teams to sort out.

In the end, people are working on things they think are important, and that can be the result of having clearly-articulated global priorities, or it can be the result of guesswork. Producing a stack rank of priorities and forcing conversations about tradeoffs upfront is hard, but it provides clarity and principles that facilitate decision making in an efficient and scaled way.