Revenue weighted voting multiplies each vote on your feature board by a number tied to what the voter pays you. A vote from a $5,000/month account carries more weight than a vote from a free signup. You see both the raw count and the weighted score, so you always know what is popular versus what is valuable.
This guide covers how to set the multipliers, how customers get assigned to tiers through Stripe, what happens when subscriptions change, and how the weighted scores feed into prioritization. If you want the argument for why raw vote counts mislead, start with vote counts are a vanity metric.
How it works
You create voting tiers that match your pricing. Each tier gets a name and a multiplier, an integer between 1 and 100 that you choose based on your product's economics. Something like: Free gets 1x, Starter gets 3x, Pro gets 5x, Enterprise gets 10x.
The multiplier is not automatically derived from MRR. You set it yourself. A $199/month plan does not automatically get a 199x weight. You decide that Enterprise votes should count 10x, or 15x, or 5x, whatever reflects the revenue risk of losing those customers. This is deliberate. Every product's distribution is different, and a hardcoded formula would be wrong for most of them.
When a customer on your Pro tier (5x) votes for a feature, that vote is recorded with a weight of 5. The feature's weighted score goes up by 5 instead of 1. A feature with 4 Enterprise votes (10x each) has a weighted score of 40, which outranks a feature with 30 Free votes (1x each, score of 30), even though it has fewer raw votes.
That's the entire concept. The rest is about how customers get assigned to tiers and how the scores feed into prioritization.
Connecting Stripe
The manual approach, looking up each voter in Stripe and tagging them by hand, works exactly once. Then people upgrade, downgrade, churn, and your tags are wrong within a month.
The automatic approach: you add a restricted Stripe API key (read only, customers and subscriptions). The system pulls your customer list, looks at each customer's active subscriptions, and calculates their MRR. Monthly subscriptions count at face value, annual subscriptions are divided by 12, quarterly by 3. Trialing subscriptions count as $0.
You define MRR ranges that map to tiers. Something like $0 maps to Free, $1 to $1,999 maps to Starter, $2,000 to $4,999 maps to Pro, $5,000+ maps to Enterprise. Ranges are checked in order and the first match wins.
After the initial import, Stripe webhooks keep it current. When a customer upgrades, downgrades, subscribes, or cancels, the system recalculates their MRR and reassigns their tier automatically.
If you are not on Stripe, you can import via CSV. The file needs an email column. Name, MRR, and tier are optional. The system matches voters to their billing profiles by email, so when someone votes on your board, their vote picks up the right multiplier.
What voters without a tier get
Anyone who is not in your Stripe data or CSV import gets a weight of 1. They are not blocked from voting. They just carry the default weight. Anonymous visitors, trial users who never converted, people who signed up with a different email than their billing email, they all vote at 1x.
This is the right default. You want everyone to be able to participate. You just do not want 50 free trial users to drown out 4 enterprise customers who collectively pay you $20,000 a month.
What happens when tiers change
When a vote is cast, the multiplier is recorded on that vote. If a customer was on Pro (5x) when they voted and later upgrades to Enterprise (10x), the old vote keeps its 5x weight. New votes from that customer use the new 10x weight.
The admin dashboard computes live weighted scores from current tier assignments, so it reflects the upgrade immediately across all votes. The public board uses the recorded weights.
If you want both to match, you trigger a recalculation. It walks through every vote, looks up each voter's current tier, and updates the stored weights. After that, both views agree. You might do this quarterly, after a large Stripe import, or after restructuring your tiers.
How weighted votes feed into the roadmap
The weighted vote count plugs into a demand score:
(weighted votes x 3) + (comments x 2) + (views x 0.1)
Votes carry the highest multiplier because they are the most intentional signal. Comments show engagement. Views are passive. When you enable weighted demand scoring, the formula uses weighted vote counts instead of raw counts.
On top of that, there is a priority score: demand score divided by effort. A feature with high demand but massive effort might rank below a quick win with moderate demand from paying customers. This is where the practical roadmap decisions happen.
When this makes sense
Revenue weighted voting works when your product has tiered pricing with a meaningful spread between plans. The wider the gap between what your cheapest and most expensive customers pay, the more signal you get.
It fits B2B SaaS with free and paid tiers, freemium products where free users outnumber paying customers by a wide margin, and any product where a single enterprise account is worth dozens of starter accounts.
It does not fit consumer products where everyone pays the same price, internal tools where all users are employees, or open source projects where the community is the product.
Mistakes to avoid
Multipliers too high on the top tier. If three enterprise customers can outvote your entire user base, the board becomes an enterprise wish list. Keep the multiplier proportional to actual revenue differences.
Never recalculating. Customers upgrade and downgrade constantly. If you import once and never recalculate, your weights drift from reality. A periodic recalculation takes seconds.
Ignoring the raw count. The weighted score tells you what is valuable. The raw count tells you what is popular. You need both. A feature with 200 raw votes and a low weighted score means your free users want it badly. That is useful for conversion strategy, even if it is not the next thing to build.
FAQ
What is revenue weighted voting?
A feature prioritization method where each vote is multiplied by the voter's subscription revenue. A $200/month customer's vote might count 10x while a free user's counts 1x. You see both the raw vote count and the weighted score, so you know what is popular and what is valuable.
Should free users be able to vote?
Yes. They vote at 1x. Their votes still count. They just do not override paying customers. Free users are a conversion pipeline, and knowing what they want is useful. Revenue weighting does not silence them; it puts their input in proportion.
How does Stripe integration work?
You add a restricted Stripe API key. The system imports your customers, calculates MRR from active subscriptions, and assigns each customer to a tier based on MRR ranges you define. After the initial import, Stripe webhooks keep everything current when subscriptions change.
What multiplier should enterprise customers get?
Start with the revenue ratio. If enterprise pays 10x what starter pays, try a 10x multiplier. Adjust based on how the board looks. Multipliers go from 1 to 100.
Try VoteFirst free for 30 days. Revenue weighted voting included on all plans, starting at $4.50/mo.