Most product roadmaps are built by a product manager who consults a few stakeholders and then announces the priority list. This process has a name: HiPPO (Highest Paid Person's Opinion). It produces roadmaps that reflect one person's priorities, miss genuine engineering complexity concerns, ignore design team insights, and create low ownership across the team. Structured team voting in feature prioritisation fixes this. Not by replacing product judgment — but by ensuring that engineering, design, customer success, and product all have an equal, anonymous voice in the process. This guide covers the five most useful frameworks and exactly how to run them.
The HiPPO problem in feature prioritisation
The HiPPO effect describes a common failure mode: when a senior person (the Highest Paid Person in the room) expresses a preference early, everyone else converges around it. In feature prioritisation sessions, this means the PM or CEO's priority list wins by default — not because it's the best list, but because nobody wants to contradict the senior voice. The engineering team knows Feature X is technically fragile and will cause problems. The design team knows Feature Y has a better user impact. But neither raises this in the meeting. Anonymous voting solves this. When engineers and designers vote privately on a backlog before the priority discussion, genuine signals emerge that wouldn't surface in a public meeting.
Framework 1: Dot voting for backlog prioritisation
Dot voting is the fastest method for narrowing a long backlog to a shortlist. Each participant gets a fixed number of votes (typically one-third of the total number of items) and allocates them across features. They can concentrate all their votes on one feature or spread them. The items with the most votes become sprint candidates. For a 15-item backlog, each person gets 5 votes. Run the vote anonymously before the sprint planning meeting. The results tell you where genuine cross-functional agreement exists and where it doesn't — and the planning meeting focuses discussion on the gaps.
Prepare the candidate backlog 48 hours before planning
List every candidate feature with a clear title and 1-2 sentence description. Context matters — vague items get vague votes. Share the list with all voters before the vote opens.
Create an anonymous dot vote with all items as options
In Chooseday, create a decision with dot voting mode and anonymous mode enabled. Set a deadline 24 hours before the planning meeting. Give each participant one-third of the total items as votes.
Let the vote run privately
Don't share partial results. Let everyone vote without knowing how others have voted. This is especially important if the PM or lead has strong preferences.
Review results at the start of planning
Open the planning session with the dot vote results. Items with strong cross-functional support go into the sprint. Items with low votes get deprioritised or discussed. Items where the vote is divided (high variance) need discussion.
Framework 2: Ranked choice voting for shortlist selection
Once dot voting has narrowed the backlog to a shortlist (typically 4-8 features), ranked choice voting finds the option with the broadest genuine support. Unlike dot voting (which produces a priority list), ranked choice produces a single winner — useful when you need to select one big feature to focus the sprint around. Participants rank the shortlisted features in order of preference. The instant-runoff algorithm eliminates the least popular options and redistributes votes until one feature has majority support. The winner is the feature that the most people can genuinely get behind — not just the one a few people were most passionate about.
Framework 3: RICE scoring and weighted matrices
RICE scoring is a systematic framework for comparing features on four dimensions: Reach (how many users in a given time period), Impact (how much it improves outcomes for each user, typically 0.25–3x), Confidence (how sure you are of your estimates, 50-100%), and Effort (person-months). RICE Score = (Reach × Impact × Confidence) / Effort. A higher score indicates a higher priority feature. RICE is useful for systematic comparison but has limitations: it requires reliable estimates, it can favour large features over high-quality small improvements, and it doesn't capture strategic considerations. Most teams use RICE to create an initial ranked list and then use team voting to make the final call — combining systematic scoring with human judgment.
Framework 4: Cross-functional prioritisation
Features affect different functions differently. Engineering cares about complexity and technical debt. Design cares about user experience impact. Customer success cares about the most requested features. Sales cares about deal-blocking features. Product cares about strategic alignment. Cross-functional prioritisation runs separate anonymous votes by function and then compares the results. Features that appear in the top 3 of every function's vote are clear priorities. Features that only one function rates highly are worth a specific discussion about whether that function's perspective is being given appropriate weight. This process surfaces genuine cross-functional priorities and prevents any one function from dominating the roadmap unilaterally.
How to run feature prioritisation sessions that actually work
Prepare the candidate list with full context
Every candidate feature needs: a clear name, a 1-3 sentence description of the user problem it solves, and any relevant data (request frequency, potential impact). Votes are only as good as the context provided.
Run the vote 24-48 hours before the planning meeting
Async voting produces better results than live voting. People vote when they're fresh, can consult notes or data, and don't feel social pressure from others in the room.
Make anonymous mode mandatory
The HiPPO effect is real and powerful. Anonymous voting is not optional — it's the mechanism that makes cross-functional input genuinely diverse.
Use the meeting to discuss the vote results, not to hold the vote
Walk into the meeting with results. Discuss surprises — items that ranked much higher or lower than expected. Focus discussion time on genuine disagreements, not on stating positions the vote already captured.
Document the outcome and rationale
Record which features were prioritised and the key reasons. This context is valuable when the priorities are questioned six weeks later — and they will be.
Frequently asked questions
It depends on the decision type. For narrowing a long backlog: dot voting. For selecting between a shortlist: ranked choice. For systematic scoring: RICE. Most teams combine scoring to create a shortlist, then team voting to finalise.
Anonymous team voting distributes the decision across engineering, design, and product. It prevents the HiPPO effect and surfaces genuine engineering concerns and design insights that wouldn't come out in public discussions.
RICE stands for Reach, Impact, Confidence, Effort. Features are scored on each dimension and ranked by RICE score. Useful for systematic comparison but best combined with team voting for the final decision.
Anonymous voting is the most effective way. In public discussions, engineers often defer to PMs. Anonymous dot voting on the backlog surfaces genuine engineering priorities — including concerns about complexity that are rarely raised publicly.
Most teams benefit from a prioritisation vote at the start of each sprint (near-term backlog) and quarterly for the longer-term roadmap.
Yes — async prioritisation often produces better results. Team members can review specs carefully, consult data, and give considered input without time pressure. Run the vote 24-48 hours before the planning meeting.