Objective Prioritisation: ARR

This is one of RoadmapOne’s articles on Objective Prioritisation frameworks .

The enterprise account worth £500k annually asks for SAML SSO. A thousand small businesses worth £5k each ask for better mobile experience. Who wins? Most prioritisation frameworks—RICE, ICE, MoSCoW—score these equally on “reach” or “importance” despite wildly different revenue stakes. ARR prioritisation cuts through the philosophy: it ranks features by the annual recurring revenue requesting them, either cumulatively (sum of all asking customers’ ARR) or weighted (adjusting for strategic importance). Whoever pays the most gets priority.

This feels brutally mercenary—and it is. ARR prioritisation makes explicit what many SaaS companies do implicitly: follow the money. Enterprise customers paying £100k annually get their features built. Freemium users paying £0 get promises and backlogs. The democracy of “one user, one vote” gives way to the plutocracy of “one pound, one vote.” But here’s the uncomfortable truth: if you’re a subscription business living on recurring revenue, ignoring who pays the bills is strategic suicide.

ARR prioritisation works brilliantly when your roadmap must protect revenue—when churn is high, when key accounts threaten to leave, when expansion revenue depends on specific features. It collapses when it turns your product into bespoke consulting, when it starves innovation for enterprise demands, or when short-term revenue optimisation kills long-term strategic positioning. The question isn’t whether to consider ARR—it’s how much weight to give it relative to user reach, strategic bets, and market positioning.

Sign up now to prioritise by revenue impact

What ARR Prioritisation Actually Measures

Annual Recurring Revenue (ARR) is the value of recurring subscription revenue normalised to a one-year period. A customer paying £10k monthly has £120k ARR. A customer on a £50k annual contract has £50k ARR. ARR excludes one-time fees, services revenue, and variable usage charges—it measures only predictable, recurring income.

ARR prioritisation weights features by the ARR of customers requesting them. When fifty customers collectively representing £2M in ARR ask for Salesforce integration, and two hundred customers representing £400k ask for dark mode, Salesforce integration wins—the revenue at stake is 5× higher.

There are two primary methods:

Cumulative ARR: Simple Revenue Summing

The simplest approach: sum the ARR of every customer who requested the feature. If 10 customers with £50k ARR each and 5 customers with £100k ARR want API rate limit increases, the cumulative ARR is £1M. If 200 customers with £2k ARR each want mobile push notifications, cumulative ARR is £400k. The API rate limits win despite serving fewer customers, because the revenue at stake is higher.

Cumulative ARR is transparent and objective: you link feature requests to customer records in your CRM, pull ARR for each requesting account, and sum. Tools like Productboard, Savio, and Canny automate this—filter your feature backlog by cumulative ARR and the revenue-ranked roadmap writes itself.

The trap is treating cumulative ARR as the only input. If your top-20 features by cumulative ARR are all enterprise-specific with zero SMB or consumer benefit, you’ve optimised for protecting current revenue while starving growth. ARR shows you what current customers want; it doesn’t tell you what future customers need or what strategic differentiation demands.

Weighted ARR: Adjusting for Strategic Importance

Weighted ARR divides a customer’s total ARR across all their feature requests, then applies strategic multipliers. If a £100k ARR customer requests five features, each starts with £20k base weight. If one feature is “critical for renewal” (churn risk), you apply a 2× multiplier: £40k. If another feature is “nice to have,” it stays £20k.

Weighted ARR acknowledges that not all feature requests are equal. A customer asking for 20 features represents signal noise; a customer threatening to churn over one feature represents existential risk. Weighting captures urgency and strategic context.

The danger is subjectivity masquerading as data. If customer success teams label every enterprise request “critical for renewal” to inflate priority, weighted ARR becomes political lobbying dressed in spreadsheets. The cure is discipline: limit “critical” multipliers to accounts with documented churn risk (renewal in next 90 days, executive escalation, competitive threat). Public calibration—showing how weights were assigned—keeps the process honest.

The Three Variables That Define ARR Scoring

Customer ARR: Who’s Requesting This?

The foundation: link feature requests to customer records and pull ARR. This requires integration between your product feedback tool (Productboard, Canny, etc.) and CRM (Salesforce, HubSpot). Without integration, you’re manually tagging requests with account IDs—tedious and error-prone.

