# How to handle the vocal minority in customer feedback > Handle the vocal minority by checking who is asking, how many distinct customers agree, and what quiet usage shows. Weigh loud requests against the behavior of the wider base, answer the loudest customers directly, and keep the roadmap driven by patterns rather than volume. Source: https://escutaproduto.com/resources/vocal-minority-feedback Last updated: 2026-10-11 ## Why are the loudest customers rarely the most common? Feedback is self-selected. The people who write in are the ones who feel strongly enough to take a few minutes, and that group is rarely a fair sample of your customers. Most customers never write at all. They use the product, get on with their work, and leave when something is missing for them, often without a word. That does not make loud customers wrong. A frustrated power user can see a real gap that everyone else will hit later. The problem is treating volume from a few people as a measure of demand across the whole base. A roadmap built that way tends to serve the most vocal customers, not the most valuable ones. ## How do you check who is asking? Before you weigh a request, find out who made it. Four questions cover most cases: 1. **How many distinct customers?** Count people, not messages. Three messages from one account count once. 2. **Who are they?** Check the plan, role or segment, if you store it in metadata. A request from your largest segment means something different from one from a small, inactive account. 3. **How long have they been customers?** Long-time users may describe a real gap, or they may be attached to an old way of working. Both are worth knowing. 4. **Do they represent the segment you want to grow?** A request that only fits one unusual setup should not steer the product for everyone. The [paying vs free user feedback guide](/resources/paying-vs-free-user-feedback) covers how to weigh segments in more depth. ## How do you weigh loud requests against quiet usage? Quiet usage is the evidence most teams ignore. Check what the wider base does before you decide what a loud request is worth. Analytics show whether people reach the feature at all, how often they use the related flow, and whether they drop off before or after it. A simple way to set the two side by side: - If the loud request concerns a feature almost nobody uses, the request may describe a problem you have not solved for the people who do use it. Find out before you add more to it. - If the loud request concerns a flow that thousands of people use daily, and the usage data shows drop-off in that flow, the request deserves attention even from a few people. - If usage is healthy and the request is for something new, treat it as an option to test with a small group, not a roadmap commitment. The [feedback vs product analytics guide](/resources/feedback-vs-product-analytics) explains how to put these two sources together. ## What does a squeaky-wheel roadmap look like? A squeaky-wheel roadmap is one that moves whenever the loudest customer complains. You can spot one by its pattern: the features on the roadmap match the names of the most active accounts, not the problems most customers share. Releases feel reactive, and the team spends time answering the same few people instead of improving the core. The fix is not to ignore loud customers. It is to decide in advance how a request earns a place, and to write that rule down. A written rule protects the team when a large account pushes hard for something narrow. ## A worked example: one loud request, many quiet users For example, suppose 4 customers ask for a custom report layout over one month. All four are on the largest plan, and they message the team directly as well as through the inbox. In the same month, 60 other customers use the existing export, and 11 of them report that the column order is hard to read in their spreadsheet. Here the loud request is for a custom layout, but the quiet pattern is about readability in a flow many customers already use. The better first step is a small change to the default export order, tested with the eleven people who raised it. The four loud customers get a direct reply that explains the choice and invites them to test the change. The custom layout waits until it appears again from customers outside that one account. ## How do you answer a loud customer without caving? Reply within your normal window, and acknowledge the problem in their words. Then explain what you are doing: testing a change, collecting more examples, or deciding against the request for now. Avoid promising a date you cannot keep. The [guide to saying no to feature requests](/resources/say-no-to-feature-requests) has wording for the cases where the answer is no. Keep the reply factual. Loud customers often respond well to a clear reason and a named next step, more than to a fast yes. ## Keeping the quiet majority in the room Schedule a regular check on the quiet side of the data, not only the inbox. Each week, look at a few numbers: how many distinct customers asked for each request, how usage is moving in the flows people complain about, and which bugs are rising. Put those numbers in the review before the loudest message gets read, so the room starts from the base rather than the most recent email. The [weekly feedback review template](/resources/weekly-feedback-review-template) includes a place for this. ## Reading the quiet side with Escuta Produto Escuta Produto keeps every item in one inbox, so loud and quiet requests land in the same list instead of in separate email threads. Filter by type to focus on requests, then count distinct customers from the email field and your notes. Escuta Produto has no public voting board, so a vote count is not a signal here. Count the people who wrote in, and ask the rest through your own product analytics or a short follow-up. Set status and notes as you go, so the decision about the loudest request is written next to the quiet evidence. The [widget docs](/docs/widget) show how feedback arrives with the page the customer was on, which helps you match a complaint to the flow where usage is falling. ## Frequently asked questions ### What is the vocal minority in customer feedback? It is the small group of customers who write in most often and most strongly. Their feedback is real, but they rarely represent the whole customer base, which is why their volume should not decide the roadmap alone. ### How do you weigh a loud request against quiet usage? Check how many distinct customers ask, who they are, and what usage data shows for the related flow. A loud request on a rarely used feature may point to a deeper problem, while a request on a heavily used flow with drop-off deserves attention even from a few people. ### What is a squeaky-wheel roadmap? A roadmap that changes whenever the loudest customer complains. It serves the most active accounts instead of shared problems, and it leaves the team reacting to requests rather than improving the core product. ### How should you respond to a loud customer who wants a feature you will not build? Acknowledge the problem in their own words, explain the reason for your decision or the test you are running, and avoid promising a date you cannot keep. A clear, factual reply usually lands better than a fast yes.