01 The framework isn't the decision

Every product organisation I've worked in has a prioritisation framework. RICE, weighted scoring, cost of delay, a bespoke spreadsheet with six columns and a tab nobody opens. They are useful. They give a group of people a shared language for comparing things that are not naturally comparable, and they make reasoning visible instead of private.

What they don't do is make the decision. A framework structures a conversation. It cannot absorb accountability. When the model produces a ranking, somebody still has to look at the third row and say: not this quarter. That sentence is the actual work, and no scoring method has ever made it easier to say.

The tell is what happens when the output is inconvenient. If the number says one thing and the room wants another, teams rarely revisit the reasoning. They revisit the weights.

02 Every yes creates a hidden no

A roadmap is usually presented as a list of commitments. It is more honestly read as a list of refusals. When you commit a team to one initiative, you have simultaneously declined everything that competed for the same engineering weeks, and those refusals are almost never written down anywhere a stakeholder can see them.

Making the hidden nos explicit changes the conversation from taste to trade-off. It also changes who can argue with you: it is difficult to dispute a ranking, and much easier to dispute a claim that platform resilience can wait one more quarter. That argument is the one worth having.

03 Prioritisation is an allocation of organisational attention

Engineering time is the constraint teams talk about. It is rarely the binding one. The scarcer resources are leadership attention, decision bandwidth, and the organisation's willingness to tolerate one more unfinished thing. A roadmap that fits the engineering capacity but exceeds the organisation's capacity to make decisions will still fail, quietly, in the form of things that are technically in progress and practically stalled.

Treating prioritisation as allocation forces three questions that scoring models tend to hide: what are we withdrawing attention from, who will notice, and what will we do when they escalate.

04 When stakeholder power enters the model

Frameworks assume requests arrive with equal standing. They do not. A request from the executive who owns the revenue number carries different weight from an identical request logged by a support lead, and pretending otherwise is how product teams lose credibility twice: once for ignoring power, and once for being surprised by it.

05 What good product leadership looks like

The teams I've seen handle this well are not the ones with the most sophisticated model. They are the ones who can explain a decision in five moves, in public, without defensiveness.

06 The conversation after the spreadsheet

The part of this job that gets remembered is not the analysis. It is the twenty minutes after it, when a person who genuinely needs something is told they are not getting it, and hears a reason that respects their problem. Do that consistently and your next difficult decision costs less political capital, because people believe the process even when they dislike the output.

That is the whole skill. Not the model. The willingness to hold a position you can defend, and to change it when the evidence rather than the volume changes.

Here is the idea. A roadmap is a list of refusals wearing the costume of a list of plans. Every committed initiative consumes engineering weeks that other work needed, and the refusals almost never appear in the document. So the team gets credit for the commitments and takes the blame for the deferrals, which nobody agreed to explicitly.

The fix is not a better model. It is one extra column: what this displaces. Adding it changes the meeting from a defence of your ranking into a shared decision about allocation, and it moves the argument to where it belongs.

Try it in the next planning session. Write the displacement line for your top three commitments before anyone else speaks.

— Genesis