Clean data matters. If your CRM conflates expansion revenue with base ARR, or includes one-time implementation fees, your ARR figures are inflated. If customer success logs requests inconsistently (sometimes tagging accounts, sometimes not), your cumulative ARR is partial. Garbage data produces garbage prioritisation.

The trap is ignoring who’s NOT asking. If your £2M enterprise accounts are silent while £50k SMB accounts flood requests, cumulative ARR makes SMB features look critical—but your largest customers might be satisfied or already churning silently. ARR prioritisation reflects vocal customers, not strategic importance.

Request Volume: How Many Customers Want This?

Pure ARR ignores reach. If one £1M customer asks for a feature, cumulative ARR is £1M. If 500 customers averaging £2k ARR ask for a different feature, cumulative ARR is also £1M. Are they equal?

Most teams combine ARR with request count: high cumulative ARR plus high request volume signals broad, revenue-critical demand. High ARR with low volume signals enterprise-specific need. Low ARR with high volume signals SMB or consumer demand with limited revenue. Each pattern informs different decisions.

Churn Risk: Is Revenue at Stake Immediately?

ARR sitting comfortably in locked contracts prioritises differently than ARR at risk. If a £500k customer threatens to cancel in 60 days unless you build SCIM provisioning, that £500k carries existential urgency. If a £500k customer casually mentions they’d love a feature “someday,” the urgency is low.

Weighted ARR incorporates churn risk: multiply base ARR by churn probability. A £100k account renewing in 90 days with “medium churn risk” might get 1.5× weight (£150k effective). An account threatening immediate cancellation gets 2-3× weight. An account locked in a three-year contract gets 1× or even 0.8× (they’re not leaving regardless).

The discipline is calibration: track whether high-weight “critical for renewal” features actually prevented churn. If you prioritise ten “critical” features and eight accounts churned anyway, either your weighting is broken or the features weren’t actually critical. Honest retrospectives improve future scoring.

ARR Prioritisation in Action: Three Scenarios

Scenario A: Enterprise SSO vs Consumer Mobile Redesign

You’re a B2B SaaS product with both enterprise and SMB customers.

Feature 1: SAML SSO for Enterprise Accounts

• Requesting customers: 8 enterprise accounts
• Cumulative ARR: £720,000 (average £90k per account)
• Request count: 8
• Churn risk multiplier: 2× (three accounts up for renewal, SSO is blocker)
• Weighted ARR Score: £720k × 2 = £1,440,000

Feature 2: Mobile App Redesign

• Requesting customers: 340 SMB accounts
• Cumulative ARR: £680,000 (average £2k per account)
• Request count: 340
• Churn risk multiplier: 1× (general satisfaction issue, not immediate churn)
• Weighted ARR Score: £680k × 1 = £680,000

ARR prioritisation says: Build SAML SSO. The revenue at immediate risk (£720k with churn threat) dwarfs the mobile redesign despite 42× fewer customers requesting it. The enterprise accounts threaten to leave; the SMB accounts are frustrated but not cancelling.

Strategic override question: If you always prioritise enterprise, when do you build for SMB growth? If mobile redesign enables 50% faster SMB acquisition and SMB accounts represent future growth, ignoring it for enterprise firefighting starves your growth engine. ARR prioritisation identifies the revenue reality; you must decide if protecting existing revenue trumps enabling future revenue.

Scenario B: API Rate Limits vs Collaboration Features

Feature 1: Increase API Rate Limits

• Requesting customers: 5 high-volume API users
• Cumulative ARR: £950,000 (average £190k per account)
• Request count: 5
• Churn risk multiplier: 1.5× (one account threatened to leave, others frustrated)
• Weighted ARR Score: £950k × 1.5 = £1,425,000

Feature 2: Team Collaboration & Commenting

• Requesting customers: 150 mid-market accounts
• Cumulative ARR: £900,000 (average £6k per account)
• Request count: 150
• Churn risk multiplier: 1× (nice-to-have, not renewal blocker)
• Weighted ARR Score: £900k × 1 = £900,000

ARR prioritisation says: Increase API rate limits. Five power users generating nearly £1M ARR are hitting constraints; losing them is catastrophic. Collaboration features serve 30× more customers but with lower individual revenue and no immediate churn risk.

Strategic reality check: The five API power users are on custom enterprise plans—you could negotiate rate limit increases case-by-case without building scalable infrastructure. The 150 collaboration requests signal a product gap affecting mid-market expansion. ARR prioritisation correctly identifies revenue at risk, but solving it might not require a product solution—sales can negotiate bespoke contracts. Meanwhile, ignoring collaboration features caps your mid-market growth.

