When Everyone Agrees

There is a particular moment in product management when a customer request begins to feel like a fact. It usually starts innocently enough. A customer asks for a feature during a quarterly business review, and the account team passes the request along to Product. A week later, another customer mentions something similar. Sales says they have heard it from several prospects, Customer Success confirms that it comes up regularly, and before long someone adds that a competitor already offers it. By the time the request reaches a roadmap discussion, the conversation is no longer about whether the organization should solve the problem. Everyone already seems to agree that it should. The only remaining question is when.

We have seen some version of this happen in nearly every product organization we have worked with. In many ways, it represents exactly what companies say they want. Teams are listening to customers, information is flowing across departments, and product decisions appear to be grounded in market evidence rather than internal opinion. When several independent sources point toward the same conclusion, acting on that conclusion feels not only reasonable but responsible.

Sometimes it is. Customers frequently identify real gaps in products, and repeated feedback can reveal opportunities that deserve investment. The danger begins when repetition is mistaken for understanding. Five customers asking for the same feature does not necessarily mean five customers have the same problem, and fifty requests in a feedback system do not automatically make something strategically important. What appears to be overwhelming agreement can sometimes be the product organization’s first indication that it needs to become more curious, not less.

When Feedback Becomes a Vote

Most organizations eventually develop some mechanism for collecting customer feedback. Requests arrive through sales conversations, support tickets, advisory boards, customer interviews, surveys, product analytics, and countless conversations between employees and customers. As the volume grows, teams understandably look for ways to organize it. Requests are categorized, tagged, counted, and sometimes assigned scores intended to help Product determine what matters most.

There is nothing inherently wrong with doing this. Patterns matter, and a product organization that repeatedly hears the same concern should pay attention. The problem emerges when the organization begins treating frequency as a proxy for importance. Once that happens, customer discovery quietly turns into voting. Ten requests appear stronger than five, twenty appear stronger than ten, and the roadmap gradually becomes an aggregation of the most frequently expressed desires.

The apparent objectivity is comforting. Nobody has to defend a difficult judgment because the numbers seem to have made the decision. Sales can point to opportunities in the pipeline, Customer Success can point to renewal conversations, and Product can point to the volume of requests. Everyone has evidence supporting the same conclusion, which makes challenging it surprisingly difficult.

Yet the number of times a request appears tells us very little about why it exists.

Imagine that twenty customers ask for the ability to export a particular set of data into a spreadsheet. The obvious conclusion is that the product needs a better export capability. Perhaps it does. But those twenty requests could represent several entirely different problems. Some customers may need to perform analysis the application cannot support. Others may need to send information to executives who never log into the product. A few may be feeding another system through a manual process because an integration is missing. Others may simply prefer spreadsheets because that is how they have always worked.

The requested feature is identical. The underlying problems are not.

If we build the export exactly as requested, we may satisfy all twenty customers temporarily while solving none of their actual problems particularly well. Worse, we may conclude that the demand validated our decision because usage of the new export feature is high. Customers asked for it, we delivered it, and they use it. From the perspective of traditional product metrics, the story looks like a success.

The more interesting question is why they still need the spreadsheet.

Customers Are Usually Better at Pain Than Prescription

There is an old product management idea that customers are excellent at describing their problems but less reliable at designing the solution. Like most product aphorisms, it becomes less useful when treated as an absolute rule. Customers frequently have excellent ideas, particularly sophisticated users who understand their workflows deeply. Ignoring their proposed solutions simply because they came from customers would be every bit as foolish as implementing them without investigation.

The distinction we find more useful is between pain and prescription. When a customer describes where a workflow breaks down, what takes too long, where information disappears, or what prevents them from accomplishing something important, they are providing direct evidence about their experience. When they tell us exactly what feature should be built to fix it, they have moved from describing the problem into designing the product.

That design is inevitably shaped by what they already know. Customers imagine solutions based on the product they currently use, the competitors they have seen, and the workflows they have developed around existing limitations. They rarely have visibility into the broader customer base, the product architecture, future strategy, or alternative approaches the product team might explore. None of this makes their recommendation wrong. It simply means the recommendation should be treated as one possible solution rather than the requirement itself.

This becomes especially important when many customers converge on the same prescription. Consensus creates confidence, and confidence tends to shorten discovery. Instead of asking why customers need something, teams begin discussing implementation. The organization moves quickly from “we keep hearing this” to “we know what customers want,” often without noticing that an important step disappeared between those statements.

Not Every Customer Has the Same Microphone

There is another problem with counting feedback that has little to do with the feedback itself. The customers represented in our systems are not a random sample of the market.

Large customers usually have louder voices than small ones. They have account executives, customer success managers, executive sponsors, quarterly business reviews, and renewal conversations. Their requests travel through the organization quickly because significant revenue may be attached to them. When a strategic customer needs something, several people may independently communicate the same request to Product, creating the impression of multiple signals when all of them originated from a single account.

