Tiny Speck had been built to make a game. Glitch was imaginative, social, and difficult to categorize. It also failed to become a sustainable business. When the company announced in late 2012 that the game would close, the obvious interpretation was that the venture had reached its end.
But the team had built something else while trying to build the game: an internal communication system. Its value was easy to miss because it was infrastructure, not the product anyone had set out to sell. The system helped a distributed team share messages, files, and context. It was useful in the unglamorous, repeated work of making Glitch.
The distinction mattered. A retrospective story can make Slack look inevitable, as if a great collaboration product had been waiting inside a failed game all along. It was not inevitable. The team still had to recognize that an internal adaptation might solve a problem beyond itself. Then it had to learn whether other teams experienced the same pain.
Slack’s early approach was deliberately close to customers. Stewart Butterfield later described persuading teams in the founders’ network to try the product, watching how they used it, and learning from feedback. The product had grown out of Tiny Speck’s own habits, but that did not prove that its language, features, or value would transfer. Proximity to early users helped convert firsthand conviction into a proposition that other organizations could understand.
What were they really selling?
Before Slack’s preview release, Butterfield sent the team a memo titled “We Don’t Sell Saddles Here.” The argument was that the company could not define the market narrowly as workplace messaging. Customers did not wake up wanting another chat tool. The product mattered because of what it could make possible: less effort spent reconstructing information, better access to organizational knowledge, and more effective collaboration.
That reframing did not erase the failed game. It used the failure as evidence. Tiny Speck’s team knew the communication problem from inside the work. Their expertise was not simply technical. It was embodied in the constraints they had already lived through.
The lesson is not “pivot when something fails.” Many internal tools should remain internal, and many failed products do not contain another company. The more precise lesson is to inspect what the work forced you to invent. Failure can destroy the original thesis while leaving behind capabilities, behaviors, or insights that deserve a different question.
Sources and further reading
Keep exploring
Flickr: What if the community mattered more than the game?Instagram: What should you remove when users reveal what matters?Put the question to work with an AI prompt →Browse all cases →For a discussion tailored to your team, explore a workshop with Julien.