How to build a product roadmap from customer feedback
5 min read
How to build a product roadmap comes down to this: collect what customers have already asked for, group it by the problem behind each request, rank the groups with a rule you can explain, decide how sure you are about each, and publish the result in a format that matches who reads it. The order matters. Teams that start with a layout and fill it with ideas get a document that looks finished and carries no evidence. Teams that start with requests get a shorter roadmap with a reason behind every row.
| Step | What you do | What you end up with |
|---|---|---|
| 1. Gather | Pull requests, support themes and usage data into one list | A raw list with a source on every line |
| 2. Group | Merge duplicates, name the problem behind each cluster | Ten to twenty problems with counts |
| 3. Rank | Apply one scoring rule and write it down | An ordered list you can defend |
| 4. Commit | Label each item committed, forecast or exploring | Honest confidence on every row |
| 5. Format | Choose a layout for the reader | A roadmap in Now/Next/Later, themes or a timeline |
| 6. Review | Set a date to look at every row again | A roadmap that stays current |
Where do you start when you build a product roadmap?
Start with the evidence you already hold, not with a blank page. Open feature requests, support conversations tagged with the same complaint, sales call notes and usage data from your own product are all inputs. Put them in one list and write down where each item came from.
Requests rarely arrive in a usable shape. “Add Slack integration” and “notify my team when a task changes” may be the same need. That is why the next step is grouping, and why a tracker that merges duplicates is worth having; duplicate feature requests covers how. Keep in mind that support tickets and feature requests carry different kinds of signal, and a roadmap built from only one of them will lean the wrong way.
How do you turn requests into items on your product roadmap?
Group requests by the problem, name each group as an outcome, and keep the count. A group of fourteen requests that all describe losing a filter after reload becomes one item: “Keep the filter you used last time”. The count goes in the source column, so anyone reading the roadmap can see the weight behind it.
Write the outcome in the customer’s words. “Implement saved view persistence” tells an engineer what to build and tells a customer nothing. The outcome phrasing also forces a useful question: if you cannot say what changes for the customer, you may be looking at an internal task that belongs on a different list.
How do you decide what goes first?
Pick one scoring rule, write it down, and apply it to every item. RICE, which scores reach, impact, confidence and effort, is the most common; Intercom’s write-up of RICE is the original source. A simpler rule works as well if you can explain it: count of requests, weighted by whether the requester is an active paying account, divided by rough effort.
What matters is that the rule is stated, because the first customer who asks why their request is not on the list will want an answer. Where the rule and your judgement disagree, say so in the row. Prioritizing feature requests goes through scoring methods, the revenue-weighting question and what upvotes do and do not tell you.
How sure are you about each item?
Label every item with its confidence before you publish anything. A simple three-value scale is enough: committed means the team would be surprised not to ship it in the window, forecast means it is the plan unless something changes, and exploring means there is no promise.
This single column prevents most roadmap damage. Without it, a customer reads an exploring item as a commitment, sales quotes it, and a quarter later it is a complaint. Marty Cagan’s essay on the alternative to roadmaps makes the underlying argument: a list of features with dates is a list of guesses presented as plans, and the fix is to be explicit about what you know.
Which format should the roadmap take?
Choose the layout last, by reader. Customers asking whether you heard them need a short public view. Leadership asking why this work needs themes or outcomes. A team that changes direction monthly does well with Now, Next and Later and no dates. Product roadmap examples shows six formats with realistic items and how each fails, and the product roadmap template gives the fields to copy once you have chosen.
Most teams end up with two documents: a strategic roadmap for internal readers and a reduced public one showing only what you are willing to be held to. If you publish one, public roadmap describes how to drive it from labels on the issues you already track.
How do you keep the roadmap from going stale?
Give every row a review date and keep the roadmap where the work already is. A roadmap that is updated by hand in a separate tool goes stale because nobody’s daily job includes it. If each column maps to a label on the issue, the roadmap changes when the label does.
Close the loop when an item ships. The people who asked should hear about it, and the changelog entry is the usual place; the customer feedback loop describes the whole path. If you decide not to build something, say so as well. A clear no is useful to the person who asked, and declining feature requests covers the wording.
FAQ
What are the steps for how to build a product roadmap? Gather requests and data, group them by the problem behind each, rank them with a written rule, label each item with how sure you are, choose a format for the reader and set a review date. Starting from evidence keeps the roadmap short and defensible.
What should a product roadmap be based on? On customer requests, support themes, usage data and your strategy, in that order of how often they are skipped. A roadmap with no source behind its rows is a wish list.
How long should a product roadmap cover? Long enough to be useful and short enough to be believable. For many small teams that is the current quarter in detail and the next one or two as themes. Anything further out belongs under “later” with no dates.
Who should be involved in building a product roadmap? The product owner decides, engineering checks feasibility and effort, and support and sales supply the requests and themes they hear. Customers see the result in a public version, but they do not edit it.
The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.