A request from your biggest customer rarely arrives as a neutral product question. It arrives with revenue attached, a relationship to protect, a sales escalation, and usually someone asking for a date.
That pressure is not irrational. Losing an important customer can be expensive. But the customer’s importance can make the proposed solution look like stronger product evidence than it really is.
Why they are such good sensors
Large customers often hit scale, governance, workflow and integration problems before everyone else. They expose limits that smaller customers can live around. They may reveal where your data model breaks, where manual work becomes impossible, or where a seemingly harmless product assumption no longer holds.
That is useful signal. The mistake is jumping from “this problem is real” to “this requested feature is the product direction.”
I use three tests
Pattern. Does the underlying problem exist elsewhere, even if other customers describe it differently?
Leverage. If we solve it, does the product become stronger for a meaningful part of the market?
Residue. What complexity remains after this customer leaves?
Product residue is the part teams underestimate
A feature may take six weeks to build and five years to own. That ownership can include configuration, support logic, documentation, permission models, migration behaviour, tests, edge cases and future compatibility.
The build estimate tells you what the request costs now. Product residue tells you what the yes keeps costing after everyone who made the decision has moved on to something else.
If this customer disappeared tomorrow, would we still be glad this capability exists in the product?
Sometimes the correct answer is still yes
I am not arguing for purity. A large customer can expose the beginning of a market shift. They can finance capability that later becomes core. They can give access to usage, scale and operating conditions you cannot reproduce internally.
In those cases I would rather build deliberately than pretend the request is generic from day one. Start with the smallest version that solves the real problem. Keep the assumptions visible. Decide what evidence would justify generalising it.
That is different from letting the customer become the product manager.