Customer feedback reaches your support team every day, while the product roadmap has limited room. Connecting the two takes a step that turns individual requests into described problems, weighs their impact and checks whether they fit the product's goals. Without it, the loudest customer or the last conversation someone remembers sets the order of work. This guide covers that step: reviewing many requests together rather than assessing a single ticket.
If you are still deciding whether a particular message describes a defect or a new need, start with our guide on bug or feature request. Here we assume you already have those classifications and that dozens of them have piled up.
Group by problem, not by the proposed solution
Customers usually describe whatever solution comes to mind: "add an Excel export", "we need a printable PDF", "connect this to our accounting software". In a fictional scheduling app for dance schools, those three requests may stem from one difficulty: the school owner has to hand the timetable to someone who does not use the app. Counted separately, each looks like a niche wish. Counted together, they reveal a clear problem.
So record the customer's situation and goal first, and only then their suggestion. Asking "what do you want to do with that file?" often tells you more than the name of the format. Keep the suggestion, but do not treat it as a specification. A consistent label vocabulary makes counting easier later; our guide on tagging conversations and tickets shows how to design one.
A group need not be perfect on day one. A few broad problems with a short description are more useful than a hundred labels that each hold one request. If the same difficulty keeps returning as a bug report rather than a feature request, read about recurring customer issues, because there the shared root cause matters more than a product development decision.
The group card: five fields that are enough for a priority discussion
Every group needs a short description that someone who never spoke to the customers can follow. The card below is a suggested process built on a fictional example, not the result of a real rollout.
Scroll the table sideways to see all columns.
| Field | What to record | Fictional example |
|---|---|---|
| Problem | The customer's difficulty in the team's own words | The timetable has to reach someone outside the app |
| Who has it | Type of customer and the situation where it appears | School owners before the term starts |
| Evidence | Linked conversations and tickets, quotes, observations | Requests for Excel, PDF and accounting software |
| Current workaround | What customers do today and what it costs them | Copying the timetable into a spreadsheet by hand |
| Decision | Review outcome, the reason and the next check date | To be assessed at the next review |
The evidence field should link to specific conversations, not just hold a number. A bare count will not show whether ten different customers asked or one customer asked ten times. The workaround field protects you from overrating a problem: if customers can get around it in two minutes, the problem may be real but less urgent than one that stops their work.
Weigh impact, confidence and fit with product goals
When comparing groups, ask three questions. How much does the problem get in the way of the outcome customers use the product for? How sure are you that you understand the problem and how widespread it is? Does a solution fit the direction the team has already chosen for the coming period? A group with strong impact but poor fit does not disappear; it waits with its reason written down.
Intercom describes the RICE method: reach, impact and confidence are multiplied and the result is divided by effort. The author adds that the score is not a hard rule and a lower-scoring project may rightly come first: Intercom: RICE.
Lower your confidence when a group rests only on statements like "we would buy it if you added this". Customer behaviour, such as a repeated manual workaround or an abandoned process, is a stronger signal than a promise. Account size or a forceful tone is business context worth noting, but it should not replace the problem description. The same rule applies to website fixes: our guide to ICE scoring for UX fixes shows how to rate confidence by evidence from recordings and heatmaps.
Jakob Nielsen of Nielsen Norman Group (2001) advises watching what users do, because what they say, including claims about whether they would use a feature, is a poor predictor of actual behaviour. The article is about usability research and does not offer a method for building a roadmap: NN/g: the first rule of usability.
A regular review: the order of work
Groups should not be reassessed every time a new message arrives. Set a steady rhythm, for example once per planning cycle, and prepare the material before the meeting.
- Sort new requests.Someone from support assigns new tickets to existing groups or opens a new group with a short problem description.
- Update the cards.Add new evidence to each group and check whether the current workaround still works the same way.
- Compare the groups.The product team assesses impact, confidence and fit with goals, then picks a few groups for further work.
- Record the decision and reason.Every group discussed gets an outcome: planned, needs discovery, deferred or declined, with one sentence explaining why.
- Brief the support team.Support knows what to tell customers and when the group will come back for review.
A roadmap priority is not the same as a support queue priority. A customer may need a quick answer to a request that reaches the plan only months later, or never. Our guide on ticket queue priorities covers the order of day-to-day contacts; here you are ranking changes to the product.
What to tell the customer before a decision is made
Customers should know their request was understood and recorded, but they should not hear a promise nobody has approved. Saying "I'll pass it on, it will definitely be added" creates a commitment without an owner. Describe the stage instead, plus what the customer can do today.
"Thank you for the details. I understand you need a way to share the timetable with your accountant without retyping it. We have added this need to similar requests that the product team discusses at its regular review. I cannot promise today whether or when such a solution will be available. In the meantime, [the workaround you checked in their account]. Once a decision is made, I will get back to you."
When the request concerns an ongoing project delivered for a client rather than product development, a different approach applies. What matters then is the agreed scope and a recorded decision, as described in our guide for when a client changes the project scope. After the review, contact the customers linked to the group, even if the answer is "not in this period". Ready-to-send “we won't change this” and “not yet, we will check back on a set date” messages are in the guide on how to close the customer feedback loop.
Keeping a trail of decisions with tags and Meetlead Projects
In Meetlead you can tag conversations and filter the inbox by several tags at once, which makes it easier to gather evidence for one group. In the Projects app you can link a task to a ticket, a recording and other tasks, place it in the backlog, assign it to an epic, set its priority and record decisions in comments. An epic can stand for one problem group.
The team creates these links manually: Meetlead does not group requests automatically, calculate a priority score or publish a roadmap to customers. Projects requires an account, an active app on the site and access in your plan. When a group moves into delivery, follow our guide from support ticket to task so that the task has an outcome, an owner and a completion criterion.
- The group describes a problem, not just a feature name.
- The evidence points to specific conversations or tickets.
- The current workaround and its cost to customers are noted.
- The review decision has a reason and a date for the next check.
- Support knows what to tell customers in this group.
Questions about customer requests and the product plan
Is the number of requests enough to put a feature on the roadmap? No. The count shows reach, but it says nothing about impact, confidence or fit with your goals. A few requests from customers whose core work is blocked can outweigh many requests for a minor convenience. Record the count alongside the evidence and the workaround.
Can you tell a customer "no"? Yes, once a decision has been made and you know the reason. Briefly explain what the team is focusing on in the coming period and point to an available workaround if there is one. An honest "not now" with the date of the next review beats a generic "thanks for the suggestion" that leads the customer to ask again a month later.
