A decision framework for deciding what not to build

RICE was developed by Intercom to rank feature requests in a consistent, repeatable way. The formula is: (Reach x Impact x Confidence) / Effort. Reach is how many users the feature touches per quarter. Impact is the estimated impact on each user (1 = minimal, 2 = low, 3 = medium, 4 = high). Confidence is how confident you are in your estimates (50%, 80%, or 100%). Effort is person-months. The output is a score. Higher scores should be built first.

RICE is useful because it forces quantification. The feature that someone is most excited about is not necessarily the one with the highest RICE score. It surfaces assumptions. A high-Reach, low-Impact, high-Confidence feature with low Effort has a decent score. A low-Reach, high-Impact, low-Confidence feature with high Effort scores poorly and should be deprioritised or researched further.

Where RICE misses: it presumes a feature is going to be built. The scoring system is a ranking mechanism, not a gating mechanism. A RICE score of 3.2 does not tell you whether 3.2 is good enough to justify the maintenance commitment. Nothing in RICE asks "should we build zero?" Nothing asks "does this feature already exist somewhere in the product?" Nothing asks "who will maintain this in 18 months?"

The Kano model was developed by Noriaki Kano in 1984. It categorises features into three types. Basic features (also called Must-be): their absence causes dissatisfaction, but their presence does not cause satisfaction. They are expected. Performance features: their presence increases satisfaction linearly. More is better. Excitement features (also called Delighters): unexpected features that cause significant satisfaction when present but no dissatisfaction when absent.

The model is useful for understanding why adding more Performance features does not deliver proportional returns. And it is particularly useful for understanding why Excitement features become Basic features over time. Touch-ID was an Excitement feature in 2013. It is a Basic feature in 2026. Features degrade through the Kano categories as expectations rise.

Where Kano misses the bloat question: the Excitement category is a bloat engine. Every team wants to ship Delighters. Delighters are memorable, shareable, praised in product reviews. But today's Delighter is tomorrow's Basic feature that you are now committed to maintaining forever. The Kano model does not ask whether shipping a Delighter is a maintenance commitment you can afford. It does not ask whether the Delighter belongs in your product or in a different product.

MoSCoW prioritisation categorises requirements into four buckets: Must have (the release is not viable without this), Should have (important but not vital for the current release), Could have (nice to have, included if time allows), and Won't have (explicitly excluded from this release).

MoSCoW is widely used in project management and requirements definition. It is simple, communicable, and stakeholder-friendly. It has one quality that is genuinely rare in prioritisation frameworks: the Won't column.

The Won't column is the most important column in MoSCoW and the least used. In practice, the Won't column is treated as "not yet" rather than "never." Items move from Won't to Could to Should to Must across releases, which means the Won't column is a deferral mechanism, not a rejection mechanism. The discipline to keep things in Won't permanently, to say "this is not in this product now or ever," is the anti-bloat application of MoSCoW.

Where MoSCoW misses: it does not ask whether Must-have features from two years ago are still must-have today. Features that were Must for v1 are maintained indefinitely without re-evaluation. MoSCoW is a requirements framework, not a lifecycle framework.

Shape Up is Ryan Singer's methodology for product development, published in 2019 as a free book by Basecamp. It is the most complete structural response to feature bloat available in the product management literature.

The core insight is appetite: before a feature is worked on, the team defines how much time they are willing to spend on it. This is the appetite, typically 2 weeks (small batch) or 6 weeks (large batch). The scope is then shaped to fit the appetite, not the other way around. If the full feature cannot be done in 6 weeks, you find the version of the feature that can be done in 6 weeks, or you don't do it at all.

This is the fundamental inversion of how most teams work. Most teams scope the feature, then estimate how long it will take, then argue about whether they have time. Shape Up starts with time and makes scope variable. This structural change forces cuts at the shaping stage, before any code is written.

The betting table is where work gets chosen. Every six-week cycle, the team places bets: here is the work we will do this cycle. What doesn't get bet on doesn't get worked on. There is no backlog in the conventional sense. Things that do not get bet on can be pitched again next cycle or dropped. This forces a continuous re-evaluation of what is worth doing.

Feature bloat self-diagnostic

Digital Signet

Need help running the checklist across a real product?

Digital Signet facilitates two-week product audits that apply this framework to your actual feature set, with your actual usage data.