The difficult part of prioritisation isn't calculating a score. It's taking responsibility for the consequences of choosing one future over another.
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.
Opportunity cost is not an abstraction. It has a name, a team and a quarter attached to it.
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.
Write the trade-off line before the meeting, not during it. If you cannot complete the sentence "we are choosing X, which means Y waits until Z", the decision isn't finished and the meeting will finish it for you.
One useful product idea, once a week.
If this was useful, the newsletter develops one idea like it more deeply each week.
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.
Prioritisation becomes leadership the moment somebody important dislikes the answer.
- Cost-of-delay reasoning is the most useful of the common models, mainly because it forces a conversation about time rather than value.
- "Attention" here means recurring decision capacity, not headcount. Teams can be fully staffed and still be unable to decide.