The Setup
In 2009, Google unveiled Wave to a standing ovation at Google I/O. The demo was genuinely impressive: a real-time collaborative communication platform that blended email, instant messaging, and document editing into a single interface. Invites were scarce. Tech journalists called it the future of communication. Then, fourteen months after public launch, Google killed it.
The standard narrative writes itself: Google got arrogant, built something nobody wanted, and wasted hundreds of millions of dollars on a product that couldn’t find a market. That story is satisfying, clean, and mostly wrong.
The more interesting question isn’t why Wave failed. It’s why Google built it the way they did, knowing the odds against it, and what they got out of it that never showed up in the product’s obituary.
What Actually Happened
Wave was built by a small team in Sydney led by Lars and Jens Rasmussen, the brothers who had previously built Google Maps. That lineage matters. The Maps team had pulled off something technically remarkable, and Google gave them significant latitude to chase a genuinely hard problem: what would communication look like if you invented email today, knowing what we now know about real-time systems?
The engineering ambition was real. Wave introduced operational transformation at a scale and in a consumer product context that had never been attempted. The protocol allowed multiple users to edit a shared document simultaneously, with changes propagating character-by-character in real time, across distributed servers, without conflicts. This was not a trivial problem. The team published their approach openly and even proposed Wave as an open standard.
Where Wave struggled was precisely where the engineering succeeded too completely. The product was so flexible, so open-ended, that nobody could explain what it was for. When you can’t tell a new user what problem the tool solves, you have a positioning failure, not a technology failure. Users who got invites logged in, looked at an empty Wave inbox, and had no idea what to do next. The feature that made Wave technically impressive, its real-time character-by-character updates, made it socially exhausting in practice. Watching someone compose a message letter by letter, including all their false starts and corrections, turned out to feel intrusive rather than collaborative.
Google shut down Wave in 2010. But the engineering work didn’t disappear.
The operational transformation research fed directly into Google Docs’ real-time collaboration features, which are now used by hundreds of millions of people. The open-source Apache Wave project continued independently. Engineers who worked on Wave spread through Google and carried the institutional knowledge of building real-time distributed systems into subsequent products. The Sydney office that built Wave became a significant Google engineering hub.
The product failed. The investment didn’t.
Why This Pattern Exists
Tech companies build products they know have high failure probability for a reason that accounting systems are bad at capturing: working software is the most efficient way to learn certain things.
You can run user research. You can build prototypes. You can analyze the market. None of those approaches answer the question that Wave was actually asking, which was: can we build operational transformation that works at consumer scale, and if we can, does that unlock something people actually want? The only way to answer that question is to build the system and put real users on it.
This is distinct from recklessness. Google didn’t build Wave hoping nobody would notice the failure. They built it as a structured experiment where the engineering knowledge was valuable regardless of the product outcome. The distinction matters because it changes how you evaluate the decision. Judged as a product launch, Wave was a failure. Judged as an infrastructure research project with a product wrapper, it was closer to a success.
Microsoft ran a version of this logic with Courier, the dual-screen tablet concept that leaked in 2010. Courier never shipped. The design and interaction research from that project is visible in Surface devices and in aspects of OneNote’s development. Microsoft got years of thinking about stylus interaction and split-screen workflows out of a product that never saw a retail shelf.
Amazon’s pattern is more aggressive. They have launched and killed products at a rate that would look like dysfunction in most companies: Fire Phone, the Kindle Fire tablets’ many pivots, Alexa features that came and went. What looks like product chaos from outside is, inside Amazon’s model, a deliberate process of building things to find out what the real constraints are. The Fire Phone failed as a phone and as a platform, but the computer vision work that powered its Firefly feature eventually fed into Amazon’s visual search capabilities and contributed to the technology stack behind Amazon Go stores.
The pattern holds across smaller companies too. Slack began as a game called Glitch. The game failed, but the internal communication tool the team built to coordinate their work became Slack. Stewart Butterfield didn’t set out to build a messaging platform by pretending to build a game, but the failure of one project created the conditions for discovering what the next one should be.
What This Means
The lesson is not that you should build products you expect to fail. It’s that the right unit of analysis is rarely the product itself.
When Google evaluated whether to fund Wave, the question wasn’t only “will this become a successful communication product.” A more complete version of that question was “what will we know, and what will we have built, when this is over.” If the answer to the second part is valuable regardless of what happens to the product, the calculus changes.
This is genuinely hard to execute. It requires organizational honesty about what you’re actually trying to learn, which means being honest that you’re not sure the product will work. It requires tracking outcomes at the engineering and knowledge level, not just at the revenue level. And it requires leadership willing to call a project successful even when the product gets shut down, which is psychologically difficult and politically complicated inside most companies.
The companies that do this well tend to have a few things in common. They separate the product decision from the engineering investment decision explicitly. They staff experimental projects with people who are genuinely excited by the research question, not just by the prospect of launching something. And they have a deliberate process for extracting what was learned when a project ends, rather than letting the knowledge walk out the door with the team.
Google Wave looked like a cautionary tale about overreach. Look at it differently: a team built something that advanced the state of distributed systems engineering, trained a generation of engineers in real-time collaboration infrastructure, and directly enabled technology that hundreds of millions of people now use daily. The product is gone. The work isn’t.
When a tech company builds something it knows might become obsolete quickly, the question worth asking isn’t whether they miscalculated. It’s what they were actually trying to find out.
