Feature prioritisation frameworks that actually hold up

Every PM knows the frameworks. RICE, MoSCoW, Kano — they're in every product course, every PM interview, every roadmap conversation. The problem isn't that teams don't know they exist. It's that most teams apply them wrong, or apply the wrong one for the situation they're actually in.

Here's how I actually use them — and when I don't.

MoSCoW — best for early stage, worst when misused

MoSCoW works when you need a fast, shared decision about what ships in this cycle and what doesn't. Must-have, should-have, could-have, won't-have. Simple categories, easy for non-PM stakeholders to understand, quick to apply.

The problem: at early stage, everything feels like a must-have. The founder wants it all. The engineer has opinions. The sales team has promises they've already made. If you let the must-have category get crowded, MoSCoW stops working — you've just renamed your full backlog.

The fix is brutal honesty about the must-have category. If removing a feature wouldn't cause the launch to fail, it's not a must-have. Hold that line.

RICE — best when you have data, useless when you don't

RICE — Reach, Impact, Confidence, Effort — is the most rigorous prioritisation framework most product teams have access to. When you have real data to plug in, it produces defensible, consistent decisions that are hard to argue with subjectively.

The catch: it requires data you often don't have at early stage. Reach is guesswork. Impact is a gut feeling with a number attached. Confidence is usually optimistic. At that point RICE becomes theatre — a spreadsheet that gives false precision to decisions you're still making on instinct.

Use RICE when you have enough user data and usage metrics to populate it honestly. Before that, MoSCoW is more useful precisely because it doesn't pretend to be scientific.

Kano — underused, and the most honest of the three

The Kano model divides features into three categories: must-be quality (users expect it, won't notice if it's there, will notice if it's not), performance (more is better), and delighters (unexpected, creates satisfaction above expectation).

Most teams skip Kano because it requires user research to apply properly. That's also exactly why it's valuable — it forces you to ask what users actually feel about a feature, not what you think they should feel.

The most useful thing Kano does is identify the must-be features you're underinvesting in. Teams consistently over-prioritise delighters — the exciting new stuff — and underinvest in the baseline that users expect to just work. Kano makes that gap visible.

The honest version

No framework makes the decision for you. They all 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. Early stage with limited data — MoSCoW. Growth stage with real usage metrics — RICE. Trying to understand what users actually value — Kano.

Pick the one that fits the situation. Apply it honestly. And be willing to override it when the signal from users is strong enough to justify it.

For the broader system around prioritisation — including backlog health and when to override frameworks — I've written about making prioritisation a system. And if your PM practice is outgrowing its current setup, this covers how to scale before things break.