Around 2011, a project management startup in San Francisco had a problem most founders would envy: customers loved them and kept asking for more. Enterprise clients wanted Gantt charts. SMB customers wanted time tracking. A handful of vocal power users wanted a native desktop app. The team, eager and responsive, built all of it. Within two years they had a product that did everything and was known for nothing. They ran out of runway before they could figure out which of those things actually mattered. The company quietly shut down.
Around the same time, a team building a communication tool kept getting requests to add email integration, task management, and project timelines. They said no to almost all of it. The product stayed weird and narrow. That company was Slack, and Stewart Butterfield sold it to Salesforce for $27.7 billion.
Those aren’t cherry-picked outliers. They’re a pattern.
The Feedback Trap
Customer feedback is seductive because it feels like evidence. You’re not guessing what people want, you’re being told. This is how founders justify building feature after feature without ever stepping back to ask whether the product is getting better or just bigger.
The problem is that customers are not product managers. They’re describing symptoms, not diagnoses. When someone says “I need Gantt charts,” what they usually mean is “I’m struggling to see how our work fits together over time.” Gantt charts are one solution to that problem. They might not be the right one. And if your product isn’t designed around that underlying problem, adding Gantt charts won’t help, it’ll just add complexity.
Customers also describe what they already know. They ask for features that exist in other tools because those are the solutions they can name. Early Slack users who wanted email integration weren’t wrong that they had a communication problem. They were wrong that email was the answer. Butterfield’s team understood that, even when users didn’t.
Why Saying Yes Feels Like Strategy
Building to customer requests has a seductive logic. It feels customer-centric. It generates goodwill. In the short term, it often produces revenue, because enterprise customers in particular will pay for custom features. This is exactly what makes it dangerous.
Every yes you say to a feature request is an implicit no to something else. It’s a no to the engineering time you could have spent making your core experience better. It’s a no to the design clarity that comes from a product that does one thing exceptionally. It’s a no to the future customers who might have loved what you were building before you compromised it.
Basecamp, which has been profitable for decades without taking outside funding, has written extensively about this. Their whole philosophy is built on refusing to let customer requests drive product decisions. When users ask for features, Basecamp often says no, or waits years before considering it. The product is better for it. So is the business. Deleting a feature is harder than building one, and Basecamp knows it.
The enterprise version of this trap is particularly insidious. A customer offers you $200,000 if you build their specific workflow into your product. You say yes. Then another customer wants modifications to that workflow. You say yes again. Eighteen months later you have a product that two customers love and everyone else finds confusing, and you’re locked into supporting custom logic that makes every future improvement harder. There’s a right way to handle enterprise pressure, and it involves saying no far more than most founders are comfortable with.
What Ignoring Customers Actually Means
Here’s what tends to get lost in this conversation: ignoring customer requests is not the same as ignoring customers. The best founders are obsessive about understanding their users. They just draw a hard line between understanding problems and accepting solutions.
Steve Jobs famously said customers don’t know what they want until you show it to them. This gets quoted endlessly and often misapplied. He didn’t mean ignore users. He meant that customers describe the world they know, not the world that’s possible. Your job is to understand their world better than they do, and then build something they couldn’t have asked for.
This requires a different kind of listening. Instead of treating a feature request as a task to be scheduled, treat it as a clue to be investigated. Why does this person want this? What are they doing right now that isn’t working? What would have to be true about their workflow for this request to make sense? Often you’ll find the real problem is something your product could address without building anything new. Sometimes you’ll find a genuine gap. Occasionally you’ll find that this user isn’t actually your customer.
The customer who almost quit knows more than your fans for exactly this reason. They’re telling you about structural problems, not feature wish lists.
What This Looks Like in Practice
The practical version of this isn’t complicated, but it requires conviction. You need a product thesis, a clear statement of what your product is and who it’s for, and you need to hold it firmly enough that customer requests bounce off it rather than accumulate inside it.
When a request comes in, the first question isn’t “how hard would this be to build?” It’s “does this fit our thesis?” If the answer is no, you decline and explain why. Not rudely, not dismissively, but clearly. Good customers respect this. The ones who don’t are often telling you something important about fit.
You also need to be honest about what kind of feedback you’re actually getting. Loud customers are usually your most engaged users, but engaged doesn’t mean representative. The person filing ten feature requests a week is often an outlier. The silent majority who signed up, found value, and kept paying without complaining are your actual market. Building for the squeaky wheel means building for the exception.
None of this means you never build what customers ask for. Sometimes the feedback is right, the request fits your thesis, and you should build it. The point is that the decision should come from your product thinking, not from the volume of requests or the size of the customer asking.
The startup that listened to everyone built a product that pleased no one well enough to survive. The one that held the line built something people couldn’t stop talking about. Conviction is a product strategy.
