A feature request with 80 votes sounds like a clear directive. Forty upvotes from free-trial users who churned last month and forty from power users on your cheapest plan is a very different signal than eighty votes from customers at $500/month.
Raw vote counts make these two scenarios look identical. Revenue-weighted feedback does not.
This post explains what revenue weighting is, why it produces better prioritization decisions than vote counting alone, and how to implement it without adding friction for users.
The problem with raw vote counts
Vote counts as a prioritization metric have a fundamental structural flaw: they measure who showed up, not who matters to the business.
Survivorship and timing bias. A request submitted on day one accumulates votes for the lifetime of the board. It has more time to be seen and voted on than a request submitted last week. The leaderboard reflects longevity as much as demand. A request from a cohort of users who churned six months ago can still sit at the top of your backlog.
Free users vote more than paying users. Free users, by definition, have less invested in your product. They are more likely to engage with community features like voting boards. They have more time. They are exploring. Paying users (especially on higher plans) are usually busier and often less likely to browse a feature board. Your backlog skews toward free-tier priorities if you measure only vote counts.
One vote is one vote, regardless of ARR. An upvote from a user paying $2,000/month and an upvote from a free trial user count the same in a raw total. From a business perspective, they do not mean the same thing. The $2,000/month user's request, if ignored, represents actual churn risk. The free trial user's request, if ignored, represents a conversion you may not make, a different calculation entirely.
None of this means you should ignore free users or that raw vote counts are useless. They are a useful first-pass signal. But building a product roadmap primarily off of a raw leaderboard is building for whoever is most engaged with your feedback UI, not for your best customers.
What revenue weighting actually means
Revenue weighting means attaching a user's MRR (or another business-relevant metric, like plan tier or account size) to their submissions and votes, then using that information alongside raw counts when prioritizing.
The simplest version: when reviewing the backlog, you can see not just vote count but who voted. If ten of the twenty votes on a request are from customers at your highest plan, that request has a different business case than twenty votes spread evenly across your free tier.
A more sophisticated version: compute a weighted score per request. A vote from a $500/month customer counts more than a vote from a free user. The leaderboard reflects expected revenue impact, not just popularity.
The most honest version (and the one most useful in practice) is to display both. Show the raw vote count (a measure of breadth) and a revenue-weighted score or the total MRR of requesting customers (a measure of retention risk). Both are real signals. Neither is complete alone. A request with 2 votes from $5,000/month customers and one with 200 votes from free users are both worth understanding; they are just telling you different things.
How to implement it: server-side identity tokens
Revenue weighting only works if you know who your users are when they interact with the feedback widget. Anonymous submissions cannot carry MRR. This means you need a way to identify users without asking them to log in inside the widget.
The standard approach is a server-side identity token. Here is how it works:
- When your product page loads for a logged-in user, your server generates a signed JWT that includes the user's ID, email, name, and (critically) their MRR or plan information.
- The JWT is signed with a per-project secret that the feedback tool knows.
- You pass the token to the widget via a
data-identity-tokenattribute on the script tag. - The widget verifies the token, extracts the user's identity, and attaches it to every submission and vote that user makes during the session.
From the user's perspective, nothing happened. They did not log in. They did not see a form. They click the feedback button, submit their request, and it carries their account context automatically.
This is what the server-side identity integration for Reqio is built for. There is no published Reqio SDK; you mint the signed JWT on your server using your language's standard JWT library. The dashboard (Project > Settings > Identity) generates the exact snippet for your project ID and signing secret. A Node.js / Next.js example using the jose library:
// npm install jose
import { SignJWT } from "jose";
const secret = new TextEncoder().encode(process.env.REQIO_SECRET);
const now = Math.floor(Date.now() / 1000);
const token = await new SignJWT({
sub: user.id,
email: user.email,
traits: { plan: user.plan, amount: user.planAmount, interval: user.billingInterval },
})
.setProtectedHeader({ alg: "HS256" })
.setAudience("https://reqio.app/p/YOUR_PROJECT_ID")
.setIssuedAt(now)
.setExpirationTime(now + 300)
.sign(secret);
<!-- Client-side: pass the token to the widget -->
<script
async
src="https://reqio.app/widget.js"
data-project-id="YOUR_PROJECT_ID"
data-identity-token="TOKEN_FROM_SERVER">
</script>
Once this is in place, every vote and submission in your backlog carries the submitter's identity. Your dashboard shows MRR per request alongside vote count.
Using revenue-weighted data in practice
Revenue weighting changes the questions you can ask when reviewing your backlog.
What does this request cost if we ignore it? Sum the MRR of the customers who requested or voted for a feature. That is the revenue at risk if the feature is missing and those customers churn over it. This is not a perfect calculation (customers churn for many reasons), but it is a more grounded prioritization input than "it has 80 votes."
Who are the actual requesters? When a request reaches a meaningful vote threshold, look at who the top voters are. Can you reach out to two or three of them for a five-minute conversation? The vote is a compressed signal; a brief conversation unlocks the real requirement underneath. Revenue context tells you which requests warrant that investment.
Are we building for our best customers or our most vocal users? This is the strategic question. If your top ten feature requests are dominated by users on your free tier, and the requests from your top revenue customers are buried at position 30, that is a prioritization problem, not because free users are wrong, but because the backlog is not telling you about your most important relationships.
Revenue-weighted feedback makes this visible. Without it, you may never notice the pattern.
What revenue weighting does not tell you
A few important limits:
Revenue weighting does not replace user research. Knowing that $X in MRR wants feature Y tells you the feature matters. It does not tell you what "feature Y" actually means, what the right implementation looks like, or whether your current interpretation of the request matches what users actually need. High MRR should trigger a conversation, not skip one.
Revenue weighting can suppress good ideas from free users. New features often get validated by engaged free users before they become a retention driver for paying customers. A product built entirely for current top revenue will struggle to expand its market. The balance (not abandoning one signal for the other) is a judgment call, not a formula.
And revenue weighting is only as accurate as the data you pass. If you pass incorrect MRR, do not pass it for all users, or pass it inconsistently, the weighted scores reflect those gaps. Garbage in, garbage out.
Putting it together
Revenue weighting is not a replacement for a well-designed feedback collection system. It is an enhancement to one. Before weighting makes sense, you need:
- A widget embedded in your product so submissions happen at the moment of experience, not days later via an email survey.
- Category separation so feature requests, bug reports, and general feedback are in separate queues.
- A visible status pipeline so users stay engaged with the system after submitting.
Once those foundations are in place, adding revenue weighting via server-side identity tokens is a one-time integration that meaningfully upgrades the signal quality of your entire backlog. See how to collect customer feedback that's actually actionable for the foundation layer, and how to collect feature requests users actually submit for the widget mechanics.
Reqio supports revenue-weighted feedback natively. Pass your users' MRR via the server-side identity token and your backlog displays weighted scores alongside raw vote counts. Get started free. See pricing.