Most product teams prioritize features by vote count. 50 votes beats 10 votes. Simple. Democratic. And often completely wrong.
The problem: free users vote. Churned users vote. Lurkers who signed up for a free trial in 2024 and never paid a dollar vote. Meanwhile, your three biggest enterprise customers — each paying $299/month — each cast one vote and get drowned out by a crowd that generates zero revenue.
Voter MRR fixes this. It's a signal that shows how much monthly recurring revenue is attached to each feature request — not just how many users asked for it.
How Voter MRR works
The concept is simple: each user who votes on a feature request has an MRR value attached to their account. When you look at a feature request, you see two numbers:
- Vote count — how many users want this
- Voter MRR — how much MRR those users represent
In ShipPulse, you assign an MRR value to each voter manually (or via API if you're syncing from your billing system). ShipPulse then surfaces both numbers on every feedback post, so you can see at a glance whether a feature is popular among high-value customers or just popular among free users.
A real example
You have two feature requests:
47 users want this. But most are on the free plan — total MRR attached is $180.
Only 8 users asked for this — but they're all on Agency plans. That's $2,400/mo at stake.
By vote count, CSV export wins. By Voter MRR, SSO is not even close.
Neither signal is the whole picture — there's real value in serving your free users and growing the base. But Voter MRR makes the trade-off explicit. You're choosing between serving 47 free users or retaining $2,400 MRR worth of enterprise customers. That's a decision you should make deliberately.
How to set it up in ShipPulse
In your ShipPulse feedback board, each voter's profile has an MRR field. You can set it:
- Manually — update voter MRR values from the dashboard. Good for small teams who know their customer list well.
- Via API — send voter MRR values programmatically from your billing system. If you use Stripe or LemonSqueezy, you can sync subscription values on plan changes.
- Via SDK — identify users with their MRR value when they interact with your feedback widget:
ShipPulse.identify({ email: '[email protected]', mrr: 299 });
When Voter MRR changes your prioritization
Voter MRR is most valuable when your free-to-paid conversion is ongoing and your free user base is significantly larger than your paid base. In that situation, raw vote counts almost always reflect what free users want — not what drives revenue.
It's also valuable when you have a wide pricing spread — $19/mo plans and $99/mo plans. A feature that retains Agency customers is worth more than a feature that retains Starter customers, and vote count can't capture that.
The right way to use both signals
Don't optimize exclusively for Voter MRR — that leads to building only for enterprise customers and ignoring the growth engine of your free tier. The right frame is:
- High vote count + High Voter MRR → build this now, no debate
- High vote count + Low Voter MRR → build it if it fits your growth thesis
- Low vote count + High Voter MRR → strong retention play, worth doing
- Low vote count + Low Voter MRR → defer or decline
The goal isn't to replace judgment with a number. It's to give you the right numbers so your judgment is actually informed.