Feature Request Triage

Here is a Monday morning that every startup founder recognises.

Your backlog has 147 feature requests. Sales wants three features that will “definitely close that enterprise deal.” Customer success has a list from churning customers. Engineering wants to address technical debt that nobody else understands. The CEO — that is you — just added three “urgent” items after a conversation with an investor. And someone on the team forwarded a competitor’s changelog that makes everyone nervous.

Nobody agrees on what to build next. The conversation gets louder. The person with the strongest opinion wins. Two weeks later, you ship something, and the metrics do not move.

Your product team just wrapped up the quarter with a bang. Fifteen new features shipped. The engineering and development teams are exhausted but proud. The roadmap is colour-coded and beautiful. But then the metrics start to roll in. Conversion rates are flat. Churn is up. Customer satisfaction scores have not budged.

Sound familiar? You are not alone. Most SaaS companies are stuck in a feature factory, churning out functionality users do not want, do not use, or actively avoid. While your competitors are optimising the core experiences that drive growth, you are polishing the peripheral features.

And the data on how much of what you build actually gets used is devastating. It is estimated that around 80 percent of product features are “rarely or never used.” The median feature adoption rate across products is just 6.4% — meaning for every 100 features your team builds and ships, only about 6 of them are driving 80% of actual user activity. Even the best product teams are focusing on features that simply do not matter to their end users.

Feature bloat contributes to approximately 40% of product abandonment. You are not just wasting engineering hours. You are actively making your product worse — more complex, harder to learn, more expensive to maintain — with every feature you add that nobody asked for, or that only one customer screamed about.

You do not need more features. You need the right features — chosen through a framework, not a fight.

The RICE scoring system: your foundation

Messaging-software maker Intercom developed the RICE roadmap prioritisation model to improve its own internal decision-making processes. RICE was co-developed by Sean McBride, a former product manager at Intercom, and it has since become the most widely adopted feature scoring method in product management.

Sean explains: “It’s just a structured framework for breaking down one big estimate into four smaller estimates that are easier for the human mind to think about without getting bogged down.”

The formula is simple: (Reach × Impact × Confidence) ÷ Effort = RICE Score.

Let me walk through each factor.

The beauty of RICE is that it replaces subjective debates with a number you can compare across wildly different types of requests. Of course, RICE scores should not be used as a hard and fast rule. There are many reasons why you might work on a project with a lower score first. One project may be a dependency for another project, or another feature might be “table stakes” to sell to certain customers. Sometimes you might want or need to work on projects out of order. And that is okay. With a scoring system in place, you can clearly identify when you are making these trade-offs.

Adapting RICE for startup realities: the RICE+ scorecard

Standard RICE is powerful. But startups need two additional dimensions that the original framework does not capture: customer revenue impact and strategic alignment.

Build a RICE+ scorecard by adding two columns to your Google Sheet:

This surfaces features that serve high-value customers AND move your strategy forward — not just popular requests from users who will never pay you.

The triage process: from inbox to decision in 5 steps

Having a scorecard is useless without a process. Without a clear method, feature prioritisation can turn into a subjective debate influenced by the loudest voice in the room. Here is the weekly triage rhythm that keeps your backlog honest.

Step 1: Capture everything in one place

Feature requests come from everywhere — sales calls, support tickets, customer emails, Slack messages, investor conversations, competitor analysis. The first rule is that every request, regardless of source, must land in a single database. A Notion table, a Trello board, or a simple Google Sheet — the tool does not matter. The discipline of centralised capture does.

For each request, capture: who requested it, their customer ARR, the request description, the underlying use case (why they want it, not just what they want), and the date submitted. Product managers often have a hundred items and no clear way to rank them. Stakeholders push for their favourites. Technical debt never makes it to the top. Meanwhile, customers churn because the features they need keep getting deprioritised.

Step 2: Triage weekly — 30 minutes

Like an email inbox, triage your requests every week. For each new request, answer three questions: Can you imagine solving the problem it describes one day? If not, delete it. Does the request make sense? If not, ask for clarification. Which existing feature request does it relate to? Link it to an existing item, or create a new one. This prevents your backlog from becoming a wishlist nobody can navigate.

Step 3: Score using your RICE+ scorecard

For any request that passes triage, score it across all six dimensions. Critical rule: Engage different teams — marketing, development, sales — to provide diverse perspectives and improve the accuracy of your estimates. Each scorer should complete their scores independently before any group discussion. This prevents groupthink and anchoring bias.

Step 4: Stack rank and discuss the top 10

Scores provide ranking, not build-or-not-build decisions. A high score tells you which items rank above others for further consideration, not whether any item warrants investment. Strategic imperatives, resource constraints, and business context still matter. Use the scores to focus your team’s discussion on the right ten features — not all 147.

Step 5: Assign or decline — and communicate

Move top-ranked items to your roadmap. Decline the rest — respectfully. And here is where most founders fail: close the loop with every requester. Every single one. Ghosting a customer who took the time to suggest a feature is worse than saying no. It teaches them that feedback is pointless, and they stop giving it to you — which means the next time they have a problem, they leave instead of asking.

The art of saying no — without losing customers

This is the skill that separates founders who build focused products from founders who build bloated ones. You will always have more feature requests than you can build. Learning to say no gracefully — to customers, to stakeholders, and even to yourself — is perhaps the most important product skill you can develop.

When a customer requests a feature, they are already convinced that it is crucial for their success with your product. It is way more important to them than it is to you. You just know you are not going to do it. If you do not explain it, they will not understand why. They will just feel like their input is not important to you.

Here are four templates that follow the Acknowledge-Explain-Offer structure:

