---
title: How to prioritise feature requests | AskTheCustomer
description: Turn a pile of feature requests into a clear roadmap. Find the need behind each request, count who is asking, score with RICE and say no with care.
image: https://www.askthecustomer.ai/hubfs/blog-images/p3-og-v4.png
---
[AskTheCustomer](https://www.askthecustomer.ai/)
[The problem](https://www.askthecustomer.ai/#problem) [How it works](https://www.askthecustomer.ai/#how) [Use cases](https://www.askthecustomer.ai/#use-cases) [Who it's for](https://www.askthecustomer.ai/who-its-for) [Blog](https://www.askthecustomer.ai/blog) [Early Access](https://www.askthecustomer.ai/early-access)
[Home](https://www.askthecustomer.ai/)/[Blog](https://www.askthecustomer.ai/blog)/Article
# How to prioritise feature requests from customers
OS [Olha Solonenko](https://www.askthecustomer.ai/blog/author/olha-solonenko) 7 October 2026 11 min read Updated 20 October 2026
Customers are good at describing their problems and unreliable at designing solutions. Here is how to turn a pile of feature requests into a short list you can defend.
Key takeaways
- A feature request is a proposed solution. Prioritise the underlying need, not the wording of the request.
- Count distinct customers and segments, not total mentions. One loud account is not a pattern.
- A simple score such as RICE makes trade-offs visible, but the inputs are estimates. Show your confidence.
- Most features are rarely used (80% in Pendo's analysis), so saying no is part of the job.
- Close the loop. Tell customers what you decided and why, even when the answer is no.
*How to… · Product*
## The short answer
Treat every feature request as a clue, not an order. A customer who asks for an export button is telling you about a job they can't finish today. Your task is to find that job, check how many other people share it, and then pick the cheapest way to solve it.
In practice that means four moves. Rewrite each request as a problem. Count how many different customers and segments raise it. Score what's left with a simple model, so the trade-offs are visible. Then decide, and tell the people who asked what you decided.
This guide walks through each step, compares the main scoring methods, and ends with a template you can copy into your own tracker.
## Why it matters: most features don't earn their keep
Building the wrong thing is expensive, and it's common. Pendo analysed feature usage across 615 software subscriptions and found that [80% of features are rarely or never used, while about 12% of features generate 80% of daily usage](https://www.pendo.io/resources/the-2019-feature-adoption-report/). The data is from 2019 and from Pendo's own customer base, so treat it as a rough guide. The pattern is still a useful warning.
Every request you accept has a cost. It takes engineering time, it adds surface area to support, and it pushes something else off the roadmap. Saying yes to everything is a decision too. It just doesn't feel like one.
*Move from the request to the need before you compare options.*
## Step 1: Turn each request into a need
A request arrives as a solution: "Add a Slack integration." "Let us export to Excel." "We need a dark mode." Customers aren't wrong to ask. They're just describing the answer they can imagine, and they often can't see the better ones.
Product coach Teresa Torres makes the point bluntly: [our job is not to prioritise solutions](https://www.producttalk.org/prioritize-opportunities/). She argues for working at the level of customer needs, which she calls opportunities, and comparing those instead.
For each request, ask the customer three things:
- "What were you trying to do when you hit this?"
- "What do you do today instead?"
- "What does it cost you when it doesn't work?"
Write the answer in one sentence, in the customer's own words where you can. "I need to send monthly numbers to finance" is a need. "Add CSV export" is a solution. Several different requests often collapse into the same need, and that is your first piece of signal.
Keep those follow-up questions neutral. Our guide on [how to write customer interview questions that aren't leading](https://www.askthecustomer.ai/blog/how-to-write-customer-interview-questions-not-leading) shows how.
Here is how a few typical requests translate.
| What the customer says | The need behind it | Other ways to solve it |
| --- | --- | --- |
| "Add a CSV export." | Share monthly numbers with finance without retyping them. | Scheduled email report, shared dashboard link, accounting integration. |
| "We need a Slack integration." | Find out quickly when something needs their attention. | Email alerts, mobile notifications, a digest. |
| "Let us customise the dashboard." | See their own key numbers first, without hunting. | Better defaults per role, saved views, a single summary page. |
| "Add an approval workflow." | Stop mistakes reaching customers without slowing everyone down. | Permissions, a review checklist, an audit log. |
If you can't get to the need because the request is old, anonymous or second-hand, mark it as "need unclear" and keep it out of the scoring until you've asked.
## Step 2: Count who is asking, and who isn't
Next, work out how much demand sits behind each need. Count the number of **different customers**, not the number of mentions. Ten requests from one account is one signal, not ten.
Then split the count in three ways:
- **By segment.** A need that matters hugely to enterprise admins may be irrelevant to small teams. Look at demand per segment, not as one blended average.
- **By role.** The person who requests a feature is not always the person who uses it, or the person who pays for it.
- **By evidence type.** Support tickets, sales-call notes, interviews, churn reasons and in-app behaviour each tell you something different.
Look beyond the people who email you. The most vocal customers are not a random sample. Add the quiet signals: lost-deal notes, cancellation reasons, and tickets where people describe a workaround without asking for anything. Workarounds are some of the strongest evidence, because people only build them for problems that hurt.
Then check the other direction. If a need shows up in your market research but never in your customer evidence, either your customers are unusual or you aren't reaching the people who have it. Both are worth knowing. Keep the two sources separate so you can see where they disagree.
Our guide on [how to validate a product idea before building it](https://www.askthecustomer.ai/blog/how-to-validate-a-product-idea-before-building-it) covers how to test demand when the evidence is thin.
*Breadth of demand against strategic fit. A starting point for the conversation, not a verdict.*
## Step 3: Score the needs with a simple model
Once you have a list of needs with evidence behind each, put them on a common scale. Scoring doesn't make the decision for you. It stops the loudest voice, or the most recent conversation, winning by default.
The best-known model is RICE, which Intercom [built to prioritise its own roadmap](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/). You score four factors and combine them:
**RICE score = (Reach × Impact × Confidence) ÷ Effort**
- **Reach** is how many people the work will affect in a set period, such as customers per quarter.
- **Impact** is the effect on each person, on Intercom's scale of 3 (massive), 2 (high), 1 (medium), 0.5 (low) and 0.25 (minimal).
- **Confidence** is how sure you are of your estimates: 100% is high, 80% medium and 50% low.
- **Effort** is the total work across product, design and engineering, in person-months.
ProductPlan's guide to the model notes that [anything below 50% confidence is a "moonshot"](https://www.productplan.com/glossary/rice-scoring-model) and probably shouldn't be prioritised yet. It also points out that impact is hard to measure, because it's difficult to isolate one project as the cause of a change in behaviour. Treat the maths as a conversation tool, not a measurement.
*The RICE formula and scales, as defined by Intercom.*
RICE isn't the only option. Here's how the common methods compare.
| Method | What it answers | Best when | Watch out for |
| --- | --- | --- | --- |
| RICE | Which items give the most impact per unit of effort? | You have a long list and some usage data. | False precision. The inputs are estimates. |
| Kano model | Which features are basics, which add satisfaction, which delight? | You're deciding between kinds of improvement, not just sizes. | Needs a survey of the right customers. |
| Weighted scoring | Which items best fit the goals we've chosen? | Leadership wants criteria that reflect strategy. | Weights can be gamed to reach a favourite answer. |
| Opportunity tree | Which customer needs are worth solving, and how? | You're early and need to compare needs, not features. | Takes interview time to build properly. |
| Simple impact versus effort grid | What are the quick wins and the big bets? | You need a fast first pass with the team. | Treats all impact as equal. |
The Kano model is worth a closer look if you suspect a request is a basic expectation rather than a differentiator. [ProductPlan describes](https://www.productplan.com/learn/kano-model-prioritization) three types of feature: must-be features customers expect, performance features where more is better, and attractive features that delight. You find out which is which by asking two questions per feature: how would you feel with it, and how would you feel without it. Must-be features rarely win praise, but missing one can sink a deal.
A few tips for scoring well:
- **Score as a group.** A product manager, an engineer and someone from customer-facing work will catch different blind spots.
- **Write down your evidence.** "Reach: 40 accounts" should link to something. Otherwise it's a guess wearing a number.
- **Score needs, not requests.** Merge duplicates first. Otherwise the same problem gets counted several times.
- **Re-score when evidence changes.** A score is a snapshot, not a verdict.
## Step 4: Decide, say no well, and close the loop
A ranked list isn't a roadmap. Before you commit, check three things.
**Strategic fit.** Does this move you toward the customers and problems you've chosen to serve? A high-scoring request from a segment you're deliberately leaving behind may still be a no.
**Dependencies and risk.** Does it unlock other work? Is it hard to reverse? Reversible choices can be made quickly. Torres suggests treating many of these as two-way decisions, because [you don't need perfect data to start testing](https://www.producttalk.org/prioritize-opportunities/).
**The big-customer problem.** Sooner or later your largest account asks for something only they want. You don't have to refuse outright. You have a few options: solve the underlying need a different way, offer a workaround, make a paid commitment a condition of building it, or decline and explain the trade-off. Be honest about which one you're choosing.
Whatever you decide, tell people. Most customers can accept a no. What frustrates them is silence. A good reply has four parts:
1. Thank them and repeat their need in your own words, so they know you understood it.
2. State the decision plainly: yes, not yet, or no.
3. Give one honest reason, such as "it would help a small number of accounts and we're focused on onboarding."
4. Offer what you can: a workaround, a different feature that covers part of the need, or a promise to revisit when something changes.
Keep a "not now" list with the date and the reason. When circumstances change, you'll know exactly what you decided and why.
## A feature request scorecard you can copy
Paste this into a spreadsheet or your product tool. Fill one row per **need**, not per request.
| Need (in the customer's words) | Requests merged | Distinct customers | Segments and roles | Evidence sources | Reach (per quarter) | Impact (0.25–3) | Confidence (50–100%) | Effort (person-months) | RICE score | Decision and date |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| \[e.g. "Send monthly numbers to finance"\] | \[4\] | \[9\] | \[Mid-market admins\] | \[Tickets, 2 interviews\] | \[300\] | \[1\] | \[80%\] | \[2\] | \[120\] | \[Build next quarter\] |
| \[Need 2\] | | | | | | | | | | |
| \[Need 3\] | | | | | | | | | | |
Add three rules above the table before you start:
- We count distinct customers, not mentions.
- We don't score a need until we've confirmed what it is.
- Anything below 50% confidence goes back for research, not onto the roadmap.
## Common mistakes
- **Building the request as written.** You get the solution the customer imagined, which may not be the best one. Find the need first.
- **Counting mentions instead of customers.** One account that emails weekly looks like a trend. It isn't.
- **Listening only to the loudest.** Include quiet signals, such as lost deals, churn reasons and workarounds.
- **Treating the score as the answer.** A RICE number is built from estimates. Use it to spark the discussion, then use judgement.
- **Never saying no.** An endless backlog tells customers you've heard them and tells your team nothing. Prune it every quarter.
- **Going silent.** Customers who hear nothing assume you ignored them. Close the loop, even with a no.
- **Ignoring strategy.** A pile of well-scored items from the wrong segment is a roadmap for a different company.
## FAQ
### Should I build what customers ask for?
Not as asked. Customers are the best source of problems and an unreliable source of solutions. Use requests to find needs, then design the solution yourself. Sometimes that ends up looking exactly like the request. Often it's simpler.
### How many requests do I need before building something?
There's no magic number. A better question is how many different customers in your target segment share the need, and how much it costs them. Five accounts with a painful, expensive workaround is stronger than fifty vague "nice to have" mentions. Confirm the need with a few conversations before you commit.
### What is the RICE framework?
RICE is a scoring model developed at Intercom. It multiplies reach, impact and confidence, then divides by effort, to give a score for total impact per unit of work. It's useful for comparing a long list. It's less useful when your inputs are pure guesses, which is why the confidence factor exists.
### How do I handle a request from my biggest customer?
Treat it as strong evidence about one account, then test whether the need is wider. Ask what they are trying to do. You may find a cheaper way to solve it, or a pattern across other accounts. If it's truly specific to them, decide openly whether a paid commitment, a workaround or a polite no is the right answer.
### How do I say no without losing the customer?
Be fast, specific and kind. Restate their need, say no plainly, give one honest reason, and offer what you can do instead. Customers tend to respect a clear answer more than a vague "we'll look into it".
### How often should I review the backlog?
Quarterly is a good rhythm for most teams. Merge duplicates, re-score items where the evidence has changed, and close anything that no longer fits your strategy. A shorter backlog is easier to trust.
## Sources
- [Pendo: The 2019 Feature Adoption Report](https://www.pendo.io/resources/the-2019-feature-adoption-report/)
- [Intercom: RICE, simple prioritisation for product managers](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/)
- [ProductPlan: RICE scoring model](https://www.productplan.com/glossary/rice-scoring-model)
- [ProductPlan: Kano model prioritisation](https://www.productplan.com/learn/kano-model-prioritization)
- [Product Talk (Teresa Torres): Prioritize opportunities, not solutions](https://www.producttalk.org/prioritize-opportunities/)
*Last updated: 20 October 2026*
Don't guess. Ask the customer.
OS
### Olha Solonenko
Olha Solonenko is the founder of AskTheCustomer, an evidence-based AI customer persona platform for B2B teams. Based in Ireland, she works on helping product, marketing and sales teams use real customer evidence in everyday decisions.
[Connect on LinkedIn](https://www.linkedin.com/in/olha-solonenko-3630684/)
On this page
Early Access
## Build personas from *real customer evidence.*
AskTheCustomer turns your interviews, calls and tickets into personas you can question, with sources for every answer. Early Access is free.
[Join Early Access →](https://www.askthecustomer.ai/early-access) [Is it a fit for your team?](https://www.askthecustomer.ai/who-its-for)
[AskTheCustomer](https://www.askthecustomer.ai/)
Stop guessing. *Ask the customer.*
© 2026 AskTheCustomer · Built in Ireland
Page updated October 2026
```json
{
"@context" : "https://schema.org",
"@type" : "BlogPosting",
"author" : {
"@type" : "Person",
"name" : "Olha Solonenko",
"url" : "https://www.askthecustomer.ai/blog/author/olha-solonenko"
},
"dateModified" : "2026-10-20T00:46:23.223Z",
"datePublished" : "2026-10-07T09:07:14.000Z",
"headline" : "How to prioritise feature requests | AskTheCustomer",
"image" : [ "https://www.askthecustomer.ai/hubfs/blog-images/p3-og-v4.png" ],
"mainEntityOfPage" : {
"@id" : "https://www.askthecustomer.ai/blog/how-to-prioritise-feature-requests-from-customers",
"@type" : "WebPage"
},
"publisher" : {
"@type" : "Organization",
"logo" : {
"@type" : "ImageObject"
}
}
}
```
```json
{
"@context" : "https://schema.org",
"@type" : "FAQPage",
"mainEntity" : [ {
"@type" : "Question",
"acceptedAnswer" : {
"@type" : "Answer",
"text" : "Not as asked. Customers are the best source of problems and an unreliable source of solutions. Use requests to find needs, then design the solution yourself. Sometimes that ends up looking exactly like the request. Often it's simpler."
},
"name" : "Should I build what customers ask for?"
}, {
"@type" : "Question",
"acceptedAnswer" : {
"@type" : "Answer",
"text" : "There's no magic number. A better question is how many different customers in your target segment share the need, and how much it costs them. Five accounts with a painful, expensive workaround is stronger than fifty vague nice-to-have mentions. Confirm the need with a few conversations before you commit."
},
"name" : "How many requests do I need before building something?"
}, {
"@type" : "Question",
"acceptedAnswer" : {
"@type" : "Answer",
"text" : "RICE is a scoring model developed at Intercom. It multiplies reach, impact and confidence, then divides by effort, to give a score for total impact per unit of work. It's useful for comparing a long list. It's less useful when your inputs are pure guesses, which is why the confidence factor exists."
},
"name" : "What is the RICE framework?"
}, {
"@type" : "Question",
"acceptedAnswer" : {
"@type" : "Answer",
"text" : "Treat it as strong evidence about one account, then test whether the need is wider. Ask what they are trying to do. You may find a cheaper way to solve it, or a pattern across other accounts. If it's truly specific to them, decide openly whether a paid commitment, a workaround or a polite no is the right answer."
},
"name" : "How do I handle a request from my biggest customer?"
}, {
"@type" : "Question",
"acceptedAnswer" : {
"@type" : "Answer",
"text" : "Be fast, specific and kind. Restate their need, say no plainly, give one honest reason, and offer what you can do instead. Customers tend to respect a clear answer more than a vague we'll look into it."
},
"name" : "How do I say no without losing the customer?"
}, {
"@type" : "Question",
"acceptedAnswer" : {
"@type" : "Answer",
"text" : "Quarterly is a good rhythm for most teams. Merge duplicates, re-score items where the evidence has changed, and close anything that no longer fits your strategy. A shorter backlog is easier to trust."
},
"name" : "How often should I review the backlog?"
} ]
}
```
```json
{
"@context" : "https://schema.org",
"@id" : "https://www.askthecustomer.ai/blog/how-to-prioritise-feature-requests-from-customers#article",
"@type" : "BlogPosting",
"author" : {
"@id" : "https://www.askthecustomer.ai/#olha-solonenko",
"@type" : "Person",
"description" : "Olha Solonenko is the founder of AskTheCustomer, an evidence-based AI customer persona platform for B2B teams. Based in Ireland, she works on helping product, marketing and sales teams use real customer evidence in everyday decisions.",
"name" : "Olha Solonenko",
"sameAs" : [ "https://www.linkedin.com/in/olha-solonenko-3630684/" ],
"url" : "https://www.linkedin.com/in/olha-solonenko-3630684/",
"worksFor" : {
"@id" : "https://www.askthecustomer.ai/#organization"
}
},
"dateModified" : "2026-10-20",
"datePublished" : "2026-10-07",
"description" : "Turn a pile of feature requests into a clear roadmap. Find the need behind each request, count who is asking, score with RICE and say no with care.",
"headline" : "How to prioritise feature requests from customers",
"image" : {
"@type" : "ImageObject",
"height" : 630,
"url" : "https://149472448.fs1.hubspotusercontent-eu1.net/hubfs/149472448/blog-images/p3-og-v4.png",
"width" : 1200
},
"inLanguage" : "en",
"isPartOf" : {
"@id" : "https://www.askthecustomer.ai/blog#blog",
"@type" : "Blog",
"name" : "The AskTheCustomer Blog",
"url" : "https://www.askthecustomer.ai/blog"
},
"mainEntityOfPage" : "https://www.askthecustomer.ai/blog/how-to-prioritise-feature-requests-from-customers",
"publisher" : {
"@id" : "https://www.askthecustomer.ai/#organization"
},
"timeRequired" : "PT11M",
"url" : "https://www.askthecustomer.ai/blog/how-to-prioritise-feature-requests-from-customers",
"wordCount" : 2370
}
```
```json
{
"@context" : "https://schema.org",
"@id" : "https://www.askthecustomer.ai/#organization",
"@type" : "Organization",
"logo" : {
"@type" : "ImageObject",
"height" : 512,
"url" : "https://149472448.fs1.hubspotusercontent-eu1.net/hubfs/149472448/atc-logo.png",
"width" : 512
},
"name" : "AskTheCustomer",
"url" : "https://www.askthecustomer.ai/"
}
```
```json
{
"@context" : "https://schema.org",
"@type" : "BreadcrumbList",
"itemListElement" : [ {
"@type" : "ListItem",
"item" : "https://www.askthecustomer.ai/",
"name" : "Home",
"position" : 1
}, {
"@type" : "ListItem",
"item" : "https://www.askthecustomer.ai/blog",
"name" : "Blog",
"position" : 2
}, {
"@type" : "ListItem",
"item" : "https://www.askthecustomer.ai/blog/how-to-prioritise-feature-requests-from-customers",
"name" : "How to prioritise feature requests from customers",
"position" : 3
} ]
}
```