At some point "listen to your customers" came to mean "do what your customers say."
Customer obedience is just order-taking. A request comes in, you build it, you close the ticket, everybody feels productive. And it feels like service — that's the trap. It's not service. It's you handing the wheel to whoever happened to complain loudest that week. You're not steering anymore, you're being steered, and you've dressed it up as being responsive.
Customer obsession is something else. It's caring about the problem more than you care about the request. Because here's the thing — customers are great at telling you where it hurts. They're terrible at telling you what's wrong, and even worse about telling you what's wrong with a group of people.
So when a customer asks for a bigger "export to spreadsheet" button, the obedient team ships the button and moves on. The obsessed team asks why the data keeps trying to crawl out of the product in the first place. The request is a symptom. You don't build symptoms.
And the reason obedience is dangerous — not just lazy, dangerous — is that it optimizes for the wrong person. It optimizes for the one individual in front of you. And individuals are quicksand. Not because people lie, but because everybody assumes their own weird situation is everybody's situation. So you build the thing they swear is a dealbreaker, and it turns out four other accounts ever touch it.
You have to be true to a type of customer, not a specific customer. An individual's needs change. They grow, they pivot, they get acquired, they leave. Build your product around one of them and one day they walk, and you're left holding a product that's perfectly shaped for somebody who isn't here anymore — and a bad fit for everyone who is. A type, on the other hand, is stable. The needs stay roughly the same. Lose one, there's a thousand more behind them who need the same thing.
Now, the part people don't believe until you show them the receipts: piling on features to keep individuals happy doesn't just clutter the product, it actively makes it worse for the people who stay. There's a study on this — Thompson, Hamilton, and Rust, in the Journal of Marketing Research, called it "feature fatigue". Before people buy, they want capability, so they reach for the product that does the most. After they start using it, they want usability, and the loaded-up product starts losing. Same product, same features — just used. They surveyed buyers and users separately and got completely different answers. Which means loading up a product with features might be winning you customers and losing you users at the same time.[1]
Which means the skill that actually matters isn't saying yes faster. It's saying no, and meaning it. And if that sounds harsh, take it up with Michael Porter, because that's just what strategy is. He built his whole definition of the word around it — the essence of strategy is choosing what not to do, because strategy is the trade-offs, and without trade-offs anybody can copy you and you're back to grinding it out on efficiency alone.[2] A roadmap with no "no" in it isn't a strategy. It's a queue.

Here's how you catch which mode you're actually in, because everybody claims they're customer-obsessed. Look at what your team measures. If it's inputs — requests closed, features shipped, tickets cleared — that's obedience wearing the obsession t-shirt. If it's outcomes — did the customer get where they were trying to go — that's the real thing. One fills a changelog. The other builds a product.
So the next time someone rolls up with "this customer asked for it, so we should build it" — that's not the end of the conversation. That's the start of one. What are they actually trying to do? Does it serve the type, or just this one loud account? And then you have to be willing to say that's not us — not as a brush-off, but because that's the only way you ever get to be unmistakably good at the one thing you decided to be good at.
Pick your type. Serve them like zealots. Wave politely at everyone else.
Sources
[1] Feature Fatigue: When Product Capabilities Become Too Much of a Good Thing: Thompson, Hamilton, and Rust, Journal of Marketing Research 42, no. 4 (2005) ↩
[2] What Is Strategy?: Michael E. Porter, Harvard Business Review (November–December 1996) ↩