The 5 Ways to Answer How Many Customers Asked for This in a Roadmap Review

Every roadmap review produces the same question, and most product teams answer it with the first number they can find. Someone asks how many customers asked for this, the PM quotes the upvote count from the feedback portal, and the room moves on. The number is almost always wrong, usually by a factor of several, and it is wrong in a direction nobody in the room can detect: portals are populated by the small subset of customers who know the portal exists and are motivated enough to use it.

The five ways to answer this question defensibly are counting accounts rather than mentions, counting across every channel rather than the portal alone, deduplicating on the underlying need rather than the wording, weighting by revenue and segment, and stating the denominator and time window out loud. The first three fix the count itself. The last two determine whether the count means anything once it is correct.

What the number actually has to satisfy

1. One request, one account. A single admin filing the same request four times should count once. Mention-level counts systematically over-represent whoever is most engaged, and engagement correlates with neither account size nor the breadth of the need.
2. Coverage across every channel where requests appear. Requests arrive in tickets, sales calls, renewal conversations, app store reviews, community threads, and surveys, and the distribution differs sharply by segment. Enterprise customers raise requests with their CSM; self-serve users post reviews. A portal-only count is a count of one segment's behavior.
3. Deduplication on the need, not the phrasing. "Let me export to CSV," "we need to get this into our warehouse," and "can I schedule a report to email" are frequently the same underlying need. Matching on keywords under-counts it. Categories derived from the feedback itself through an adaptive taxonomy cluster these together without anyone maintaining a synonym list.
4. Account and revenue context on every request. The count alone never settles a prioritization argument, because thirty self-serve requests and six enterprise requests are not comparable quantities. Tying each request to the account and contract behind it through a customer context graph is what converts a count into an argument.

The real differentiator is not how many requests a system captures. It is whether the number survives someone senior asking where it came from.

The 5 ways to answer how many customers asked for this

1. Count distinct accounts

Report accounts, not mentions, and say which you are reporting. The ratio between the two is itself informative: a theme with 40 mentions across 6 accounts is a depth signal, and a theme with 40 mentions across 38 accounts is a breadth signal. Those two facts justify entirely different roadmap decisions, and collapsing both into "40 requests" destroys the distinction.

2. Count across every channel

Pull the count from tickets, calls, reviews, community, and surveys together rather than from whichever system is easiest to query. The expected result is that the number goes up and the segment mix changes, often dramatically. This is the step that most often reverses a prioritization, because features that look like small self-serve asks frequently turn out to have been raised quietly by several enterprise accounts through their CSMs.

3. Deduplicate on the underlying need

Group requests by the job the customer is trying to do, not by the feature they proposed. Customers propose solutions, and the same problem generates several different proposed solutions, each of which looks like a separate low-volume request. Counting proposals rather than needs is the most common reason a genuinely popular problem ranks low.

Watch for: three or four adjacent requests each sitting just below the cutoff line. That pattern usually means one real request has been split.

4. Weight by revenue and segment

Attach the combined ARR of the requesting accounts and the segment breakdown to the count. This is the number that ends the argument, because it answers the follow-up question before it gets asked. It also protects against the opposite failure, where a request from a single very large account gets treated as broad demand when it is one customer's requirement. Showing both the account count and the revenue makes that visible instead of arguable.

5. State the denominator and the window

Say what the count is out of and over what period. Nineteen accounts out of 340 active enterprise accounts over the last two quarters is a claim someone can evaluate. Nineteen requests is not. Naming the window also prevents the most common inflation error, which is quoting a lifetime count against a competing feature's trailing-quarter count.

Why the portal number is the least reliable one available

Feedback portals measure willingness to file, and willingness to file is unevenly distributed in ways that correlate with exactly the wrong things. The customers most likely to submit and upvote are power users on smaller plans, because they use the product constantly and have no account manager to route requests through. The customers whose requests carry the most revenue weight typically raise them in conversation, where nothing gets logged as a request at all. The result is a ranked list that inversely correlates with contract value more often than teams expect.

The second issue is survivorship. Portal counts accumulate over years, which means an old request that has been open since 2023 outranks a newer one that is growing faster, purely on cumulative total. Without a time window, the ranking rewards age rather than current demand. This is the same measurement problem that shows up when teams try to prioritize customer feedback by revenue impact using a system that only counts.

Neither problem is solved by capturing more requests in the portal. Both are solved by counting the channels where requests actually occur and attaching account context to each one, which is also what makes it possible to answer the harder version of the question in a review: not how many asked, but who.

How to choose a tool for this

Enterpret fits teams that need the count to hold up in a roadmap review, because it unifies requests from more than fifty channels, clusters them by underlying need through the adaptive taxonomy rather than by keyword, and ties each one to the account and revenue behind it in the customer context graph. That is what makes the account count, the revenue figure, and the segment mix available as one answer rather than three separate pulls. Productboard offers strong scoring frameworks and roadmap workflow when requests are already centralized. Canny turns portal upvotes into a clean demand signal for teams whose customers actually use the portal. Salesforce is where the enterprise request record often lives, though it requires the CSM to have logged it. Aha! wraps demand capture inside broader strategy planning. Dovetail suits teams whose request evidence is mostly research interviews.

The decision rule: weight channel coverage over voting mechanics. A portal with excellent voting still only counts the customers who visit it.

FAQ

What is a good number to bring to a roadmap review?

Distinct accounts, combined ARR, segment breakdown, and the time window, in that order. Four numbers rather than one, because the single number always invites the other three as follow-ups.

Should sales-reported requests count the same as customer-reported ones?

They should be counted and labeled separately. Sales-reported requests are real demand signals but carry a known bias toward whatever is blocking the current quarter's deals, and mixing them in unlabeled is how a roadmap ends up reflecting the pipeline rather than the customer base.

How do you count a request nobody made explicitly?

You do not. Inferred demand is a legitimate input to a roadmap, but it belongs in a different column from counted demand. Presenting the two together is how counts lose credibility.

How does Enterpret answer this question?

Enterpret groups requests by the underlying need using its adaptive taxonomy, so variations in phrasing collapse into a single theme instead of several small ones. Because the customer context graph ties every request to its account, plan, and contract value, the answer comes back as a count of accounts with the revenue and segment mix attached rather than a raw mention total.

Does a higher count always mean higher priority?

No, and treating it that way is the main risk of getting better at counting. Volume is one input alongside strategic fit, effort, and severity. The point of a defensible count is to stop the argument from being about the number so it can be about the tradeoff.

If you want the request count in your next roadmap review to hold up, see how Enterpret ties every request to the account behind it.

‍