Case Study 24-2: The Slack Origin Story — Failing Productively as Serendipity Engineering

A Company That Failed Into a Better Company

In 2009, Stewart Butterfield had already succeeded once. He had co-founded Flickr — the photo-sharing platform that became a major internet property before being acquired by Yahoo in 2005. He knew how to build a tech product. He knew how to scale a community. He knew how to attract users.

What he built next had none of those advantages.

Glitch was a browser-based multiplayer game set in an absurdist world of giant mammals. Players could pet pigs to produce pigments, squeeze butterflies to make energy, and interact with an elaborate, surrealist ecosystem. It was imaginative, creative, and beloved by the people who played it. It never found a large enough audience.

In 2012, after years of development and tens of millions of dollars invested, Butterfield shut Glitch down. By conventional measures, it was a significant failure.

What Glitch left behind, however, was not just memories of a quirky game. The team had built an internal communication tool for their own development process — a system for coordinating a distributed team that was working across time zones and disciplines on an enormously complex, constantly evolving product. The tool was threaded, searchable, and organized by channel. They called it Slack.

Slack — the software that failed game studio Glitch accidentally built while trying to coordinate the building of Glitch — launched publicly in 2013. Within 24 hours of launch, 8,000 companies signed up. Within three months, it had 30,000 daily active users. It reached a $1 billion valuation in 15 months, faster than almost any other enterprise software company in history. By 2021, when Salesforce acquired it, the company was valued at $27.7 billion.

What Kind of Serendipity Is This?

The Slack story is a nearly perfect example of pseudo-serendipity: a company searched for one thing (a successful video game), found something else (a transformative enterprise communication tool), and the thing they found was more valuable than the thing they were looking for.

But calling it pseudo-serendipity and moving on would miss everything interesting about the mechanism. How, exactly, does a failed video game become a billion-dollar enterprise software product? The answer requires looking at how Butterfield and his team made a series of decisions — decisions that most people in their position would not have made — that transformed a failure into a serendipitous discovery.

The Decisions That Made Pseudo-Serendipity Possible

Decision 1: Building the Internal Tool in the First Place

Most gaming companies trying to coordinate a distributed team in 2009 used existing tools: email, forums, IRC channels, Skype. Butterfield's team could have done the same. Instead, they built their own communication system tailored to their specific needs.

This decision was not made because anyone predicted Slack's future. It was made because existing tools were inadequate for the specific problem they faced: coordinating real-time game development across a distributed, asynchronous team with enormous amounts of shared media and context-dependent discussion.

Building your own tool when existing tools are insufficient is a serendipity trigger: it creates an artifact — a proof of concept that solves a real problem — that might turn out to solve the same problem for others who haven't thought to build it themselves.

Decision 2: Recognizing That the Tool Was Interesting

When Glitch failed, Butterfield and his team could have folded the company entirely, written off the experience, and scattered to other opportunities. Many founders do exactly that after a major failure.

Instead, Butterfield noticed that the tool they had built while building Glitch was genuinely better at solving team communication problems than anything they had encountered. This recognition required what the chapter calls serendipity antennae — the attentional posture that notices the unexpected interesting thing even while dealing with the failure it emerged from.

The timeline is stark: Glitch shut down on December 6, 2012. Within weeks, Butterfield and his remaining team had pivoted to developing the internal tool as a standalone product. The speed of that pivot suggests something important: Butterfield had probably been noticing the tool's quality for some time before Glitch's failure made the pivot available as a choice.

Decision 3: Beta-Testing with Outside Companies

Rather than just developing Slack and launching it, Butterfield recruited a handful of outside companies to use it in their real work environments before launch. These included other tech companies and startups with no prior connection to Glitch or Butterfield's team.

This decision functioned as a serendipity hook at scale: by inviting others to use the tool in real contexts, Butterfield allowed external perspectives to reveal the tool's value in ways the team — who had built it for their own specific needs — might not have seen. The beta test participants became external validators of a discovery Butterfield had made internally.

The beta testing also exposed what the team didn't know: which features mattered most to users who were not game developers, which workflows were assumed but not built, and which aspects of the product were universally compelling versus specific to Glitch's unusual team dynamics.

Failing Productively: A Serendipity Engineering Framework

The Slack story illustrates a specific and important category of serendipity engineering: productive failure. This is distinct from both lucky stumbling and from deliberate search. It is the intentional approach to failure that maximizes the serendipitous value that failure can generate.

Productive failure, as a practice, involves:

1. Building real artifacts while pursuing the primary goal. Glitch's team built Slack because they needed it, not because they were hedging against Glitch's failure. The artifact they built was real, functional, and tested under the genuine pressure of actual use. Artifacts produced by doing real work have intrinsic quality that artifacts produced speculatively do not. This is why the "build something real, even as a side effect" principle is a reliable serendipity trigger.

