Feature prioritization has no shortage of named frameworks, RICE, Kano, and MoSCoW among the most common. This article walks through how each one works, and the limitation they all share once you start using them in practice.
RICE scoring
RICE scores a request by combining four inputs, Reach (how many people it affects), Impact (how much it moves the needle for them), Confidence (how sure you are about the first two), and Effort (how much work it takes), into a single number: (Reach × Impact × Confidence) ÷ Effort. It's useful for lining up a long list of candidates side by side, especially early on when you have more ideas than time and need a first pass at narrowing them down.
The catch is that scoring all four inputs is inherently subjective. Confidence in particular tends to become a gut-feel number dressed up as data, and the resulting score is only as good as the inputs that went into it.
The Kano model
The Kano model sorts features into five categories based on the relationship between how well a feature is implemented and how satisfied it makes customers: Must-be, Performance, Attractive, Indifferent, and Reverse. You classify features by asking a pair of questions for each one, a functional question ("how do you feel if this feature is present?") and a dysfunctional question ("how do you feel if it's absent?"), and reading the pattern of answers.
Its strength is capturing an asymmetry that flat scoring misses: a missing must-be feature causes real dissatisfaction, but adding more of it barely moves satisfaction once it's there, while an attractive feature costs you nothing in dissatisfaction if it's missing but can lift satisfaction sharply when it's present. The downside is that classifying features accurately requires a structured customer survey up front, which makes it a poor fit for triaging requests as they arrive day to day.
MoSCoW
MoSCoW sorts requests into four buckets, Must have, Should have, Could have, and Won't have (this time), to scope a sprint or release. It's often used to reach team agreement quickly, and because it skips numeric scoring, it's easier to adopt than RICE or Kano.
Its weak point is that the line between buckets tends to be whatever the team agrees on in the room. The framework itself doesn't include a mechanism for distinguishing "this is genuinely a must" from "this is a must because the person who said so has a loud voice."
The shared limitation: scores and categories can hide the reason
RICE, Kano, and MoSCoW are all tools for converting requests into something comparable, a number or a category. In that conversion, the context behind each request, who's affected, what's frustrating them, why they want it, is often lost.
Take a request like "improve search": someone frustrated by slow response time and someone frustrated because certain data isn't indexed at all are really asking for two different things, with different Impact and Effort. If both get logged as a single request, that difference can slip through unnoticed once you start scoring. We go into this gap between request count and underlying reasons in more detail in "Counting Feature Requests Won't Tell You What to Build Next".
How to actually use these frameworks
A framework gives you a structure for making a decision, but if the input going into it, the background and reasoning behind each request, is thin, the score or category coming out will be thin too. In practice, spending effort putting "why is this being asked for" into words before applying a framework tends to matter more than getting the scoring itself perfectly precise.
Feedury builds an AI summary of that background into the collection flow itself, and groups similar requests so you can see combined support across them, both aimed at improving the quality of what you feed into whatever framework you use downstream. You can see it in action on the demo board.
Wrapping up
RICE, Kano, and MoSCoW are all useful structures for prioritization, but none of them make up for losing the reasoning behind a request. Before reaching for a framework, it's worth checking how well you've actually captured why people are asking for what they're asking for, that tends to matter more in practice. We cover choosing a feedback management tool more broadly in "What Is a Feedback Management Tool? A Guide for Indie Developers and Small SaaS Teams".