Misconception (Chris Jones, SVPG): "our job is to give the customer what they're asking for." Customers often don't know what they want until they see it, because they don't know what's technologically possible — so a customer's stated feature request is only their best interpretation of a solution to a problem they're experiencing, not the actual spec to build.
The real job of a product team is to get underneath the request and deeply understand the underlying pain, then let the team — not the customer — devise the solution. Cited evidence: no focus group would have asked for the iPhone; no customer ever asked for Amazon Prime or AWS. Jeff Bezos, on customer input: "The biggest mistake you can make is listening to your customers," followed immediately by "The second biggest mistake you can make is not listening to your customers" — the resolution is listening for the underlying problem, not the literal ask.
Related phenomenon: Stated Preference vs. Revealed Behavior — what customers say they want in the moment of being asked often diverges from what they actually choose.
Red flag: newer PMs who build a roadmap by sorting or prioritizing a raw list of "most-requested features." Frequency of a request is still signal worth investigating — it just isn't, by itself, a spec. See Roadmap (Feature/Project List) and Outcome-Based Roadmap Reframing for the discovery-driven alternative, and Discovery (Product Discovery Process) for the underlying process this misconception bypasses.
When the request comes from high-pressure B2B deal pressure rather than routine backlog input, the same clue-not-spec logic applies but with different stakes — see Specials (Deal-Driven Feature Builds).
A red flag: building a roadmap by simply sorting and prioritizing features by how often customers ask for them. Frequency is a signal worth investigating, not a ranked build order — dig into the underlying "why" behind a frequent request, since a better, unrequested solution to the same underlying problem may exist.
"The biggest mistake you can make is listening to your customers" — meant as a warning against building literally what's asked for most, not literally against listening. See Specials (Deal-Driven Feature Builds) for the related deal-driven-request pattern.
Из тем: The Product Operating Model