Defining priorities

Published 2025-12-22

One of the simplest things you can do for any team is define a prioritization framework. Six rows and three columns, written once and reused daily.

Doing so has three benefits:

1/ The work is highly observable. At the team level, anyone can quickly understand “is team X working on important things” and the supporting rationale.

2/ No work is precious. At the individual level, managers and individual contributors can quickly determine trade-offs when new needs arise or priorities shift.

3/ The priority is the alignment. Publicly defining your framework and a project’s associated priority accelerates disagreement between stakeholders and discussion of missing context or changing facts.

My format is:

Priority level Intent Guidelines (the important part, examples below)
P0 Must do, urgently Unblocks corporate strategy, critical issue impacting most customers
P1 Must do Tied to a corporate objective, feature outage
P2 Should do Improvement to existing service or product
P3 Nice to have Quality of life fixes
Not applicable Not within scope Misalignment with team priorities, skillset, or capacity

All six rows are necessary:

  1. Header - Schema
  2. P0 - Overrides everything
  3. P1 - The default to negotiate from and review weekly
  4. P2 - Discuss when, not if, and review monthly
  5. P3 - Discuss if and review quarterly
  6. Not applicable - Stakeholders need to know when you’re saying no

The hard work goes into column three: the custom guidelines for your team or company. This is how your team(s) will evaluate their work.

A good framework creates decision-making consistency. A prioritization framework has lasting effects across all stages of a project, from scoping to building to shipping.