Prospects can create a similar distortion. A feature associated with an active sales opportunity naturally attracts attention because the economic value is immediate and visible. If three large prospects ask for the same capability during a quarter, that request can quickly begin to feel like a market requirement. What is harder to see are the hundreds of prospects who never reached a conversation with Sales, the buyers who quietly selected another product, or the customers for whom that capability has no relevance whatsoever.

Customer Success introduces another perfectly understandable bias. Their teams spend much of their time helping customers who are struggling with something. The customers who are happily accomplishing their goals rarely schedule meetings to explain how little assistance they need. As a result, the feedback moving through an organization naturally overrepresents friction.

None of these groups should be ignored. Strategic customers matter. Sales feedback matters. Customer Success may understand the daily realities of customers better than almost anyone else in the company. The mistake is assuming that the volume of their feedback represents the volume of the market.

Sometimes the customers we hear from least are the ones we most need to understand.

The Missing Customers

Product teams naturally spend most of their discovery time with existing customers because existing customers are easy to find. We know who they are, have their contact information, understand which products they use, and usually have employees responsible for maintaining those relationships. When we need feedback, they are the obvious people to ask.

This creates an enormous blind spot.

The customer who renewed can tell us why they stayed, but the customer who left may understand our weaknesses better. The prospect who purchased can explain what convinced them, while the prospect who chose a competitor can tell us where our value proposition failed. The active user can describe frustrations within the current workflow, but the person who abandoned the product after three weeks may reveal a problem that long-term users have simply learned to tolerate.

There is also an even less visible group: people who should be customers but never seriously considered the product at all. They do not submit feature requests because they have no relationship with the company. They do not participate in advisory boards or complete customer surveys. They are absent from the feedback database, which makes it remarkably easy to forget that they exist.

This is one reason an organization can become exceptionally responsive to customers while gradually becoming less responsive to the market. Existing customers naturally ask companies to make the product better for people like them. If the organization consistently follows those requests, the product can become extraordinarily well optimized for the customers it already has while becoming increasingly difficult to sell to anyone else.

The feedback system will not warn us when this is happening. In fact, it may tell us we are doing an excellent job.

Agreement Should Make Us More Curious

None of this means product teams should distrust customer feedback. We believe exactly the opposite. Customer feedback is among the most valuable evidence an organization possesses, but evidence becomes useful only when interpreted in context.

When several customers independently describe the same pain, that is a strong signal worth investigating. When they independently request the same solution, that is interesting as well. The mistake is treating either signal as the end of discovery rather than the beginning of it.

The most useful response to repeated feedback is often to go one level deeper. We want to understand what customers are trying to accomplish when the problem occurs, what they do today instead, how frequently it happens, what the consequences are, and why the existing alternatives are insufficient. We want to know whether customers who never requested the feature experience the same problem differently. We want to understand whether lost customers or prospects encountered the same friction and reached a completely different conclusion about what they needed.

That investigation may ultimately lead directly back to the feature customers originally requested. There is nothing wrong with that outcome. The difference is that the organization now understands why it is building the feature and what outcome it should create. That understanding becomes particularly valuable when tradeoffs emerge during development because the team can evaluate alternatives against the underlying customer problem rather than against a list of requested functionality.

Sometimes the investigation leads somewhere entirely different. A request for better reporting turns out to be a problem with visibility. A request for additional configuration reveals that customers are compensating for an overly complicated workflow. A request for an integration exposes a broader problem with how information moves through the organization. The original request was not wrong. It was simply the customer’s best description of a solution based on the product they knew.

Feedback Is Evidence, Not Instruction

We believe one of the most important responsibilities of product leadership is maintaining the distinction between listening to customers and taking instructions from them. The first requires curiosity and judgment. The second requires little more than a backlog.

This distinction becomes harder when everyone agrees. When Sales, Customer Success, executives, and customers all support the same request, asking additional questions can feel unnecessarily cautious. Product teams may even worry that continued discovery will be interpreted as resistance to something the organization has already decided.

In our experience, those are precisely the moments when strong product leadership matters most. The objective is not to prove everyone wrong or to protect the roadmap from customer requests. It is to make sure the organization understands the problem well enough that the investment it is about to make has a reasonable chance of creating the outcome everyone expects.

Customer feedback should absolutely influence product strategy. It should challenge assumptions, expose problems, reveal opportunities, and occasionally force organizations to reconsider decisions they were confident about. What it should not do is relieve product teams of the responsibility to think.

The most dangerous customer feedback is not necessarily the complaint from an angry customer or the strange request nobody understands. Those are easy to recognize as signals requiring investigation. The more dangerous feedback is the request that arrives already surrounded by agreement, because agreement creates the comforting illusion that the learning is finished.

Often, that is exactly when it needs to begin.