Feedback Vote

Origin & evolution

Public feature⭐FeatureProduct SpecificationA product capability or featureView reference → voting grew out of support forums and the uservoice-style boards of the late 2000s, where customers could post a request and others could pile on. The appeal was obvious: let demand surface itself, no guesswork required. Tools such as Canny, Frill, and Feature Upvote later formalised the pattern into the standard product-feedback board.

The practice has since absorbed a hard lesson about its own bias. As Canny's own guidance concedes, an unconstrained board skews toward the loudest voice rather than the most valuable one, and a simple count quietly rewards low-effort, high-visibility requests. The widely cited correction is segment and revenue weighting: as one analysis frames it, three enterprise accounts asking for the same thing might carry three votes between them and still be the highest-revenue priority on the board. The vote stays useful as a demand signal once you stop treating every vote as equal.

How it works in practice

A SaaS team has two requests open. A workflow shortcut has 180 votes, mostly from free-tier hobbyists. A SAML integration has 12 votes, all from accounts above £30k ARR. The raw count says build the shortcut. Weighted by plan, the integration is worth roughly £360k in protected revenue against a shortcut that touches no paying segment. The team ships SAML, and the vote did its job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference →: it pointed at real demand, once the count was read through the lens of who cast it.

Feedback vote vs. its neighbours

• Feature request is the thing being voted on, the proposed capability💪CapabilityStrategyAn ability that enables value deliveryView reference →. The vote is a tally of demand attached to it; one request gathers many votes.
• Roadmap item🚩Roadmap ItemProduct SpecificationAn item on the product roadmapView reference → is a committed plan. Votes inform what gets promoted to the roadmap🛣️RoadmapProduct SpecificationA strategic plan of features and milestonesView reference → through feedback_vote_prioritises_roadmap_itemFeedback VoteprioritisesRoadmap Itemcross-domain, but the promotion is a decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → the team makes, not an automatic consequence of crossing a threshold.
• Behavioural segment is the group a voter belongs to. The edge feedback_vote_from_behavioral_segmentFeedback VotefromBehavioral Segmentcross-domain is what makes weighting possible: a vote from a high-retention paying cohort👥CohortGrowthA group of users sharing a common characteristicView reference → can count for more than one from a churned trialist.

In the graph

In the Unified Product Graph, a feedback vote sits in the feedback region and connects three ways: it is cast on a request (feature_request_voted_on_by_feedback_voteFeature Requestvoted on byFeedback Votehierarchy), it informs a plan (feedback_vote_prioritises_roadmap_itemFeedback VoteprioritisesRoadmap Itemcross-domain), and it carries the segment of its source (feedback_vote_from_behavioral_segmentFeedback VotefromBehavioral Segmentcross-domain). That third edge is the structural defence against the loudest-voice trap. Because every vote knows which cohort produced it, the count can be weighted by revenue or retention at query time, so the board reports demand the team can act on rather than a popularity contest.