Prioritisation is a system, not a gut feeling

Most prioritisation conversations start in the wrong place.

The question teams usually ask is: what should we build next? The question they should be asking is: what do we know, what don't we know, and what's the most important thing to find out? Prioritisation isn't a ranking exercise. It's a decision about where to focus given incomplete information.

When teams treat it as a ranking exercise, they end up with a backlog that reflects opinions rather than evidence. The loudest voice wins. The most recent customer complaint jumps the queue. The CEO's pet feature gets moved to the top. And the team spends more time managing the list than making progress on what matters.

Make it a system, not a conversation

The value of a prioritisation framework isn't that it makes the decision for you. It's that it gives the team a shared language for the decision — one that's harder to override on instinct.

MoSCoW works best when you need fast, shared decisions about what ships in a given cycle. Must-have, should-have, could-have, won't-have. Simple enough that non-PM stakeholders can engage with it. The failure mode: letting the must-have category get crowded. If everything is a must-have, you've just renamed your full backlog. Hold the line on that category and MoSCoW works. Let it slip and it's useless.

RICE — Reach, Impact, Confidence, Effort — is the most rigorous option when you have real data to populate it with. The problem at early stage is that you usually don't. Reach is a guess. Impact is a gut feeling with a number attached. Confidence is almost always optimistic. At that point RICE produces false precision — a spreadsheet that looks objective but isn't. Use it when the data is real. Before that, MoSCoW is more honest.

Kano is the most underused of the three and the most valuable for understanding what users actually feel rather than what you think they should feel. It separates features into must-be quality, performance, and delighters. The most useful thing it does: reveal the must-be features you're underinvesting in because you're focused on the exciting new stuff.

The backlog is a strategy problem

A bloated backlog isn't a list problem. It's a sign that the team hasn't made hard decisions about what the product is and isn't trying to do.

Every item on the backlog should be traceable to a real user need or a clear business outcome. If it can't be, that's worth knowing before it sits on the list for six months. A regular backlog review — not to groom tickets, but to honestly ask whether each item still deserves to be there — is one of the most useful things a PM can do.

Cut the list. Make it reflect what you actually believe. A short, honest backlog is more useful than a long, aspirational one.

The honest version

No framework makes the decision for you. They help you structure the conversation and make the decision more defensible — but the judgment still belongs to you.

The real skill in prioritisation isn't knowing the frameworks. It's knowing which one to reach for given the stage you're at, the data you have, and the team you're working with. Pick the one that fits. Apply it honestly. And be willing to override it when the signal from users is strong enough to justify it.

For a deeper dive on each framework — MoSCoW, RICE, and Kano — and when each one fails, I've written about the frameworks that actually hold up. And if the backlog itself is being driven by stakeholder requests more than user evidence, building for the user, not the roadmap is the companion to this.