Get in the habit of documenting what you are saying no to in a place where others can see. This can be an appendix to your roadmap or a section of a wiki page. Being transparent about what your team will NOT do and WHY reduces ambiguity throughout your organisation.

The feature bloat trap: why “yes” can kill your product

Before you override your scoring system because a big customer pressured you, understand what is at stake.

Research from the Nielsen Norman Group shows that feature bloat directly correlates with decreased user satisfaction. Jared Spool calls it “experience rot” and highlights the inevitable complexity creep and user experience decline that occurs when teams add features without ruthless prioritisation.

Consider a real pattern: a B2B SaaS platform spent six months building an advanced scheduling feature requested by their largest enterprise client. The feature worked beautifully for that one client — but sat unused by 98% of their user base. Six months of engineering, design, and testing for one customer. Meanwhile, the three features that 60% of users needed sat in the backlog, collecting dust.

Average products see usage concentrated in just 11% of their feature set, while best-in-class organisations see it spread across 28%. That gap tells you everything about the difference between a product that says yes to everything and one that says yes to the right things.

The consequences of chronic feature bloat compound:

• Onboarding time doubles — more features means more complexity, which means new users take longer to find value
• Support tickets spike — every additional feature is another surface area for confusion, bugs, and questions
• Churn increases — pre-product-market fit companies experience 4.3 times higher churn than established SaaS businesses, and feature bloat often delays the moment when you actually nail what users need
• Technical debt accumulates — developers waste on average 23% of their working time due to technical debt, and every unused feature adds to that burden
• Maintenance costs compound — low-impact features still need maintenance, bug fixes, and updates. They create dependencies that slow down future development and increase the risk of breaking changes. Low-impact features do not just waste resources; they actively prevent you from building high-impact ones.

The most successful products are not the ones with the most features. They are the ones with the right features — chosen through discipline, not panic.

Why the loudest voice is almost never right

Here is one of the most important things I can tell you about feature requests, and it is the insight that most founders miss until it is too late.

Sales and support teams typically focus on urgent and specific user needs, which may not reflect the broader needs of your user base. Prioritising feature requests from them alone leads to a skewed process that satisfies a few users at the expense of the many.

The salesperson who says “we will lose this deal without feature X” is not lying. They genuinely believe it. But what they cannot see is the opportunity cost — the three features you will NOT build because you spent two months on the one that closes one deal. And the deal that feature X closes might churn in six months anyway, because the customer who needed a custom feature is usually the customer who has the most unusual use case — and therefore the least likely to be satisfied long-term.

While there is no denying a customer’s feelings or pain points, they are not always the best at both diagnosing the root cause of their issue and coming up with the ideal solution. Customers are trapped in their own particular worldviews and coloured by the specifics of their experience. Therefore, they are potentially unable to envision the full possibility of options.

That is why the scoring system matters. It does not eliminate human judgment — it structures it. It forces the conversation from “I feel this is important” to “here is the reach, impact, confidence, effort, revenue weight, and strategic alignment — and here is how it compares to the 20 other things we could build instead.”

The weekly rhythm that makes it stick

Using static scores is a common mistake. Product needs change. Prioritisation is not one-and-done. Review and rescore monthly as context changes. A feature that scored low three months ago might score high today because the market shifted, or because a competitor launched something that changed the game.

Most teams benefit from weekly refinement sessions lasting 30 to 60 minutes, focused on items in the top 30 to 40% of the backlog. Do not try to refine everything. Only refine what will be built soon. Requirements change. Refining items six months out is wasted effort when priorities shift.

Build your triage system this week

Stop debating features in Slack threads. Build a system. Here is a five-day setup plan.

Which framework to use at your stage

A quick note for founders at different stages, because the right framework depends on where you are.

Pre-product-market fit: use ICE (Impact, Confidence, Ease). You are running experiments, not building features. Speed and learning matter more than precision. ICE is faster to score because it drops the Reach dimension — which you do not have enough data for anyway.

Growth phase: use RICE or RICE+. You have usage data, you know your users, and you need to maximise the impact of your engineering investment across a growing user base. The additional dimensions of Reach and Revenue Weight become meaningful because you have enough customers to differentiate.

Scale phase: use RICE+ with quarterly recalibration. At this point, you have multiple product teams, competing roadmaps, and cross-functional complexity. When multiple teams use the RICE model, they might score similar initiatives differently, which may lead to misaligned priorities. Establish clear scoring guidelines and calibrate regularly across teams to ensure consistency.

The mindset shift that makes everything else work

Here is the uncomfortable truth underneath all of this.

Most founders treat feature requests as an input problem — too many requests, not enough time. But it is actually an output problem. You are not overwhelmed because you have too many requests. You are overwhelmed because you do not have a system for deciding which ones matter.

Public cloud companies spend an estimated $29.5 billion on features that may rarely or never be used. That is the cost of building without a framework — at industry scale. For a startup, the cost is proportionally even higher, because every wasted engineering month is a month you are not spending on the features that would actually grow your business.

Only 6% of product features are generating 80% of clicks for the average product. Think about what that means. For every ten features you ship, nine of them are contributing almost nothing to user engagement. The one feature that matters is carrying the entire product on its back — and it is competing for engineering time with nine features that should never have been built.

Every feature you say yes to carries not just the cost of building it, but the ongoing cost of maintaining it, supporting it, documenting it, onboarding users on it, and working around it when it creates complexity for future development. Every feature must justify both its existence and its upkeep.

The hallmark of a mature digital product is not abundance. It is intentionality.

Your backlog is not a wishlist. It is a strategy document. Score it. Rank it. Ship only what earns its place.