To turn feedback into a roadmap, collect every request in one list, merge duplicates so votes are honest, weight those votes by who is asking (segment and revenue), score the top items against effort, put the winners on a roadmap with clear statuses, and tell every requester when the work ships. The rest of this guide walks through each step, with a worked scoring example and the flow we use in FeatureOS: board, status, roadmap, changelog.
The six steps at a glance
| Step | What you do | Output |
|---|---|---|
| 1. Collect | Route every channel into one list | One board per product area |
| 2. Clean | Merge duplicates, tag by theme and segment | Honest vote counts |
| 3. Weight | Adjust votes by segment and revenue | A weighted demand score |
| 4. Score | Add reach, impact, confidence and effort | A ranked shortlist |
| 5. Plan | Move the shortlist onto a roadmap with statuses | Planned / In progress / Shipped |
| 6. Close the loop | Notify voters and publish a changelog | Customers who see their feedback land |
Step 1: collect feedback in one place
Feedback arrives in support tickets, sales calls, Slack threads and emails. If it stays there, the loudest channel wins. Pick one home and route everything into it.
In FeatureOS that home is a feedback board. Customers post and vote on the hosted board or through the in-app feedback widget. Support can create posts from Intercom or Zendesk, the team can log requests from Slack, and anyone can email requests in. A consistent feature request template helps every post state the problem, not just the solution.
Step 2: clean the list
Two posts asking for the same thing split the votes and hide real demand. Before you rank anything:
- Merge duplicates. FeatureOS suggests similar posts while a customer types, and when you merge two posts the votes and comments are kept.
- Tag by theme (reporting, integrations, permissions) so you can see clusters, not just single posts.
- Tag by segment (plan, company size, industry) if you plan to weight by segment in the next step.
- Save filters for the views you check every week, such as "Enterprise, open, most voted".
Step 3: weight votes by segment and revenue
A raw vote count treats a free-trial user and your largest customer the same. Most teams want demand weighted by who is asking. Two common weights:
Segment weight. Give each segment a multiplier that reflects your strategy. For example: target segment 3, current paying customers 2, free or trial users 1. Weighted votes = the sum of each voter's multiplier.
Revenue weight. Add up the revenue attached to a request: the plan value of paying voters, or the value of open deals that need it. FeatureOS's Salesforce integration does this for sales-led teams: reps upvote a post from an opportunity, and the opportunity value is attached, so you see the combined revenue at stake per request.
Customers can also give each post a priority rating on the board, which tells you how urgent it is to them, not only that they want it.
A worked example
These numbers are made up to show the method.
| Request | Raw votes | Weighted votes (segment) | Revenue attached | Read |
|---|---|---|---|---|
| CSV export | 40 | 52 (mostly trial users, some paying) | Low | Popular, low value per vote |
| SSO with Okta | 12 | 34 (mostly target segment) | High (3 open deals) | Fewer votes, much more weight |
| Dark mode | 65 | 70 | None | Loud, but no buying signal |
Ranked by raw votes, SSO is last. Weighting nearly triples its score, and it is the only request with deals waiting on it, so it belongs on the shortlist next to dark mode. Neither number decides on its own; the next step adds effort and confidence.
Step 4: score the shortlist
Take the top 10 to 20 weighted requests and score them with a framework the team agrees on. RICE (reach, impact, confidence, effort) works well because your weighted votes feed straight into reach and impact. Value vs effort is a faster alternative. We compare them in RICE vs ICE vs value vs effort, and you can try both in the free feature prioritization calculator or sort with MoSCoW.
FeatureOS roadmaps include R.I.C.E. and value vs effort scoring on the roadmap itself, so the score sits next to the card instead of in a separate spreadsheet.
Step 5: put the winners on a roadmap
A roadmap is the promise you are willing to make. Keep it short and use statuses customers understand.
- Add posts to the roadmap, or live-sync a saved filter so matching requests appear without a second copy.
- Use your own statuses and columns (for example Under review, Planned, In progress, Shipped) and pick the view that fits: Timeline, Kanban or List.
- Decide what is public. A public roadmap builds trust, a private one keeps internal work internal. You can hide boards or card details you are not ready to show. See 12 public roadmap examples for what other teams share.
- Hand off to engineering. Push a post to Jira or Linear as an issue, so the request and the ticket stay linked.
Step 6: close the loop with a changelog
The step most teams skip is the one customers notice. When the work ships, tell the people who asked.
- Status changes notify voters. When a post moves to planned or shipped in FeatureOS, its voters and commenters are notified, and you can pin a note to the post explaining the update.
- Publish a changelog entry and link it to the request. The entry appears on your hosted changelog, in embeds and in the in-app widget, and you can show it to everyone or only to the user segments it affects. More on this in changelog software and how to write a changelog.
The flow in FeatureOS: board, status, roadmap, changelog
Here is one request end to end:
- A customer posts "Export reports as CSV" from the in-app widget. FeatureOS suggests an existing post, so they upvote it instead.
- Support adds two more votes on behalf of customers who asked in Intercom; a sales rep upvotes from a Salesforce opportunity, which attaches the deal value.
- The PM tags the post "reporting" and "finance", and moves it to Under review. Voters are notified.
- The post scores well on RICE, so the PM moves it to Planned and it appears on the public roadmap. The PM pushes it to Linear.
- When the work starts, the card moves to In progress. When it ships, it moves to Shipped.
- The PM publishes a changelog entry linked to the post. Every voter hears that their request shipped, and the entry shows in the widget with a "new" indicator.
Common mistakes
- Ranking by raw votes only. Votes measure how many people asked, not how much it matters to the business.
- Never merging duplicates. Split votes hide your biggest requests.
- A roadmap with dates you cannot keep. Use statuses, or show dates only for work already in progress.
- Shipping silently. If requesters never hear back, they stop giving feedback.
Related: feature request software, closing the feedback loop, product roadmap software, 7 product management frameworks and the art of saying no to feature requests.