Prioritisation Is Not a Framework Problem. It's a Courage Problem.
Every PM I know has a prioritisation framework.
RICE. ICE. MoSCoW. Opportunity scoring. Weighted impact matrices. Some of them have more than one, a framework for quarterly planning, a different one for sprint-level decisions, a third one they use when everything goes sideways mid-quarter.
And yet, every PM I know also has a list of things that shouldn’t be on the roadmap and somehow are.
A feature requested by a big client that doesn’t serve anyone else. A project that’s been “strategically important” for three quarters without moving. Something the founder wants that the data doesn’t support. A thing that keeps getting reprioritised up not because the evidence changed, but because someone with a loud voice pushed for it again.
The frameworks didn’t fail. The courage to use them honestly did.
What prioritisation actually requires
A framework gives you a method for ranking things. What it can’t do, what no framework can do, is make the conversation that follows ranking them any easier.
Because once you’ve scored everything and the ranking is clear, you still have to go tell someone that their thing is not the most important thing. You still have to defend that ranking to a founder who cares deeply about a feature that scored low. You still have to explain to a client why the custom request they’re banking on isn’t in the next sprint.
That conversation takes something that isn’t methodology. It takes a willingness to have an uncomfortable meeting, to be temporarily unpopular, to hold a position when someone pushes back.
That’s not a skill gap. It’s a courage gap. And it’s much harder to fix with a Substack article than a scoring matrix.
The way it usually breaks down
What I’ve seen, in my own work and in teams I’ve been part of, is that the framework gets used honestly up to the point where the ranking is inconvenient and then quietly adjusted.
A feature that scored 12 gets bumped to “18 if you think about it differently.” A project that ranked fourth gets elevated to second because a stakeholder conversation went the wrong way and nobody wanted the friction of holding the line.
The framework becomes a prop. Something to point to when the decision was easy, and something to renegotiate when it wasn’t.
And the worst part is it’s not dishonesty exactly. It’s just the slow accumulation of avoiding the difficult conversation over and over, until the roadmap stops reflecting what the team actually believes and starts reflecting what was easiest to agree to.
The thing I try to remember
The most useful sentence I’ve found for prioritisation conversations is this one: “I want to understand what would change if we moved this up.”
Not combative. Not defensive. Just genuinely curious. Because sometimes the answer reveals real information I didn’t have, context about a customer situation, a dependency I’d missed, a market thing that genuinely changes the calculus. That’s useful. I want to know that.
But sometimes the answer is just “because I want it higher.” And then the conversation gets real and that’s the one worth having, even if it’s awkward.
The courage in prioritisation is mostly the courage to ask that question and to sit with whatever comes back.
A small reframe
If your roadmap feels cluttered with things that probably shouldn’t be there, it’s worth asking not just “what should we drop?” but “where did we not hold the line?”
Not as a blame exercise. But as a learning one.
Because the pattern is usually pretty consistent. There’s a person or a context that makes the conversation harder. There’s a kind of request that tends to get through when it shouldn’t. Naming that pattern is the first step to actually doing prioritisation rather than just doing prioritisation theatre.
The framework is a tool. The hard part was always the human conversation.