Stewart Butterfield wanted to make a game. Not metaphorically, not as a side project, not as a hobby he pursued on weekends. Glitch was a real company, funded by real venture capital, staffed by real engineers, and it launched in 2011 as a massively multiplayer browser game built around a whimsical, collaborative world. It was genuinely interesting. It was also, by any commercial measure, a failure. Glitch shut down in 2012.
But while building Glitch, Butterfield’s team had developed an internal messaging tool to coordinate across time zones. When the game died, that tool was all they had left. They cleaned it up, gave it a real name, and launched it publicly in August 2013. By February 2015, Slack was valued at over a billion dollars.
This is one of the most famous pivots in tech history, and it’s usually told as a redemption story. Failure leads to accidental success. The underdog finds the real treasure buried in the wreckage. But I think that framing undersells what actually happened, and it obscures a lesson that most founders get exactly backwards.
The mythology around the pivot tends to frame it as an accident. The founders stumble onto something better while chasing something else. But Slack wasn’t an accident. The team had been using their internal chat tool for years. They knew it worked. They knew their own productivity depended on it. The decision to pivot wasn’t desperation, it was pattern recognition. They had already solved a problem for themselves. The question was whether other teams had the same problem.
The answer, obviously, was yes.
Here’s what most startup postmortems miss: the original problem doesn’t have to be the right problem. The original problem just has to be hard enough, specific enough, and real enough that solving it forces you to build something genuinely useful. Glitch required coordinating a distributed team in real time across a complex creative project. That constraint produced Slack. The game was the kiln. The tool was what came out of it.
YouTube followed a similar arc. The original concept, circa 2005, was a video-based dating site where people would upload clips of themselves describing their ideal partner. Nobody wanted this. But the underlying infrastructure, fast video upload, reliable hosting, shareable links, turned out to be exactly what the internet needed for everything else. The founders noticed that users were uploading whatever they wanted regardless of the intended use case, and they got out of the way.
Twitter came out of Odeo, a podcasting company that got blindsided when Apple announced iTunes would support podcasts natively. The core team built a side project during a hackathon. That side project became one of the most influential communication platforms of the next two decades.
The pattern isn’t coincidence. It’s a specific kind of product discovery that only happens when you’re deep in a real problem. You build something for yourself, or for a narrow use case, and the act of building it teaches you what actually matters. The original problem is the entry point, not the destination.
But here’s where I want to push back on the standard reading of these stories: the pivot only works if founders are paying close attention to what they’ve already built. Most teams aren’t. They’re heads-down on the original thesis, treating everything else as distraction. The internal tool that becomes Slack gets ignored. The video infrastructure that becomes YouTube gets treated as a technical necessity, not a product. The successful pivot requires a specific kind of attention, an ability to notice when the byproduct is outperforming the main event.
Amazon Web Services is the canonical example of this at scale. Amazon built massive internal infrastructure to handle its own e-commerce operations. The infrastructure was so good that they eventually realized other companies needed the same thing. AWS launched publicly in 2006. Today it generates more operating profit than the retail business that created it. The original problem, selling books online, funded the infrastructure that became the real business.
This is worth sitting with. One of the most profitable technology businesses in history was a byproduct of solving a logistics problem for a bookstore.
None of this means founders should be cavalier about their original vision. The gaming company that never ships a game because they’re too busy building internal tools has a different problem. The discipline required to actually solve a hard problem is what produces the useful byproducts in the first place. You cannot accidentally build something robust while you’re slacking off on the main project. The rigor transfers.
What it does mean is that founders should treat their original problem as a hypothesis, not a mandate. The question isn’t “how do we make our original idea work” but “what have we actually learned about what people need.” Those are different questions, and only one of them points at the exit.
There’s a version of this that fails badly, worth naming. Companies that pivot purely from fear, abandoning a working product because growth is slow or competition is fierce, are doing something different from what Butterfield did with Slack. The reactive pivot is usually a mistake. Glitch didn’t pivot because it was scared. It pivoted because it was dead. The distinction matters. Listening to customers killed one startup. Ignoring them made another rich. The signal you’re looking for isn’t distress inside your company. It’s unexpected traction somewhere adjacent to what you’re building.
Slack hit a million daily active users within 24 hours of its public launch. That’s not a gradual signal you might miss. But in most cases, the signal is quieter. It’s the enterprise customer who keeps asking your B2C product to do something weird. It’s the API you built for internal use that five other companies are asking to license. It’s the workflow your team uses daily that nobody else in the market has productized.
Pay attention to what you’ve built that works. Especially when it wasn’t what you set out to build.