Scenario C: Reporting Dashboard vs Third-Party Integrations

Feature 1: Advanced Reporting Dashboard

• Requesting customers: 12 customers (mix of enterprise and mid-market)
• Cumulative ARR: £400,000 (average £33k per account)
• Request count: 12
• Churn risk multiplier: 1.2× (common in churned customer exit interviews)
• Weighted ARR Score: £400k × 1.2 = £480,000

Feature 2: Zapier Integration

• Requesting customers: 60 SMB and prosumer accounts
• Cumulative ARR: £180,000 (average £3k per account)
• Request count: 60
• Churn risk multiplier: 1× (feature request, not churn driver)
• Weighted ARR Score: £180k × 1 = £180,000

ARR prioritisation says: Build reporting dashboard. Higher cumulative ARR, churn-correlated in exit interviews, and serves paying customers.

Long-term strategic question: Zapier integration unlocks 3,000+ app connections and serves as a growth multiplier—new customers sign up because “it integrates with everything.” The reporting dashboard serves existing customers better but doesn’t drive new acquisition. If your growth challenge is top-of-funnel, ARR prioritisation optimises for retention while starving acquisition. Both matter, but ARR only sees one.

When ARR Is Your Best Weapon

ARR prioritisation excels in four contexts.

First: Protecting high-value customer accounts. When enterprise accounts collectively representing millions in ARR threaten churn unless specific features ship, ARR prioritisation quantifies the decision. Losing a £500k account is worse than frustrating fifty £2k accounts. ARR makes the trade-off transparent: protect the revenue that pays the bills.

Second: Revenue-driven product-market fit. In early SaaS growth, you’re still discovering which customer segments value your product most. ARR prioritisation reveals it: if £2M in ARR comes from healthcare customers requesting compliance features, while £200k comes from retail asking for different features, double down on healthcare. Your product-market fit is healthcare; retail is distraction. ARR shows you where the money is.

Third: Transparent stakeholder communication. When sales, customer success, and product argue about roadmap priorities, ARR depersonalises the debate. “This feature represents £1.2M in at-risk ARR” beats “my customer really wants this.” ARR quantifies whose pain matters most financially, replacing lobbying with data.

Fourth: Balancing quick wins and enterprise demands. Combining ARR with effort estimates (ARR per engineering-month) surfaces high-revenue, low-effort opportunities. A £300k ARR feature requiring two engineers for one month scores better than a £600k feature requiring six engineers for six months. ARR per effort optimises for revenue velocity, not just total revenue.

When ARR Betrays You

ARR prioritisation collapses in three scenarios.

First: When it turns your product into a consulting service. If every enterprise customer requests bespoke features and you prioritise by cumulative ARR, your roadmap becomes a Frankenstein of one-off customisations. You’re no longer building a scalable product—you’re doing services work disguised as SaaS. The cure is filtering: only score features requested by 3+ customers or 10+ total requests. Single-customer requests, regardless of ARR, get escalated for strategic review, not automatic prioritisation.

Second: When it starves strategic innovation. ARR reflects what current customers want from the current product. It doesn’t tell you what adjacent markets need, what disruptive competitors are building, or what future customers will demand. If you follow ARR strictly, you optimise the current product for the current customer base while missing market shifts. The fix is reserving 20-30% of capacity for strategic bets that score low on ARR but high on “Transform” or “Market Expansion” tags.

Third: When weighting becomes political theatre. If every stakeholder inflates their features’ churn risk multiplier to game priority, weighted ARR is lobbying with extra steps. Sales marks every feature “critical for this quarter’s deals.” Customer success labels everything “high churn risk.” Product VPs apply “strategic importance” multipliers to pet projects. Soon weighted ARR correlates more with political power than revenue risk. The cure is public calibration: show historical data on which “critical” features actually closed deals or prevented churn, and penalise repeat offenders who cry wolf.

Practical Implementation: From CRM to Roadmap

Step 1: Integrate Your Product Feedback Tool with CRM

ARR prioritisation requires linking feature requests to customer ARR. Tools like Productboard, Canny, and Savio offer native CRM integrations (Salesforce, HubSpot). When a customer requests a feature, the tool automatically pulls their ARR, contract end date, and account segment.

