How to weight feature requests by Stripe ARR instead of vote count
The method is a join, not a formula. For every feature request, list the distinct accounts asking for it, look up each account's annual recurring revenue in Stripe, and sum it. Rank features by that summed ARR instead of by vote count. A request with three enterprise accounts behind it can outrank one with thirty free-trial upvotes, because thirty trial accounts might be worth less combined than one of the three.
Stripe won't hand you that number directly. There's no ARR field on a Customer object; a customer carries an email, a balance, and a metadata map, nothing that says what they pay annually. You derive it from their active subscription instead. Each Price carries a unit_amount and a recurring.interval (month, year, week). That unit_amount is denominated in the smallest currency unit, cents for USD, so a $49/month price stores unit_amount: 4900, not 49. ARR is (unit_amount ÷ 100) × quantity for USD, annualized by that interval, summed across every line item on the subscription. Do that once per account, join it to your feature board by email or company domain, and vote count stops being the only signal you have.
Why vote count misreads your business
A voting board counts participation, not revenue. BuildBetter's own breakdown of this problem puts it plainly: "vocal customers are rarely your biggest accounts," and the 1-9-90 pattern of who bothers to vote at all means your loudest 1% sets the ranking for everyone else. A free-tier developer testing your API on a Tuesday afternoon can cast a vote with the same weight as an account paying six figures a year, and a board with a thousand free users will always out-vote a board with fifty paying ones.
That's not a flaw in whatever tool hosts the board. Vote count is a headcount, and revenue isn't distributed like headcount, so a ranking built on headcount routinely points product teams at the wrong feature.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionThe join, step by step
1. Pull the request-to-account list. Whatever holds your feature requests, a board, a spreadsheet, a Linear label, export the distinct accounts behind each one. Match by email domain where you can; a request voted on by three people at the same company is one account, not three.
2. Look up each account in Stripe. Stripe's Search API supports an exact match on email (customers/search?query=email:'name@company.com'), or run the same query in the Dashboard's search bar. Expand the result to its active subscriptions.
3. Compute ARR per account. Stripe's unit_amount is in cents for USD (and the equivalent minor unit for other currencies), not dollars, so divide it by 100 before you do anything else with it. For each subscription line item, take (price.unit_amount ÷ 100) × quantity. If recurring.interval is month, multiply by 12; if year, leave it; if week, multiply by 52. Sum across every item on the subscription for accounts with more than one seat type or add-on. Skip that division and every number downstream is off by 100x.
4. Sum ARR per feature, not per vote. A feature with five accounts worth $12,000, $8,500, $6,000, $4,000, and $2,000 in ARR scores $32,500, regardless of whether each account cast one vote or twenty.
5. Rank features by summed ARR, and keep the vote count visible next to it. Vote count still tells you something, breadth of demand isn't nothing, but it stops being the only number on the page.
For a one-off pull, Stripe Sigma runs SQL directly over your Stripe data (subscriptions, customers, invoices) and is included at no extra cost if you're already on Stripe's Data Pipeline, which makes step 2 and 3 a single query instead of a loop of API calls.
Foreman Systems runs the numbers
Foreman Systems sells jobsite management software to general contractors, billed monthly through Stripe across Starter, Pro, and Enterprise plans. Its public feature board had two requests near the top going into a quarterly planning review. Dark mode for the mobile app had 58 votes; custom inspection checklist templates had 22.
By vote count, dark mode wasn't close. Nkechi Beckwith, Foreman's head of product, ran the Stripe join anyway before finalizing the roadmap, because four of the checklist votes had come from the same enterprise account that had been vocal in a renewal call.
The export changed the picture. Dark mode's 58 votes traced to 54 distinct accounts, nearly all on the $49/month Starter plan, summing to about $31,800 in ARR. The checklist request's 22 votes traced to 19 accounts: five were Enterprise accounts averaging $42,000 a year, and the other fourteen averaged $900 a year, for a total just over $222,000. One of those five was Ironclad Grading.
Dara Kessling, VP of Field Ops, Ironclad Grading: "We're on your Enterprise plan and we're still building inspection checklists in a shared spreadsheet. We've asked for this twice now."
Nkechi brought both numbers into the planning review on one slide: dark mode had well over twice the votes, but the checklist request carried five Enterprise accounts worth more than the entire Starter tier combined. Foreman shipped the checklist templates that quarter. Dark mode stayed on the board, now with an ARR number next to its vote count instead of standing alone.
What breaks first as the board grows
The spreadsheet version above is honest and it works, for one planning cycle. It breaks down for reasons that show up predictably as the board grows:
- It's a snapshot, not a feed. The ARR number is accurate the day you pull it and stale the moment an account upgrades, downgrades, or churns. Nobody re-runs the join weekly by hand.
- Matching by email breaks at real companies. A request voted on by someone at
jane@company.comand someone else atprocurement@company.comneeds a human to recognize they're the same account; Stripe's customer record won't do that for you. - The board and the billing system never talk again. The number you wrote down doesn't update when the account's plan changes, so a ranking built on it drifts further from true the longer it sits unrefreshed.
Past a few dozen open requests, that's the point teams stop re-running a spreadsheet join and start looking for something that keeps the two systems connected. That's the category we build in. Modem connects to Stripe once you authorize it from Settings, matches Stripe customers to the people and companies already in Modem, and carries plan and revenue context on every topic those accounts are attached to, refreshed as billing changes rather than typed in once. It doesn't hand you a single "rank by ARR" button either; someone still decides what counts as a request worth summing. What it removes is the re-export. The revenue number sitting on the topic stays current instead of aging the moment you save the spreadsheet. One note on the paragraph above: we sell Modem, so it's a pitch, not a review, and it's worth reading that way. The mechanics of that Stripe connection are covered in more depth in connecting Stripe revenue to customer feedback.
Run it on five requests before your next planning review
Pick your top five requests by vote count. Pull the distinct accounts behind each one. Run the Stripe lookup by hand for just those five, no automation required, just an afternoon and a spreadsheet. The exercise proves itself the first time a five-vote request comes back worth more than a fifty-vote one, and that usually happens inside a single planning review.
