The Game That Failed and the Tool That Succeeded
Glitch was an online massively multiplayer game that Stewart Butterfield’s company Tiny Speck had been building since 2009. After three years of development and approximately $17 million in funding, Glitch shut down in November 2012 — the game was not attracting the user base it needed to be commercially viable. The team that had been playing with the game’s ideas was talented, the investors had been supportive, and the game’s creative vision was ambitious — but the core product hadn’t found its market.
During the Glitch development period, the Tiny Speck team had built an internal communication system to coordinate their distributed team. The system allowed real-time messaging, file sharing, search of message history, and integration with other tools the team was using. When Glitch was shut down, Butterfield and the remaining team recognised that the communication tool they’d built for themselves was solving a real problem — one that many organisations were experiencing — in a way that existing tools didn’t. The strategic decision to pivot from the failed game to the communication tool became the founding of Slack.
The Unfair Advantage of Building for Yourself
The insight that most explains Slack’s product quality at launch: the team had been using the tool themselves for three years as their primary communication system, which meant they had three years of evidence about what worked, what didn’t, and what they would have paid to fix. The product was designed for their own use case — distributed teams doing creative, technical work — and the polish and functionality that resulted from extended internal use made it meaningfully better than the existing alternatives even at the initial launch.
Paul Graham’s famous advice about startups — ‘make something people want’ — is often interpreted as understanding what customers want from external research. The Slack origin story illustrates a different path: making something for yourself that solves a real problem you have, and discovering that the solution is commercially valuable to others with the same problem. The internal tool that becomes a product has a specific quality advantage: it was validated by demanding, critical users (the builders themselves) before it was ever offered to external customers.
The Beta Strategy That Created Viral Adoption
Slack’s August 2013 launch strategy — a closed beta with selective invitation-only access — produced one of the most successful product launches in enterprise software history. The beta was structured to onboard entire teams rather than individual users (because Slack’s value is inherently collaborative and a single user trying Slack without their team sees almost none of the value), which meant each beta approval produced a group of users experiencing the product together and immediately generating the conversation history that demonstrates Slack’s search and productivity value.
The waiting list approach that generated demand before supply: by the time Slack opened its beta more broadly, there was a waiting list of thousands of teams. The waiting list served multiple purposes: it managed the server load of a rapid launch, it created the social proof of demand that made Slack seem like the thing to have access to, and it allowed the team to prioritise onboarding teams that were most likely to generate useful feedback and word-of-mouth. The strategic management of access during the beta period is one of the most replicated elements of Slack’s launch strategy in subsequent SaaS product launches.
Freemium as a Growth Engine
Slack’s freemium model — free for unlimited users with unlimited message history limited to the most recent 10,000 messages, and paid for additional history, compliance features, and administrative controls — was specifically designed to allow teams to get value and develop habits before encountering the need to pay. The 10,000 message limit was calibrated to the approximate message volume that a small team generates in 3–6 months of regular use: teams wouldn’t hit the limit immediately, but active teams would hit it at roughly the point where Slack had become central to their workflow and where the cost of switching (losing the institutional knowledge in the message history) exceeded the cost of the subscription.
The bottom-up enterprise sales motion that Slack pioneered: individual teams within large organisations would adopt Slack without IT or procurement involvement, develop workflows and integrations over months, and then find that the limitation on free accounts created the business case for a paid account that was already being used and valued. The enterprise sales conversation was happening after adoption rather than before — which reversed the traditional enterprise software sales cycle and dramatically reduced the sales effort required to convert users to paying customers.
The Lessons That Apply Beyond Enterprise Software
The Slack case study produces several widely applicable principles. First, the failure that contains the success: Glitch’s failure produced the team, the investors’ continued trust, and the internal tool that became Slack. The pivot was made from a position of recognising what the team had built internally rather than from desperation to generate revenue from anything available. The quality of the asset that came out of the failed venture was the basis for the success that followed.
Second, the viral coefficient that makes product design: Slack’s design requirement that the product only works with teams (not individuals) created the viral spreading mechanism that made enterprise adoption so fast. Each new team member added to a Slack workspace is an invitation to someone who hasn’t tried the product; each new team that joins Slack at an organisation exposes adjacent teams to a product they’re not using. Building the sharing and spreading mechanism into the product architecture itself — rather than adding it as a feature — is the design insight that produced Slack’s extraordinary organic growth rate, and it’s a design principle that applies to any collaborative or network-dependent product regardless of the specific category.