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.

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.

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.