spirby.Spirby home
all posts
by Dima

the 50-vote rule: when to promote feedback to a roadmap

when is a feature request validated enough to commit to? the heuristic we use, three modifiers it needs, and the cases where you should ignore it.

every team using a public feedback board hits the same question within the first quarter. there's a post with 30 votes. there's another with 18. one's been open three months, the other three weeks. customers keep asking which ones you're going to build. you don't have a good answer.

the bad version of this conversation goes "we're listening to customer feedback" forever. the good version is a rule, written down, that you can point to. the rule we use, and the one we recommend, is fifty votes.

the rule

fifty votes on a post promotes it to the roadmap as "planned." that's the commitment. once it's there, you ship it. you don't unship it because something flashier came along.

below fifty, the post stays open and unstatused. it can collect comments, duplicates can be merged in, the team can read it, but nobody on the customer side gets a promise.

above fifty, three things happen. the status changes to planned. a comment goes on the post explaining the rough timeline (this quarter, next quarter, this year). the post enters the roadmap view.

that's the entire rule. it fits on a sticky note. you don't need a meeting to apply it.

why fifty

the number isn't sacred. fifty is just the smallest round number that's hard to game.

ten votes is too low. a single linkedin post by a customer can move ten votes. you'll end up with a roadmap built by whichever customer has the largest follower count.

a hundred votes is too high for most boards in their first year. you'll wait so long for anything to cross the threshold that the rule does no work. teams that set the bar that high end up with a roadmap built on founder intuition, with the public board as decoration.

fifty is in the right zone for a board with somewhere between 500 and 10,000 monthly active voters. if you have more, push the number up. if you have fewer, push it down. the principle is "a number that takes real momentum to clear, but that you'll see cleared a few times per quarter on a healthy board."

the three modifiers

a flat vote count isn't enough on its own. the rule has three modifiers in practice, and we apply them out loud so customers can see the logic.

velocity. fifty votes in two weeks is a very different signal from fifty votes in two years. the recent one means something just changed (a competitor shipped, a workflow broke, you launched a new pricing tier that exposed a gap). the old one means it's a slow-burning real need that finally accumulated. both are valid reasons to promote. the conversations they trigger are different.

board size. if your board has 200 customers and a post has fifty votes, that's a quarter of your customer base asking for the same thing. promote it immediately. if your board has 50,000 customers and a post has fifty votes, that's a tenth of one percent. promote it cautiously, and look at who voted before committing.

conviction. read the comments. fifty votes with one comment is weaker than fifty votes with twenty comments of "yes, exactly this, here's how it would change my workflow." the comments are where you find out whether the people voting actually want the feature you think they want.

these three modifiers are the difference between a rule and a robot. the rule says "fifty votes triggers a decision." the modifiers say "the decision isn't always yes."

what "promoted" means

a lot of feedback tools treat status changes as cosmetic. the customer sees a label change. nothing actually happens internally. that's the worst version of this. it teaches customers that the labels are theatre.

at spirby, when a post is marked "planned," three things happen automatically. anyone who voted on the post gets an email. the post appears on the public roadmap. the post becomes eligible for the next milestone planning.

when a post is marked "in progress," voters get a second email. when it ships, they get a third, with a link to the changelog entry. (we covered the round-trip discipline in last week's growth-tax post.)

if the only thing that changes when you promote is the label, your rule has no teeth. customers learn this quickly.

the cold-start exception

the fifty-vote rule breaks for the first six months of a new board. you don't have enough volume for it to work, and waiting silently for posts to clear the bar makes the board look dead.

during cold start, the rule we use is different. read every post (see step three of the playbook). pick the three you have the most conviction on. promote them with the standard message: "this is on the roadmap. we don't have many votes yet, but we've heard this from enough conversations that we're going to build it."

be explicit that you're acting on conviction rather than vote count. customers respect that. what they don't respect is being told "we're listening" while nothing on the roadmap changes for a quarter.

the founder veto, used sparingly

you will sometimes want to build a thing that nobody voted for. that's fine. founders see things customers don't. customers see things founders don't. both are real.

the rule is: name it. write a roadmap entry that says "we're building this. nobody asked for it on the board. here's why we think it matters." don't pretend there was demand when there wasn't.

if you do this more than once a quarter, your board isn't doing the work it should. either you've stopped reading it, or you're using it as a smokescreen for an internal roadmap. both are recoverable. pretending the founder veto is "customer demand" is not.

anti-patterns to avoid

four things go wrong with a vote-threshold rule, and they all look reasonable in the moment.

the first is moving the threshold post-hoc. a post hits fifty, you don't want to build it, you say "actually it needs to be a hundred." customers notice. they're paying more attention to your board than you think.

the second is counting votes from the wrong people. a board open to anonymous voting will sometimes get brigaded. a competitor's customers will sometimes vote on your board to push their preferences. the fix isn't to disable anonymous voting (we covered that in the growth-tax playbook). the fix is to look at the vote pattern when something crosses the threshold and apply judgment.

the third is stacking the deck through founder posts. if the founder writes a post that the founder wants to build, and asks the team to vote, that post will cross fifty. it's not a customer signal. it's an internal signal wearing a customer signal's clothes. don't do this.

the fourth is promoting and then quietly demoting. if you promote a post to planned and then realize you can't ship it, write a comment explaining why and move it to won't-do. don't silently revert the status. the silent revert is what destroys trust in roadmaps.

why an explicit rule beats taste

most teams resist writing the rule down. it feels constraining. it feels like you're giving up the right to use judgment.

the opposite is true. an explicit rule frees you to use judgment in the cases that need it. without a rule, every post is a judgment call, and you spend your bandwidth on the easy cases. with a rule, the easy cases handle themselves, and you can spend bandwidth on the modifiers and exceptions.

a public, written rule also forces you to be honest with yourself about what you're actually building and why. that honesty is the entire point of a public board. if you're not willing to be that honest, build privately and skip the board.

if you want a tool that doesn't fight you on any of this, try spirby. the fifty-vote rule isn't built into the product. the discipline behind it is the kind of thing you can run on any tool that has votes, status, and notifications. ours happens to have all three, on every plan.