Leadership teams run prioritisation exercises regularly during a quarter. RICE scores, updated inputs, a fresh workshop each time. The output barely moved: the same three items land near the top, in about the same order, every time. And every time, the same three items still don’t ship, or deliver outcomes. Nobody blames the scoring. They blame the prioritization framework for not being followed closely enough, and schedule another workshop to do the same thing, expecting it to fix that.
That workshop was never going to fix it, because the framework’s implementation was never the problem.
Two different questions, one label
John Cutler makes a distinction worth understanding: prioritization judgement and prioritization-as-enacted are not the same activity, even though most teams run a single meeting for both and call the whole thing “prioritization.”
Judgement is the easy part. Put smart, informed people in a room and they will converge on roughly the same list of what deserves attention. Most experienced product leaders, engineers and executives, looking at the same roadmap, will agree on the top five items within a reasonable margin. That agreement is truly useful. It also does not determine what actually happens next quarter.
Enactment is what happens after the meeting: which of those five items someone stops doing something else to protect, which one quietly loses its champion the moment a louder problem shows up, and which one survives three reprioritizations without ever being properly killed or properly shipped. Enactment runs on conviction, politics and who in the room was willing to be the person who said no, we are stopping this. None of that shows up in a scoring model.
Why nobody retros the framework
Postmortems ask what went wrong with the work. They almost never ask what went wrong with the decision to prioritize it in the first place, and when they do, the conversation stays at the level of the scoring inputs: were the reach numbers right? Was the confidence rating too generous? Nobody asks the harder question: given that everyone agreed on the ranking, why didn’t the ranking survive contact with the quarter?
That question is uncomfortable in a specific way. Answering it honestly means naming who protected their own item and who let theirs go, which reads as a personal critique rather than a process critique. A scoring model is safer to interrogate than a person’s actions, so that is what gets interrogated, quarter after quarter, while the actual mechanism of enactment goes completely unexamined.
What enactment without politics looks like
Jane Street reportedly runs its internal GPU cluster on live auction rather than committee allocation. Researchers bid against each other for compute. No approvals, no allocation meetings, no manager deciding whose model matters more this quarter. The cluster is globally visible: anyone can see what anyone else is running, and anyone can pause a job that is clearly losing its bid. One researcher accidentally reset every bid on the cluster running a command without arguments, which is its own argument for guard rails, but the underlying idea survived the incident: visibility replaced the manager.
Treat that as illustrative rather than an example, not least because at least one reply in the thread claims the practice has since been dropped as inefficient. What it illustrates regardless: enactment is not a scoring problem, it is a visibility and stakes problem. A market forces the trade-off into the open and makes someone actually pay for holding onto a low-value job. A quarterly roadmap review, by contrast, lets everyone nod at the same ranked list and then go back to protecting whatever they were already protecting, because nothing about agreeing to the list cost anyone anything.
This is the same failure I described when I wrote about why judgment that never gets written down doesn’t scale past the person who holds it: the criteria that govern a decision live in what people override under pressure, not in what they agree to on a whiteboard. Prioritization judgement is the whiteboard version. Enactment is the override.
The retro nobody runs
None of this is an argument for scrapping scoring models, any more than Goodhart’s Law is an argument against metrics. It is an argument for retrospecting the right layer. Instead of asking did we prioritise correctly, ask: why has our process repeatedly produced this same tension, and what would it take to get our people, specifically, to finally resolve it?
That question names individual persons, not formulas. It asks who has been allowed to keep something alive by never quite saying no to it, and what would have to change for that to become expensive instead of free. A framework can survive being run a hundred times. A tension that nobody is willing to name rarely survives being asked directly.
Which recurring fight on your roadmap have you rescored more times than you’ve actually resolved?
Leave a Reply