2. Treating failure as a data event, not an ending. When Glitch failed, Butterfield treated the event as new information: what remains? What did we build that actually works? What did we learn that is transferable? This is the opposite of the sunk-cost response to failure (denial, grief, withdrawal) and the opposite of the lucky-stumble response (pure surprise). It is an active, analytical engagement with what the failure leaves behind.

3. Maintaining the team through the failure. Butterfield kept a core team together through the Glitch shutdown. This allowed the knowledge, culture, and working relationships that had produced the tool to survive the failure of the primary goal. Serendipitous discoveries are often latent in the relationships and tacit knowledge that form during a project — not just in the artifacts. Maintaining the team preserved the institutional knowledge necessary to develop Slack.

4. Acting quickly on the recognition. The pivot from Glitch to Slack happened in weeks, not years. This speed required Butterfield and his team to have been paying attention to the tool's value before the crisis made the decision necessary. Serendipity engineering often means having recognized the value of the unexpected thing while you were still focused on the primary goal — so that when the primary goal disappears, you know immediately what you have.

The Counter-Argument: Was This Really Serendipity?

A skeptic might argue: Butterfield was an experienced entrepreneur with strong technical skills and investor relationships. He was in a position to recognize and exploit the opportunity that Glitch's failure revealed because of who he was and what he had built before. The "serendipity" looks like competence operating under adverse conditions, not an accidental lucky break.

This is worth taking seriously. And the chapter's framework has a clear answer: serendipity does not require that the person be unprepared. In fact, the most reliable form of serendipity (sagacity) requires exactly the prepared mind. Butterfield's preparation — his network, his technical skills, his experience building Flickr, his pattern recognition about what makes a good enterprise tool — is precisely what allowed him to see what Glitch had produced and know what to do with it.

The accident was real: he was not trying to build enterprise communication software. The sagacity was also real: he had the background to recognize that what he had accidentally built was valuable, and the capability to develop it. This is the argument the chapter makes about Pasteur and Archimedes and Fleming: preparation doesn't prevent serendipity, it enables it.

The Broader Lesson: Startups as Serendipity Machines

Butterfield himself has reflected on the pattern. "We've decided that Slack is this new kind of product," he told an interviewer, "and the things that make it feel like Slack are the things that emerged from our particular needs as a game company." The product's distinctive character — its playful design, its search-first architecture, its channel-based organization — emerged directly from the specific needs of Glitch's unusual team.

This is a broader pattern in startup history. Several major companies emerged from the wreckage of companies trying to do something else:

• YouTube grew out of the difficulty its founders had sharing a video at a dinner party — a problem encountered while working on a different startup altogether
• Twitter emerged from a podcasting startup (Odeo) that was suddenly threatened by Apple's iTunes podcasting support; the team held a brainstorming day and one idea — a short-message status update system — became the product
• Instagram grew out of Burbn, a location-check-in app that wasn't gaining traction; the founders stripped everything away except the photo feature and rebuilt around it

In each case, the pattern is similar to Slack: a team building one thing noticed that something produced in the process of building that thing was more interesting than the thing itself. The noticing — the serendipity antenna — was the critical skill.

Discussion Questions

1. Butterfield could have used existing communication tools (email, Slack-era IRC, forum software) instead of building a proprietary internal tool. How important was the decision to build rather than use existing tools? Would Slack have been discovered if the team had used email?

2. The pivot from Glitch to Slack happened within weeks of Glitch's shutdown. What does this suggest about how long Butterfield and his team had been noticing the internal tool's value? What cognitive or behavioral habits enable this kind of ongoing awareness of unexpected value?

3. Compare the Slack story to the Post-it Note story (Case Study 24-1). Both involve a "failed" primary effort that produced something more valuable. What are the key structural similarities and differences in how the serendipitous discovery happened?

4. The counter-argument section notes that Butterfield's "luck" looks a lot like preparation operating under adversity. Does this reduce the serendipity claim, or is it exactly what serendipity engineering predicts? What would the chapter's framework say?

5. YouTube, Twitter, and Instagram are given as similar examples of startup serendipity. Research one of these in more detail. Does the mechanism (a team noticing something unexpected while building something else) hold up under scrutiny? What does your research add to the pattern?

Key Terms (Chapter 24 Applied)

• Pseudo-serendipity: Searching for a successful game, finding an enterprise communication platform
• Serendipity antennae: Butterfield's ongoing noticing of the internal tool's quality during Glitch development
• Productive failure: Approaching failure as a data event that yields transferable artifacts and insights
• Serendipity by sagacity: The prepared background that enabled Butterfield to recognize and develop what Glitch had produced
• Serendipity artifact: The internal communication tool built as a genuine solution to a real problem, which became a standalone product