Why Users Are Reliable Witnesses and Unreliable Engineers
The asymmetry at the center of the feedback paradox is not a matter of intelligence or articulateness. It is structural. A user occupies a privileged vantage point on the texture of their own experience: where the workflow snags, which step they dread, what they were trying to accomplish when the product failed them. This is testimony no team can manufacture from the inside, because familiarity with one's own product is a form of blindness. But the same user has no vantage point on the solution space. They cannot see your architecture, your roadmap, the eleven other segments you serve, or the second-order consequences of the fix they propose. So they do what any competent person does when asked to solve a problem outside their visibility: they reach for the nearest adjacent thing they already know. The request for a faster horse is not stupidity. It is a correct local inference from a constrained vantage point.
The discipline this implies is to mine feedback for the evidence layer and discard the prescription layer. When a user says "add an export button here," the export button is a guess; the signal is that they hit a wall trying to move data out, at that moment, for some downstream purpose you should now go discover. Treating the prescription as the deliverable is how teams build a museum of half-used features, each one a faithfully implemented guess.
The Mechanism of the Cliff
Following users off a cliff is rarely a single bad decision. It is the compounding of a sampling bias and an incentive gradient. The users who file feedback are not a representative draw from your base — they are the loud, the tenured, the power users whose investment in the current design is deepest and whose tolerance for change is lowest. Optimize hard against this sample and you systematically sharpen the product for the people you already have while making it more forbidding for the people you have not yet earned. The incentive gradient finishes the job: each individual request is small, plausible, and cheap to grant, and granting it produces a visible, grateful response. Saying no produces silence. A product steered purely by feedback volume will therefore drift, request by reasonable request, toward maximal complexity and minimal coherence — the local optimum that is also a dead end.
Translating Input Without Surrendering Judgment
The resolution is not to listen less. It is to insert a translation step that the feedback itself can never perform, because it requires information only the product owner holds. That step converts the raw artifact of a request into a decision input by asking, in order:
- What underlying job was this person trying to do, stripped of the proposed solution?
- How many users share that job, including the silent ones who never filed anything?
- Does serving it advance the product's intended arc, or merely placate the loudest segment?
- What is the best solution to the job — which is frequently neither what was asked for nor anything resembling it?
Only the first question can be answered from the user's words. The remaining three are acts of product judgment, and they are precisely what cannot be outsourced. This is why "the customer is always right" and "ignore the customer, we know better" are the same error wearing opposite costumes: both collapse the two-layer structure into one, the first by promoting prescriptions to mandates, the second by discarding the evidence along with the guess.
The Decision Implication
The practical commitment is to hold yourself accountable for diagnosis while refusing to be bound by prescription. Measure feedback by the problems it reveals, not the features it requests, and accept that the correct response to a flood of requests is often a single change none of them named. The cost of this posture is real and worth stating plainly: you will disappoint articulate users who can see exactly that you did not build the thing they asked for, and you will not always be right about the deeper job. That is the trade-off the paradox forces. The alternative — letting the aggregate of local, well-meaning requests stand in for a coherent point of view — is not humility. It is the quiet abdication of the one responsibility a product owner cannot delegate: deciding, on behalf of users who described a problem and guessed at a cure, what is actually worth building.