Most roadmap arguments are not really about ideas. They are about evidence.
Someone says customers keep asking for a feature. Someone else says it will help revenue. Engineering says it is harder than it looks. Sales mentions that a competitor already has it. Without a shared way to judge those claims, the loudest request or the latest conversation tends to win.
A feature request evidence checklist fixes that. Before a request is allowed to influence the roadmap, the team grades the proof behind it: who asked, how often, why it matters, how sure you are, and what it will really cost. This guide walks through the checklist we recommend, a simple scoring sheet, and a worked example.
Quick Answer
A feature request evidence checklist asks nine questions before a request reaches planning: Is the requester in your target segment? How many separate accounts raised the same problem? Do the votes come from real, active customers? Is the underlying problem clear? Do support, sales or cancellation notes back it up? How large is the impact on retention or revenue? How confident is the team, and why? Is the effort estimate honest? And what can you safely say about it in public? Score each from 0 to 3 and use the total to decide whether a request goes to planning, discovery or the archive.
Why Vote Counts Are Not Enough
Votes are a useful demand signal, but they only show demand from people who found your board and bothered to click. They say nothing about cost, strategic fit, or what customers who never visit the board need.
Prioritisation frameworks exist for exactly this gap. Atlassian describes prioritisation frameworks as a way to make better informed decisions when a team cannot build everything, and its Jira Product Discovery handbook explains RICE, which weighs reach, impact and confidence against effort. Aha! takes a similar line in its product value score guidance: score the value of a piece of work, but factor in how confident you are before acting on it.
The common thread is that a number is only as good as the evidence underneath it. The checklist below is a lightweight way to collect that evidence for each request, without turning planning into a spreadsheet exercise.
The Nine-Point Evidence Checklist
1. Who asked?
Record the account behind each request: plan, company size, industry, the requester's role, and whether they are an active customer, a trial user, a prospect, a churned customer or someone on your own team. Then ask the most important question: are they in your target customer profile?
Five requests from ideal customers usually matter more than twenty from people outside the market you serve. A request from a large account deserves a serious look, but it should not quietly take over the roadmap either.
2. How many separate accounts raised the same problem?
Customers describe the same need in different words. "Custom statuses", "rename the columns", "more workflow stages" and "match our process" may all be one theme. Before scoring, combine these into a single canonical request and count unique accounts, not cards. Otherwise real demand is split across five small items and looks weaker than it is.
Our feature request management process covers the weekly triage routine that keeps duplicates from piling up.
3. Are the votes good votes?
Look past the total. How many unique accounts voted? Are the voters active? Did the votes arrive over months or in one burst after a newsletter? Did anyone explain their use case in a comment? One vote per signed-in user keeps the count honest, but even honest votes can come from outside your core segment.
A useful habit is to note the vote pattern in one line, for example: "31 votes, 18 accounts, 12 of them on paid plans, mostly agencies."
4. Is the problem clear?
Many requests are solutions in disguise. "Add CSV export" might really mean finance needs a monthly report, an admin needs a backup, or users are copying data into spreadsheets because a view is missing. Each of those problems may have a different, cheaper fix.
Ask what the customer is trying to get done, what breaks without the feature, what workaround they use today, and how often it happens. If nobody can answer, the request belongs in discovery, not in planned. A good feature request template collects most of this up front, so you are not chasing it later.
5. Does anything outside the board back it up?
Strong evidence often lives outside the roadmap tool: support tickets, cancellation reasons, lost-deal notes, onboarding friction, demo objections, and usage drop-off. One ticket proves little. The same problem showing up in support, sales calls and churn interviews turns a request from interesting into a genuine candidate.
Link or summarise those sources on the request so the planning meeting starts from facts rather than memory.
6. How big is the impact?
Impact is not the same as how strongly someone feels. Estimate how many target users are affected, how painful the problem is, and how close it sits to retention, expansion or new revenue. Note whether it supports the product direction you have already chosen.
For a small SaaS team, four plain questions are usually enough: how many of our target users does this help, how much does it hurt today, how directly does it affect retention or revenue, and does it fit where we are taking the product?
7. How confident are you, and why?
Confidence is what stops wishful scoring. Use four labels and always write the reason next to them:
"Seems useful" and "everyone wants this" are not confidence notes. If you cannot write a specific reason, the confidence is low.
8. Is the effort estimate honest?
Requests look small when only the visible screen is considered. Real effort often sits in data model changes, permissions, notifications, billing, API behaviour, testing, documentation and support training. Add ongoing maintenance and any future features that would depend on this one.
If effort is unknown, say so. A precise-looking score built on a guessed estimate is worse than an honest "needs sizing".
9. What can you safely say in public?
Every reviewed request needs a decision, and the public wording should match it exactly. "Under review" means you are still assessing. "Planned" means you intend to build it. "In progress" means work has started. "Completed" should point to a changelog entry. If the answer is no for now, say that clearly; our guide on how to say no to feature requests has wording that keeps customers on side.
ProductPlan makes a related point about treating the roadmap as a single source of truth: it should carry current priorities and plans. If a decision has not been made, the public board should not imply that it has.
A Simple Evidence Score
Score each of the nine points from 0 (no evidence) to 3 (strong evidence), for a maximum of 27:
Treat the score as a conversation starter, not an automatic verdict. Its real value is that two people looking at the same request can now see exactly where they disagree. If you already rank work with an impact-versus-effort grid, the feature prioritization matrix pairs well with this score: the checklist tells you how much to trust each input before it goes on the grid.
A Worked Example
Imagine a small invoicing SaaS reviewing a request titled "Bulk export to CSV".
Total: 23. The team brings it to planning, updates the public status, and writes the changelog entry when it ships.
Compare that with "Dark mode for reports": nine votes, mostly from free users, no support tickets, unclear benefit. It scores 9, stays visible as Under review, and the team asks voters to describe when they would use it.
Close the Loop After Every Decision
Customers do not just want to vote; they want to know what happened. When a request changes status, tell the people who asked. When evidence is thin, ask them for detail. When something ships, publish a changelog entry and link it to the original request. Our post on closing the feedback loop on feature requests has message templates for each stage.
Where Roadmapr Fits
Roadmapr gives you the visible parts of this process: a public roadmap with Under review, Planned, In progress and Completed stages, feature requests from your users, one vote per signed-in user, a changelog for shipped work, and analytics that show which requests are gathering votes over time. The evidence grading itself stays with your team, and that is the point: the board shows demand, and the checklist explains why you acted on it.
Final Checklist
Before a feature request moves to planned, confirm that:
FAQ
What is feature request evidence quality?
It is the strength of the proof behind a request: who asked, how many separate accounts raised it, which segment it affects, what business impact it has, and how confident the team is about the problem and the effort.
Should vote count decide the roadmap?
No. Votes are one signal. Review who voted, whether they match your target customers, what support and sales evidence exists, the strategic fit, the effort, and your confidence before deciding.
How often should we review feature request evidence?
Before each planning cycle, before moving any item to Planned, after a large wave of feedback, and whenever an old request suddenly picks up new votes or support pressure.
Does a low score mean we should delete the request?
Not necessarily. A low score usually means the evidence is missing, not that the idea is bad. Keep it visible, ask voters for their use case, and rescore it when new information arrives.
Sources
Ready to build your public roadmap?
Roadmapr gives you a public roadmap, feature voting, and a changelog in one place. Start on the Free plan and upgrade when your team grows.
Get Started Free