In 2014, Slack was growing fast enough that the team could have ignored almost any individual complaint. Stewart Butterfield and his team were watching adoption curves that most founders never see. Thousands of new users per day. Companies signing up without being sold to. The kind of organic growth that makes you feel invincible.
Then a customer called them out on something nobody wanted to hear: Slack was unusable at scale.
Not slow. Not ugly. Unusable. As in, when you have enough people and enough channels and enough history, the thing you built to reduce noise becomes the loudest room in the building.
The Complaint That Felt Like an Attack
Every startup has a version of this story. A customer shows up with a complaint so pointed, so specific, and so relentlessly documented that your first instinct is to treat them like a problem rather than a signal. They’ve catalogued every failure. They’ve drawn up comparisons. They’ve probably emailed multiple people on your team. And they’re right, which is the worst part.
For Slack, the pressure came from large enterprise teams who had moved entire organizations onto the platform and discovered something that small teams never would: channel sprawl at scale is genuinely disorienting, message search breaks down when the corpus gets big enough, and notification settings designed for a 15-person startup become instruments of chaos for a 500-person company.
The easy response, the one that kills companies, is to say the customer is using the product wrong. That they’re an edge case. That their needs are outside the intended use. This logic has a seductive internal consistency. You built a tool for X. They’re trying to use it for Y. Not your problem.
Except it is your problem, because Y is where the real money is.
What Listening at Scale Actually Requires
Here’s what most founders get wrong about customer feedback: they treat it as a voting system. The most common request wins. The loudest voice gets addressed. The customer with the biggest contract gets the feature they asked for.
Slack didn’t do that. What they did instead was harder and more valuable. They tried to understand what the frustrated enterprise customers were actually describing when they complained. And what emerged wasn’t a list of feature requests. It was a diagnosis of a structural problem.
Large organizations don’t use software the way small teams do. The friction that disappears at small scale reappears at large scale, amplified. When a 12-person team uses Slack, a missed message is a minor inconvenience. When a 500-person company uses it, a missed message in the wrong channel can be a compliance failure, a delayed product launch, or a customer left in the dark.
The customers who were loudest weren’t just annoyed. They were articulating a gap between what Slack had built and what enterprise work actually looks like. Slack responded by building Shared Channels, by overhauling enterprise key management, by investing seriously in compliance and data retention tools. These weren’t the features that made Slack viral. They were the features that made Slack a business.
By the time Microsoft launched Teams in 2017, Slack had already done the hard work of becoming enterprise-ready. Not because they guessed the future, but because they listened to the customers who were most inconvenienced by the present.
The Difference Between a Churner and a Critic
There’s a meaningful distinction that most product teams collapse into one category: the customer who leaves because your product isn’t right for them, and the customer who stays and fights because your product is almost right for them.
The first group is telling you something about fit. The second group is telling you something about your product.
Customers who churn quietly are often the ones you should’ve fired before they fired you, as we’ve written about before. They were never going to be transformed into advocates because the core value proposition never matched their core need. Their departure is data, but not the actionable kind.
The difficult customer, the one who sends long emails and escalates to your CEO and submits seventeen support tickets in a month, is often something else entirely. They’ve invested enough in your product to be genuinely frustrated by its limitations. Frustration at that level implies belief. You don’t get angry at a hammer for not being a saw. You get angry at a hammer that almost worked as a saw and keeps failing at the last moment.
These are your most valuable critics. The trick is building systems to hear them without being captured by them.
Don’t Let One Customer Write Your Roadmap
None of this means you should let your angriest customer dictate your product direction. That path leads somewhere worse than ignoring them entirely. A roadmap built around the loudest voice becomes a bespoke solution for one organization, wrapped in the delusion that it’s a platform.
The useful discipline is pattern recognition. When an angry customer shows up with a problem, the question isn’t whether to fix their specific complaint. The question is whether their complaint points to something structural that many other customers are experiencing quietly.
Most customers don’t complain. They just churn, or they adapt to your limitations in ways that never show up in your product analytics. The customer who is angry enough to document everything and escalate loudly is, in a strange way, doing you a favor. They’re externalizing something that most of your users internalized and gave up on.
Slack could have treated its frustrated enterprise customers as outliers. Instead, it treated them as early indicators of where the product had to go. The result was a company that sold to IBM, to Oracle, to companies with tens of thousands of seats, without losing the product qualities that made small teams love it in the first place.
The Signal Hidden in the Friction
The startup mythology version of product development is that great founders have such clear product vision that customer feedback is almost noise. Build it and they will come. Trust the vision. Don’t design by committee.
There’s a version of this that’s true and a version that’s self-serving nonsense. The true version: you shouldn’t let customers define your vision for you. The false version: customers who push back on your product are obstacles to that vision.
The customers who almost broke Slack turned out to be the ones who saw further. They weren’t asking Slack to become a different product. They were asking it to become the full version of what it already was. That’s the kind of feedback worth fighting through the friction to find.
The question every product team should be sitting with isn’t which customers to listen to. It’s which complaints, underneath their specific details, are actually telling you something true about what you haven’t built yet.