Without integration, you’re manually tagging requests—tedious, error-prone, and out-of-date within weeks. Pay for the integration or build it. ARR prioritisation without clean data is fantasy.

Step 2: Define Cumulative ARR for Each Feature

Sum the ARR of every customer who requested the feature. Your product feedback tool should show this automatically: sort features by cumulative ARR descending. The top features represent the most revenue at stake.

Add a secondary sort by request count. Features with high ARR and high volume are no-brainers. High ARR with low volume are enterprise-specific. Low ARR with high volume are SMB/consumer growth plays.

Step 3: Apply Churn Risk Multipliers (If Using Weighted ARR)

For features flagged “critical for renewal” or “churn risk,” multiply base ARR by urgency:

• 3× multiplier: Account cancelling in next 30 days, executive escalation, feature is documented blocker
• 2× multiplier: Renewal in 60-90 days, expressed dissatisfaction, competitive threat
• 1.5× multiplier: General frustration, mentioned in NPS feedback, medium churn risk
• 1× multiplier: Feature request with no churn signal

Document why each multiplier was applied. Public transparency prevents gaming.

Step 4: Combine ARR with Effort Estimates

Calculate ARR per engineering-month: divide cumulative ARR by effort (in person-months). A £600k ARR feature requiring 6 person-months scores 100k ARR/month. A £300k ARR feature requiring 2 person-months scores 150k ARR/month. The second feature delivers more revenue per unit effort.

This prevents ARR prioritisation from always favouring giant enterprise projects that lock up capacity for quarters. Sometimes five small features collectively deliver more revenue velocity than one massive feature.

Step 5: Filter for Reach Threshold

Implement a minimum reach filter: only score features requested by 3+ customers or 10+ individuals. This prevents single-customer bespoke requests from dominating the roadmap regardless of ARR. If a £1M customer requests something unique, escalate it for strategic review—don’t auto-prioritise.

Step 6: Reserve Capacity for Strategic Overrides

Fund the top ARR-scored features for 60-70% of capacity. Reserve 20-30% for strategic bets that score low on ARR but high on market positioning, innovation, or future revenue enablement. Tag these explicitly: “Strategic Bet,” “Market Expansion,” “Platform Investment.”

Track strategic overrides separately. If they consistently fail (don’t generate expected future ARR or market traction), your override criteria are broken. Recalibrate.

Step 7: Track Predictive Accuracy

Six months post-launch, compare actual revenue impact to projected ARR. If a feature projected to protect £500k ARR and three of five requesting customers still churned, the feature didn’t solve their problem—or churn drivers were misdiagnosed. If a feature projected to generate £200k expansion revenue delivered £600k, your estimation was conservative.

Calibration improves future ARR scoring. Publish retrospectives: which high-ARR features delivered? Which flopped? Teams learn to weight ARR requests by historical customer segment accuracy.

The Dark Side: When ARR Kills Your Product Vision

The most dangerous failure mode is feature factory syndrome: your roadmap becomes a ranked list of customer requests, and you build whatever the highest-paying customers ask for. Product strategy dies. You’re no longer shaping a market or creating a vision—you’re taking orders.

This happens when ARR prioritisation becomes the only input. Sales promises features to close deals, customer success escalates every request as “critical,” and the roadmap is a backlog sorted by revenue. The product team becomes an execution engine, not a strategy function.

The antidote is dual-lens prioritisation: use ARR to understand revenue at stake, but overlay strategic filters. Every quarter, generate two reports side-by-side:

1. ARR-ranked roadmap: Top features by cumulative/weighted ARR
2. Strategic tag distribution: Are funded features balanced across Run/Grow/Transform? Core/Adjacent/Transformational? Risk types?

If the ARR-ranked roadmap is 90% “Run” work (protecting existing revenue) with 3% “Transform” (future bets), override deliberately. Fund strategic innovation even if it scores low on ARR. Tag it, track it, and hold it accountable to future revenue impact.

ARR vs RICE: When to Use Which

RICE optimises for value per effort across all users. ARR optimises for revenue per effort across paying customers. Use RICE when:

• Your revenue model isn’t subscription-based
• Customer segment value is roughly equal (B2C, prosumer)
• Strategic reach matters more than revenue concentration
• You’re optimising for growth, not retention

Use ARR when:

• You’re a B2B SaaS business with recurring revenue
• Customer value varies widely (£2k SMB to £500k enterprise)
• Churn is high and revenue retention is critical
• You need to justify roadmap decisions with revenue impact

