In August 2013, Stewart Butterfield sent an internal memo to his team. The subject was a pivot. Not the kind startups announce on TechCrunch to generate buzz, but a genuine, company-threatening lurch away from the thing they had spent two years building. Glitch, the massively multiplayer online game that had consumed his team’s energy and most of his investors’ money, was shutting down. What the team planned to do next was build a workplace messaging tool based on the internal chat system they had rigged together to coordinate their own development work.
That memo, later published under the title “We Don’t Sell Saddles Here,” is now considered a minor classic of startup writing. But most people who cite it focus on the wrong thing. They quote the inspirational parts about selling the “vacation” not the suitcase. What they skip over is the setup: a failed game studio, a team of people trying to salvage something from wreckage, and a product that only existed because they needed it themselves.
Slack found product-market fit by accident. Not accidentally in a charming, serendipitous way. Accidentally in the sense that the thing that worked was a byproduct of the thing that failed.
The Setup
Glitch launched publicly in 2011 after years of development. It was a genuinely strange, creative game, the kind of thing that should have attracted a devoted niche audience. It did attract a devoted niche audience, which turned out to be the problem. The player numbers never scaled to justify the infrastructure and headcount required to run it. In November 2012, Butterfield shut it down. His team had built something that people liked but not enough people needed.
During that development cycle, the team had been using an internal messaging system to coordinate across multiple time zones and disciplines. It was fast, searchable, and integrated with the tools they were already using. When Glitch died, some version of this internal tool was the one artifact from the wreckage that seemed genuinely useful beyond their own walls.
This is the part the startup mythology usually skips: they didn’t validate a hypothesis. They didn’t run a lean experiment. They built something for themselves, failed at the thing they were trying to build, and then looked at the rubble to see what was left.
What Actually Happened
The Slack beta launched in August 2013. Butterfield reached out to a handful of friendly companies to try it, starting with Rdio, Cozy, and a few others. Within 24 hours of opening the beta, roughly 8,000 people had signed up. That number, reported at the time and widely cited since, is interesting not because it proves demand but because of where it came from. These were people with a specific pain point, teams doing asynchronous coordination work, who recognized immediately that the thing in front of them was better than what they were using.
The product didn’t need to be explained. That’s the real signal. When you have to spend significant energy teaching someone why they should want what you built, you probably don’t have PMF yet. When your beta users start asking when their colleagues can join, you’re getting warm.
But here’s what actually matters about the Slack story: the team spent considerable time after that early traction figuring out which version of PMF they actually had. The risk in early 2014 wasn’t whether anyone wanted Slack. It was whether enterprise IT departments, the people who sign procurement deals, would ever buy it. The product had viral bottom-up adoption, but that mechanism had killed other tools before it. Yammer had done the same trick and then essentially stalled until Microsoft acquired it. Bottom-up SaaS was not obviously the right model.
Slack’s bet, which turned out to be correct, was that enterprise software buyers were getting tired of the old procurement model and that a tool their employees were already using and loved was a better sales motion than a traditional top-down pitch. That bet paid off, but it wasn’t validated until it was. The team was operating on conviction backed by early signals, not certainty.
Why It Matters
Startups treat PMF as a destination, a threshold you cross after which the hard work is justified and the metrics start moving. That framing creates two problems.
First, it causes founders to keep searching for the moment instead of watching the process. Slack didn’t cross a line. It accumulated evidence. The initial beta numbers were a signal. The retention data after the first 30 days was another signal. The speed at which individual teams converted their colleagues was another. The product’s behavior in those early months told a story about how it would grow, but only if you were reading the signals correctly and not waiting for a announcement from the market that you had “made it.”
Second, the destination framing causes founders to over-index on the wrong metric at the wrong time. Many companies hit strong early growth and call it PMF when what they actually have is a compelling demo and a market of early adopters who will try anything new. Early adopters are not your market. They are a useful test population, but they tolerate rough edges and missing features that your actual market will not. Your best early customer is sometimes your worst long-term signal.
Slack spent two years on a game. The game failed. The byproduct of making the game succeeded enormously. The lesson is not “fail first so you can succeed later,” which is glib and useless. The lesson is that PMF usually arrives through a side door you weren’t watching, often in the form of something that was built for internal use, or a customer segment you weren’t targeting, or a use case you thought was marginal.
What You Can Learn
None of this is an argument for running chaotic companies and hoping for lucky accidents. Butterfield’s team was technically skilled, had domain experience in building collaborative products, and had strong pattern recognition about what good software felt like. The luck was contingent on capability.
The actual lesson is about observation. What are your users doing with your product that you didn’t intend? Which customer segment is retaining at rates that surprise you? What internal tool did your team build to solve a problem that your customers also have?
Slack’s founders were paying attention to what they had actually built, not just what they intended to build. When the game failed, they didn’t mourn it and start from scratch. They looked at the wreckage and identified the component that was working. That capacity for honest inventory, especially after a failure, is rarer than technical skill and harder to teach.
PMF is not a moment. It’s a pattern that becomes visible in retrospect, usually assembled from data points you collected while you were convinced you were building something else entirely. The founders who find it are not the ones who searched most methodically. They’re the ones who stayed curious about what was actually happening, even when it wasn’t what they planned.
