The criterion you’re already using (and why it’s urgency)
Why most prioritisation frameworks fail, and what to build instead.
Ask a team how they prioritise and you’ll get the polished answer: strategic alignment, expected impact, timing, customer value. Ask them again, more carefully, and insist they describe what actually happens rather than what should happen. The answer changes.
Urgency. Seniority. Who asked last.
These are the real prioritisation criteria in most organisations. Not because people lack discipline, but because these are the criteria that the system rewards. Urgency gets attention because the system has no intake filter to slow it down. Seniority drives decisions because there is no shared framework that gives a team legitimate grounds to push back. Who asked last wins because there is no visible record of what was already committed.
The official criteria exist in a strategy document somewhere. The real criteria exist in the habits of every working week. And the real criteria win every time, because they operate at the speed of the system while the official criteria sit in a deck nobody opens.
Why prioritisation criteria frameworks fail
Most prioritisation criteria interventions start by defining a list. A working group books a meeting room, spends ninety minutes debating what matters most, and produces a slide: strategic alignment, impact, feasibility, timing, risk. The slide gets approved. It goes into a governance deck. And within a planning cycle, nobody opens the deck.
The problem is that nobody in that meeting room has ever used those criteria to make a hard call. The list describes what the organisation believes should matter, not what the room has experienced mattering. There is no muscle memory behind the words. The first time a senior stakeholder sends a message marked urgent, the list disappears. Aspirational criteria collapse under real pressure because there is nothing holding them in place.
The alternative is to build criteria from experience rather than theory. And that requires doing something counterintuitive: making the trade-offs first, then extracting the criteria from what the room just did.
Trade-offs first, criteria second
Before anyone in the room talked about criteria, we ran the trade-off exercise. Cross-functional teams, brand strategy leads and operational delivery people at the same table, sorted their real initiatives into six columns on the wall: must progress now, should progress next, can wait, challenge and re-scope, pause, decline. Every table had to move at least two initiatives out of the top column.
The exercise forced every table to articulate, out loud, the reasoning behind each decision. “This one stays because it has a regulatory deadline.” “This one moves down because we don’t have the dependency resolved.” “This one gets paused because the brief changed twice and nobody has re-scoped it.”
After the exercise, one question: based on what you just did, what criteria were you actually using to make those calls?
The room didn’t need a framework. They had just built one, in practice, under pressure, with real work. The prioritisation criteria that emerged were grounded in lived experience: regulatory or compliance deadline, dependency readiness, brief stability, named owner with authority, visible team capacity. These were not aspirational. They were the criteria the room had already applied ten minutes earlier.
The difference between criteria built from theory and criteria built from experience is the difference between a poster on a wall and a tool in someone’s hand. One gets admired. The other gets used.
The criterion nobody wants to name
In every criteria conversation, there is one criterion the room will avoid unless someone names it first: seniority of the requester.
Every team in every organisation knows that a request from a VP carries different weight than a request from a peer. This is not a secret. It operates in every intake conversation, every planning meeting, every mid-cycle reprioritisation. But it is almost never named as a criterion, because naming it feels political.
Leaving it unnamed is worse. When seniority operates invisibly, it overrides every other criterion without accountability. A team that has just agreed that “dependency readiness” is their second most important filter will quietly abandon it the moment a senior leader sends a message marked urgent. The prioritisation criteria they built collapse, not because they were wrong, but because the invisible criterion was stronger.
The fix is simple and uncomfortable: put it on the table. Name it. “Seniority of requester” belongs on the criteria list, visibly, so the room can decide together how much weight it carries relative to the other filters. A team that has explicitly agreed that seniority is the third most important factor (after regulatory deadline and dependency readiness) has something to point to when the override arrives. A team that has left it unnamed has nothing.
This is not about removing seniority as a factor. It is about making it visible so it can be weighed rather than defaulted to.
The entry filter that protects everything you just built
Prioritisation criteria are only as durable as the intake system that enforces them. Without an entry filter, new work arrives and bypasses the criteria entirely. Someone sends a message, a team says yes, and the prioritised list shifts without anyone noticing.
Entry criteria define what must be true before work enters the system. Not “is this a good idea?” but three concrete questions: is there a named owner with authority to make decisions? Is there a named trade-off, meaning what gets displaced if this enters? And are the dependencies identified?
Here is what that looks like in practice. A senior stakeholder sends a request mid-cycle: “Can your team take on this campaign brief?” Before the entry filter, the team says yes, absorbs the work, and something else quietly slips. After the entry filter, the response is different: “We can look at this. Who owns it? What comes off the board to make room? And do we have the inputs we need, or are we waiting on another team?” The request doesn’t get rejected. It gets clarified. And that clarification is what protects everything the room already agreed to.
This sounds rigid. In practice, it is the most protective piece of scaffolding a team can build. It doesn’t slow good work down. It slows bad intake down: the half-formed requests, the mid-cycle surprises, the “can your team just pick this up?” asks that arrive without scope, without a trade-off, and without any acknowledgement of what they displace.
The entry filter is what prevents the prioritisation criteria from being theoretical. It forces every new piece of work to be evaluated against what the room agreed to, before it enters the system rather than after it has already disrupted it.
What to do if your team’s real criteria are invisible
Start by asking the honest question. Not “what criteria should we use?” but “what criteria are we actually using, whether we admit it or not?”
If the answer is urgency, seniority, and who asked last, that is not a failure. That is a diagnosis. Those criteria exist because the system rewards them and offers no alternative.
Build the alternative from experience, not theory. Run a trade-off exercise with real work before you define prioritisation criteria. Extract the criteria from what the room actually did. Name the uncomfortable ones. Then protect the criteria with an entry filter that forces new work to be evaluated before it enters the system.
Prioritisation criteria built from lived experience stick because the room has already used them. Prioritisation criteria imposed from a framework fail because nobody has.
This is the fourth in a series on the structures underneath good prioritisation. Previously: Prioritisation is a scaffolding problem, What your team knows about prioritisation, and The wall where the hidden rules live. Next: who can say yes, and does everyone know it?