Feature prioritization frameworks: RICE, MoSCoW, and the signal they miss

Here is a spot every product team lands in eventually. You have 300-odd open feature requests, room on the roadmap for maybe eight of them this quarter, and a meeting on Thursday where everyone shows up to lobby for their favorite. So you go looking for a system. Something objective. A framework that turns the pile into a ranked list that ends the argument.

The good news: those frameworks exist, and the popular ones are genuinely good. The catch: nearly all of them share one blind spot, and if you do not patch it, they will happily optimize your roadmap for the wrong customers. Let us walk the big four, then talk about the number none of them can see.

First, why bother with a framework

Because the cost of guessing is not abstract. According to Pendo's 2019 Feature Adoption Report, roughly 80% of features in the average software product are rarely or never used, while about 12% of features drive 80% of daily usage. Those are vendor numbers, so treat them as directional rather than gospel, but the direction is hard to argue with.

Every feature you build is not just a sprint spent, it is surface area you maintain, document, and support for years. Prioritization is how you avoid pouring that effort into the 80% nobody asked for twice. A framework will not make the decision for you, but it forces the trade-offs into the open where a team can actually reason about them.

RICE: the spreadsheet everyone starts with

RICE was created by Sean McBride on Intercom's growth team and published on the Intercom blog in January 2018. It scores each idea as reach times impact times confidence, divided by effort.

Reach is how many people or events a change touches in a set period. Impact is a deliberately blunt scale, 3 for massive down to 0.25 for minimal. Confidence is a percentage that docks your score when you are guessing. And effort is in person-months. The clever part is that effort sits in the denominator, so a giant idea that eats a year can lose to a modest one you ship in a week.

It is a great default. But notice what impact actually is: a number you assign, on a fixed scale, based on your read of how much a feature will move the needle. It is not tied to a dollar, and it is not tied to who is asking. Hold that thought.

MoSCoW, Kano, and WSJF: the rest of the kit

MoSCoW

MoSCoW, for must have, should have, could have, and won't have, was devised by Dai Clegg at Oracle in 1994 and later donated to the DSDM agile method. It is blunt, and that is the point: it is superb for forcing a room to agree on what actually has to be in the next release, and what can wait.

Kano

The Kano model, introduced by Professor Noriaki Kano in 1984, sorts features by how they affect satisfaction: basic must-be needs, linear performance needs, and attractive delighters. It is less a ranking tool and more a lens. It tells you whether you are shoring up table stakes or reaching for something people will actually rave about.

WSJF

WSJF, or weighted shortest job first, leans on the cost-of-delay economics from Don Reinertsen's 2009 book, The Principles of Product Development Flow, and was later baked into the Scaled Agile Framework. You divide the cost of delaying something by how long it takes, then do the most expensive-to-delay, quickest-to-finish work first.

Each of these does real work, and they answer genuinely different questions. But run your eye down that list and you will spot the gap: every one of them ranks by some flavor of how many or how much impact, and impact is measured in users, reach, and effort. Not one of them natively knows which users are behind a request.

The signal every one of them misses

Here is where scoring frameworks quietly go wrong. The easiest input to reach for is a vote count, and votes are useful. They tell you how many people care. What they do not tell you is how much the outcome is worth to your business.

So you get situations like this. A request with 200 votes, almost all from free-tier users, outranks a request with 40 votes from the three enterprise accounts that pay most of your bills. Rank purely by count and the free tier wins every time, because there are simply more of them. Prioritization has quietly become a popularity contest, and the loudest segment sets your roadmap regardless of what it contributes.

Twenty free users can outvote your biggest account. Raw demand measures how many people care, not how much the outcome is worth.

This is not an argument against frameworks. Feed a vote-only signal into RICE and you just inherit the same problem with more decimal places. The fix is upstream: weight demand by value before you score it.

Weighting demand by value

That is the gap sarvaFeed is built to close. Connect your CRM or billing data, and every vote on your board carries the ARR of the account behind it, so a request backed by high-value customers rises on its own, with no one having to relitigate it in the Thursday meeting. Revenue-weighted voting is a Pro-plan feature, and it turns a raw tally into a ranked business case.

You do not have to abandon RICE or MoSCoW to get there. Keep them, they are good at what they do. Just give them the one number they cannot see on their own, and prioritization stops being a popularity contest and starts being a business decision.