There is a phrase frequently repeated by product managers that, although it may sound cliché, is rarely applied consistently in day-to-day work. You've probably heard the famous quote attributed to Henry Ford: "If I had asked people what they wanted, they would have said faster horses." This idea sums up one of the greatest challenges in product development: Understanding what customers and users truly need. Often, they themselves are unclear about their real needs. But do companies genuinely understand the weight of this insight and act accordingly?
This leads us to another well-known phrase that I have always disliked:
"The customer is always right."
I strongly disagree with it. To be more coherent, I’d say, “The customer is always right, as long as they are right.” If we follow the logic of the original phrase, I, as a customer, could walk into McDonald’s and ask for sushi. If I’m not served, would that be a failure on their part for not giving me what I want? Obviously not. I can order anything, as long as it’s on the menu. If I insist on something beyond that, like sushi, the solution isn’t to demand it from McDonald’s, but to go to a restaurant that actually offers it.
Strangely enough, equivalent situations are much more common in digital product development. Why is that? Perhaps because the boundaries in these contexts are not clearly defined. And if they’re not, whose fault is it?
The Product Culture Problem
This is a matter of Product Culture. A company lacking a strong product culture, with well-defined scopes and a clearly outlined ICP (Ideal Customer Profile), is doomed to become a feature factory, gradually making its product irrelevant, even if it offers a long list of functionalities. This isn’t to say that a company must remain static. If a new market opportunity is identified, pivoting is valid, provided the implications are well understood and the organization is restructured to support the shift.
The biggest risk emerges when development decisions are based on ad hoc user requests, many of which turn out to be useless or underutilized. There are no comprehensive public datasets on the volume of features that become irrelevant each month, but a quick chat with a few product managers will reveal the scale of the problem. Time, money, and intellectual capital are wasted due to a lack of critical analysis and, most importantly, a failure to understand what it truly means to be a product-led company. When this is combined with short-term targets, and a disregard for opportunity cost, we see a pattern that leads many companies to stagnation (or even closure).
User vs Customer
Another critical point is the confusion between user and customer. Want an ineffective product? Have your product operations team gather problem statements directly from users who don’t actually have decision-making power. In B2B contexts, users are rarely the real customers and are often two or three levels below the decision-maker. Relying solely on their perspective is a costly mistake. It's essential to distinguish between the needs of the individual user and those of the organization. In a prioritization matrix, for instance, the user might request a feature to ease their workflow, while the company values data security or operational scalability.
Correctly identifying the real user of a solution is also a challenge. A delivery app, for example, might assume its users are young students but later realize the true decision-makers are their parents, who control the payments. This insight affects everything: Design, messaging, and the overall value proposition. The same applies to feature requests. A user might ask for something relevant only to their narrow scope, unaware of more strategic needs across the broader system.
One example of this occurred while leading the development of a healthcare solution. Interactions with clients were mainly mediated by IT analysts who acted as intermediaries between the product team and the actual end users (doctors, nurses, and receptionists). Frequently, these analysts prioritized requests that made their own maintenance or support work easier, such as simplifying administrative panels or adding internal automations. However, those requests had little impact on the real users' experience.
It became necessary to adopt a more critical approach, questioning the motivations behind each request and conducting direct interviews with healthcare professionals to understand their true pain points and workflows. This process helped us realign the backlog toward issues genuinely centered on the end user, such as reducing record entry time and optimizing patient flow, actions that effectively increased both adoption and user satisfaction.
The Limitations of the User Perspective
The truth is that the user is not always right. Not out of ill intent, but due to a limited understanding of what's possible. Their suggestions are based on past experiences, known tools, and existing constraints. Before smartphones, few imagined a single device could replace cameras, maps, agendas, music players, and even computers. Similarly, today, many are unaware of how automation and AI could transform their workflows.
This limitation directly affects requirements gathering. Often, instead of identifying the best solution, we simply document current processes (inefficiencies included). Consider a basic scenario:
You’re hired to optimize cargo loading in a logistics company. If you interview only forklift operators, you’ll hear requests like “more modern forklifts” or “better route organization.” It’s unlikely they’ll suggest replacing themselves with autonomous machines or conveyor systems.
To avoid waste in product development, we now have a wide array of tools available: Process mapping, A/B testing, design systems, user stories, storytelling techniques, JTBD, and many analytics tools. But all of them are useless if the product’s scope isn’t clearly defined. We must ask critical questions:
- Does this requested feature really need to be built?
- Is the product scope clear and well communicated?
- Is the ICP well defined and understood by everyone, including executives and middle management?
- Is the client genuinely aligned with the solution, or is the product being shaped to fit the wrong audience?
Time is always scarce. Under pressure for quick deliveries, companies often cut critical thinking and analysis in favor of immediate profit, sacrificing a broader, long-term product vision. It’s the product manager’s role to shape company strategy toward sustainable growth. But the main questions remains:
Do they have the autonomy and influence to do so?
Do executives truly understand the scope of Product Management and how product managers should drive company strategy?
Lessons from working on a B2B E-commerce platform
Another relevant experience took place while I was leading the development of a B2B e-commerce platform originally designed for mid-sized retailers. Some clients began using the system in contexts completely different from its intended purpose, for instance, to conduct online auctions, and started demanding features like extreme concurrency controls, stock-locking mechanisms, and session-blocking functionalities.
Meeting these isolated requests would have meant distorting the product’s scope and compromising its stability. At that moment, the reflection proposed about questioning whether the customer is “right” within the strategic context became crucial. We decided to reaffirm the platform’s positioning, reinforce communication of the Ideal Customer Profile (ICP), and create an API module for specific integrations, allowing exceptional cases to be handled without undermining the core architecture.
These experiences strengthened my conviction that the true role of a Product Manager is to protect the product’s purpose and coherence, ensuring that decisions are guided by evidence and long-term vision rather than by short-term demands. Understanding when the customer is not right is, paradoxically, one of the most responsible ways to generate lasting value.
PS.: I recommend you take a few minutes to read the two articles mentioned, in which I demonstrate how short-term goals can kill the product and how the financial analysis of customizations is a trap when considering the opportunity cost.