Many teams use both: ARR for enterprise-facing features, RICE for platform and consumer features. This acknowledges that enterprise roadmap decisions are revenue-driven, while foundational and growth work requires different lenses.

ARR and Board-Level Storytelling

Presenting ARR-based roadmaps to boards and investors is powerful because it speaks their language: revenue retention, expansion opportunity, and churn reduction.

Imagine presenting: “We prioritised features by cumulative ARR—the revenue at stake if we don’t build them. Our top 15 features represent £4.2M in at-risk ARR, spanning 180 customer accounts. We funded features covering £3.1M ARR with available capacity, protecting 74% of at-risk revenue. We explicitly deferred three features representing £800k ARR because they’re single-customer requests—we’ll address them through custom contracting, not product investment. We reserved 25% capacity for strategic bets in adjacent markets that score low on current ARR but unlock future growth.”

The board debates strategic trade-offs—how much to protect current revenue versus enabling future revenue—not individual features. ARR makes the trade-off quantified and transparent.

When to Override ARR (And How to Do It Transparently)

ARR is a tool, not doctrine. Override ARR when:

• Strategic market positioning: A feature unlocks a new market or competitive moat, even if current ARR is low
• Platform bets: Infrastructure that enables future features but serves no immediate customer request
• Innovation and differentiation: Capabilities that differentiate you long-term but aren’t customer-requested
• Ecosystem and partnerships: Integrations or partnerships that create strategic leverage

Tag overrides explicitly: “Market Expansion,” “Platform Bet,” “Innovation.” Reserve 20-30% capacity for them. Track whether they deliver future ARR or market advantage. If strategic overrides consistently fail, tighten criteria.

RoadmapOne supports ARR-based prioritisation with CRM integration, cumulative ARR scoring, and strategic tagging. Score objectives by ARR, fund the top scores, then review tag distributions. If high-ARR features form an unbalanced portfolio (90% enterprise, 5% SMB growth), override deliberately to protect future revenue streams.

The Honest Conversation: Who Pays Decides

ARR prioritisation forces a conversation most product teams avoid: whose needs matter most? The democratic ideal says “every user’s feedback is equal.” The business reality says “customers paying £100k annually matter more than freemium users paying £0.”

ARR makes this explicit. It’s uncomfortable but honest. If you’re a subscription business, revenue determines survival. Ignoring who writes the cheques is idealism that leads to bankruptcy. ARR prioritisation acknowledges reality: your highest-value customers get prioritised because losing them kills the business.

But ARR can’t be the only lens. Today’s £2k SMB customer might be tomorrow’s £200k enterprise account. Today’s freemium user spreading word-of-mouth might drive £1M in future ARR. Optimising purely for current ARR starves growth. Balance is essential: use ARR to protect revenue, but reserve capacity for strategic bets that generate future ARR.

If you take only three ideas from this essay, let them be:

1. ARR Prioritisation Makes Revenue Explicit. Most frameworks treat all customers equally. ARR acknowledges that a £500k enterprise account and a £5k SMB account don’t have equal strategic weight. ARR quantifies whose needs matter most financially—protecting you from democratic roadmap paralysis while forcing honesty about who you serve.

2. Cumulative ARR + Churn Risk = Weighted Priority. Raw ARR summing is a starting point. Sophisticated ARR prioritisation weights by churn risk, request volume, and strategic segment. A £200k ARR feature requested by one customer with low churn risk scores differently than a £200k feature requested by ten customers threatening to cancel. Weighting captures urgency and strategic context.

3. Reserve Capacity for Strategic Overrides or Die Slowly. If you follow ARR blindly, you optimise for current revenue while starving future growth. Reserve 20-30% of capacity for strategic bets that score low on ARR today but unlock market expansion, innovation, and platform leverage tomorrow. Track whether overrides deliver future ARR—and tighten criteria if they don’t.

RoadmapOne enables ARR-driven prioritisation for subscription businesses where revenue concentration varies. Link features to customer ARR, score by cumulative or weighted ARR, and fund what protects revenue. Then overlay strategic tags to ensure you’re not starving growth for retention.

ARR prioritisation isn’t about abandoning product vision—it’s about acknowledging who funds that vision. Use ARR to protect the revenue that pays the bills, then invest strategically in the revenue that doesn’t exist yet.

For more on Objective Prioritisation frameworks, see our comprehensive guide .