# How do you prioritize feature requests by ARR?

userhero.io · August 22, 2026

> Prioritizing feature requests by ARR (annual recurring revenue) means weighting every incoming request by the annual contract value of the account...

Prioritizing feature requests by ARR (annual recurring revenue) means weighting every incoming request by the annual contract value of the account asking for it, so that a $120,000/year enterprise customer's ask counts as much as twelve $10,000/year customers' asks combined. It is one of the most defensible ways to rank a backlog when you serve B2B customers of very different sizes, because it ties product decisions directly to revenue retention and expansion. The direct answer: calculate each request's ARR weight, combine it with request frequency and strategic fit into a single score, then sort your backlog by that score rather than by recency or loudness.

## What ARR-Based Prioritization Actually Means

**Also worth reading:** [How do you use RICE scoring with ARR data to prioritize product features for B2B SaaS?](https://userhero.io/knowledge/how_do_you_use_rice_scoring_with_arr_data_to_prioritize_product_features_for_b2b_saas.php) · [How to prioritize customer feedback with AI?](https://userhero.io/knowledge/how_to_prioritize_customer_feedback_with_ai.php) · [What are constraints in product development and operations, and how should product and support teams use them to prioritize work in 2026?](https://userhero.io/knowledge/what_are_constraints_in_product_development_and_operations_and_how_should_product_and_support_teams_use_them_to_prioritize_work_in_2026.php)

ARR-based prioritization assigns each feature request a monetary weight derived from the requesting accounts' annual recurring revenue. If a customer paying $50,000 per year requests SSO, that request carries an ARR weight of $50,000. If five customers paying $8,000 each request the same thing, the aggregate weight is $40,000. When the same feature is requested by multiple accounts, you sum their ARR values to get a total demand figure in dollars rather than in vote counts.

This approach exists because raw vote counts systematically underrepresent enterprise needs. A single enterprise account can represent 5-15% of total company ARR at many B2B SaaS companies, yet it gets exactly one vote in a democratic upvoting system like a public roadmap board. Meanwhile, dozens of small accounts can outvote it on features that matter little to revenue. Weighting by ARR corrects this distortion and forces conversations about whether a feature is worth building for the customers who fund the business.

The method is not without critics. Some product leaders argue it turns your roadmap into a captive development shop for your biggest logos, starving innovation that would attract new segments. That criticism is valid if ARR is the only input. Used as one weighted factor among several — alongside frequency, strategic fit, and effort — it becomes a strong signal rather than a tyrant. Most mature B2B product teams land on ARR as roughly 30-50% of the prioritization score, not 100%.

## Why Revenue-Weighted Prioritization Works

The core logic is simple: churn and expansion are the two largest levers on net revenue retention, and both are driven disproportionately by what your highest-ARR customers experience. Industry benchmarks consistently show that acquiring a new customer costs 5-7 times more than retaining an existing one, and that improving retention by just 5% can increase profits by 25-95% depending on the model. When a top-decile account threatens to churn over a missing integration, the cost of ignoring that request is measured in hundreds of thousands of dollars, not in one lost seat.

ARR weighting also disciplines internal stakeholders. Sales teams are notorious for escalating whatever their current deal needs, and support teams escalate whatever generated the most tickets last week. Converting both signals into dollars creates a common currency. A sales escalation on behalf of a $15,000 prospect can be compared honestly against a support-driven request from a $90,000 existing customer. Without dollar weights, these debates devolve into who argues loudest or who has the most senior title in the room.

There is a second-order benefit: ARR-weighted data makes roadmap communication easier. When a customer asks why their feature has not shipped, you can explain that the aggregated demand behind competing items was three times higher in revenue terms. Customers may still be unhappy, but the reasoning is transparent and consistent, which preserves trust far better than vague promises. Teams using structured feedback tools report that visible, criteria-based ranking reduces repeat escalations noticeably within two quarters.

## How to Calculate an ARR Weight for Each Request

Start by tagging every feedback item with the account(s) that submitted it. Pull each account's current ARR from your billing system — Stripe, Chargebee, Salesforce, or your CPQ — and normalize it. For annual contracts, use the contracted value; for monthly plans, multiply MRR by 12. Exclude discounts and one-time services so you are measuring true recurring value. If a request comes from a prospect rather than a customer, either exclude it or assign it a projected first-year ARR at a reduced confidence multiplier, commonly 0.3-0.5x, since deals close unreliably.

Next, decide how to handle multi-account aggregation. The standard formula is: Request ARR Score = sum of ARR across all requesting accounts. But raw sums let one whale dominate everything. Two refinements fix this. First, apply a concentration cap: no single account contributes more than 20-30% of any request's score, which prevents a $500,000 logo from single-handedly forcing a feature onto the roadmap. Second, add a breadth bonus: multiply the summed ARR by a factor between 1.0 and 1.5 based on how many distinct accounts requested it, rewarding broad demand over narrow demand.

A practical scoring template looks like this. Take the log or square root of summed ARR to compress outliers — sqrt($250,000) = 500 versus sqrt($25,000) = 158, a gentler gap than 10x. Then divide by your median customer ARR to produce a dimensionless index where 1.0 equals average-customer demand. Requests scoring above 2.0 deserve active roadmap consideration; below 0.5 they belong in a parking lot reviewed quarterly. Calibrate these thresholds against your own distribution after 60-90 days of data collection rather than adopting someone else's numbers blindly.

## Building the Full Prioritization Score

ARR alone is insufficient, so most teams fold it into a composite score. A widely used structure is: Priority Score = (ARR Index × W1) + (Account Count × W2) + (Strategic Fit × W3) − (Effort × W4). Weights might be 40% ARR, 20% breadth, 25% strategic fit, and 15% effort, adjusted to your context. Strategic fit is scored 1-5 by product leadership against your stated strategy — for example, whether the feature supports expansion into mid-market or deepens enterprise stickiness. Effort is estimated in engineer-weeks by the team that would build it.

Some teams prefer established frameworks with ARR grafted on. RICE (Reach, Impact, Confidence, Effort) can substitute ARR-weighted reach for raw user counts. Weighted Shortest Job First from SAFe translates naturally too: Cost of Delay can be expressed in ARR-at-risk, divided by job size. Kano modeling adds a different lens — categorize requests as basic expectations, performance drivers, or delighters — and then apply ARR weighting within each category, since a missing basic expectation from a large account usually outranks a delighter from anyone.

Whatever composite you choose, publish the formula internally. The score's political value depends on everyone trusting it, and trust requires transparency about inputs and weights. Re-score the backlog monthly, not continuously; constant re-scoring creates whiplash where engineers start work on an item only to see it drop below the cut line a week later. A monthly cadence aligned to sprint planning gives stability while keeping the queue current.

## Comparing ARR-Weighting Against Alternative Methods

No prioritization method fits every company, and honest comparison reveals real trade-offs. The table below summarizes how ARR-weighted scoring stacks up against the most common alternatives used by B2B product teams today.

| Dimension | ARR-Weighted Scoring | Raw Vote Counting | RICE | Opportunity Scoring |
| --- | --- | --- | --- | --- |
| Core input | Customer revenue | Number of votes | Reach × Impact ÷ Effort | Importance vs satisfaction gap |
| Enterprise bias | High (intentional) | Low | Medium | Low |
| Data required | Billing + feedback tags | Feedback board only | Traffic + estimates | Survey data |
| Setup time | 2-4 weeks | Days | 1-2 weeks | 4-8 weeks |
| Risk | Whale capture, short-termism | Loud-minority distortion | Impact guesses inflate scores | Survey fatigue, stale data |
| Best fit | B2B with concentrated ARR | Consumer or PLG products | Products with usage analytics | Mature products with survey programs |

Vote counting wins on simplicity and works reasonably well for product-led-growth companies with thousands of similar-sized users, where no single account matters much individually. Its failure mode in B2B is structural: one vote per account regardless of spend. RICE handles volume better but its "Impact" estimate is notoriously gameable, and it ignores who is asking entirely. Opportunity scoring produces excellent insight into underserved jobs-to-be-done but requires ongoing survey investment that most teams abandon within two quarters.
The pragmatic answer for most B2B SaaS companies between roughly $1M and $50M ARR is a hybrid: ARR-weighted scoring for the top of the funnel of requests, with qualitative judgment applied to the final 20% of roadmap slots reserved for strategic bets. Bessemer's published scaling guidance for companies moving from $1M to $10M ARR emphasizes exactly this kind of focus discipline — concentrating resources on the highest-revenue-consequence work while protecting some capacity for future growth vectors.

## Common Mistakes When Prioritizing by ARR

The most frequent error is treating ARR as the entire decision. Teams that do this become reactive vendors to their largest customers, shipping bespoke-feeling features that bloat the product and repel smaller buyers. Guard against it by capping any single account's influence and reserving 15-25% of engineering capacity for non-requested strategic work, every quarter, without exception.

The second mistake is stale or sloppy ARR attribution. Feedback arrives through support tickets, sales calls, Slack communities, and feature boards; if tagging is inconsistent, your scores are fiction. Assign clear ownership — often a support ops or product operations person — for ensuring every request carries accurate account metadata within 48 hours of arrival. Companies that skip this step typically find 30-40% of their feedback unattributable when they first audit it, which quietly corrupts every downstream score.

Third, teams confuse stated requests with underlying problems. A $200,000 account demanding a specific report format may actually need export flexibility, and building the literal request solves nothing. Apply ARR weighting to problems, not solutions: cluster related requests by the job they serve before scoring them. This clustering step routinely cuts apparent backlog size by half and surfaces demand patterns invisible at the individual-request level.

Finally, watch for recency bias sneaking back in. A big customer's renewal negotiation creates urgency pressure that inflates their requests' perceived priority beyond what the math says. Decide in advance whether renewal risk adjusts scores — some teams add a churn-risk multiplier of 1.2-1.5x for accounts flagged red in health scoring — and apply it uniformly rather than deal-by-deal.

## When to Act and How to Operationalize It

Adopt ARR-based prioritization once you have at least 30-50 paying B2B accounts and meaningful ARR concentration — typically when your top 10 customers exceed 30% of total revenue. Below that scale, you have too few data points for weighting to mean anything, and founder judgment plus direct customer conversations outperform any scoring system. Above roughly $100M ARR with thousands of accounts, pure ARR weighting flattens out too, and segment-level analysis (by tier, industry, or lifecycle stage) becomes more informative than account-level sums.

Operational rollout takes about four to six weeks. Week one: connect billing data and define the ARR normalization rules. Weeks two and three: backfill tags on your existing feedback inventory and set up automatic tagging for new inbound requests across support, sales, and community channels. Week four: run the first scoring pass and review results with sales, support, and engineering leads to sanity-check outliers. Weeks five and six: finalize weights, publish the formula, and slot the top-ranked items into the next planning cycle. Centralizing inbound signals in a shared inbox built for product and support teams — rather than scattering them across spreadsheets and chat threads — is what keeps the tagging sustainable long-term; tools like Canny (estimated around $3.5M ARR as a bootstrapped player in this space) demonstrate there is durable demand for exactly this workflow.

Review cadence matters as much as setup. Re-score monthly, re-rank quarterly, and audit the model annually against outcomes: did high-ARR-scored features actually correlate with retention and expansion? If after two quarters the correlation is weak, adjust weights toward strategic fit or breadth. The scoring system should evolve with your business, not ossify into ritual.

## Costs, Tools, and Practical Constraints

The direct cash cost of ARR-based prioritization is mostly tooling and labor. Dedicated feedback management platforms run roughly $50-$600 per month at small-to-mid scale depending on seats and tracked accounts, with enterprise tiers exceeding $1,000 monthly. Many teams start free — a spreadsheet joining billing exports to a tagged feedback list costs nothing and handles a few hundred requests fine. The larger investment is time: expect 4-8 hours weekly across product ops and support leadership to maintain tagging quality during the first quarter, dropping to 1-2 hours once automation and habits settle.

Hidden costs deserve honesty. Sales cycles slow slightly when reps must log requests properly instead of firing off Slack messages. Engineering estimation overhead grows because effort scores need real input. And there is an opportunity cost in debate time — the first two months of running the system generate more cross-functional meetings than ad-hoc prioritization ever did. Budget for that friction; it is the price of replacing politics with arithmetic, and it pays back once the process stabilizes.

For teams evaluating build-versus-buy, the deciding factors are volume and channel count. Under roughly 100 new requests per month arriving through two or fewer channels, a spreadsheet plus discipline suffices. Beyond that, dedicated signal-management tooling pays for itself in recovered analyst hours alone, before counting the retention value of never losing an enterprise request in a forgotten ticket queue.

## Quick answers

### Should prospects' feature requests count toward ARR scoring?

Generally yes, but discounted. Assign projected first-year ARR multiplied by a confidence factor of 0.3-0.5x, since open deals close unreliably. This lets sales-influenced demand compete fairly without letting unearned pipeline dominate the roadmap.

### What percentage of my prioritization score should ARR represent?

Most effective setups weight ARR at 30-50% of a composite score, with the remainder covering request breadth, strategic fit, and build effort. Using ARR as 100% of the score tends to make the roadmap purely reactive to your largest customers.

### How do I stop one huge customer from dominating the roadmap?

Apply a concentration cap so no single account contributes more than 20-30% of any request's total ARR score, and consider compressing values with a square-root transform. Also reserve 15-25% of engineering capacity per quarter for strategic work no customer requested.

### Is ARR-based prioritization right for early-stage startups?

Usually not below roughly 30-50 paying accounts. With few customers, ARR concentration is extreme and sample sizes are tiny, so founder judgment and direct conversations beat any scoring model. Adopt formal ARR weighting once your top 10 customers exceed about 30% of revenue.

### How often should I re-score the feature backlog?

Re-score monthly and formally re-rank quarterly, aligned to planning cycles. Continuous re-scoring causes whiplash where engineers start items that then fall below the cut line, while annual-only reviews let the queue drift badly out of date.

Canonical: https://userhero.io/knowledge/how_do_you_prioritize_feature_requests_by_arr.php
Markdown: https://userhero.io/knowledge/how_do_you_prioritize_feature_requests_by_arr.php/index.md