Include Business Design in Innovation

Somik Raha

Somik Raha

11-07-11

In 2010, one of the best innovations in messaging and collaboration, Google Wave, was shuttered by Google. Google concluded that the product did not have the adoption rates they were looking for, and decided to give the code away to the open source community. It was a bad outcome for Google and Urs Hölzle, Senior VP of Operations at Google, labeled it a failure in Aug 2010, using this criteria: “Wave has not seen the user adoption we would have liked.” This was barely three months after the chief designer of Google Wave, Lars Rasmussen, blogged on the Huffington Post that Wave had demonstrated real business value, and had finally been declared open to the public. Pulling the plug on a product that fails to demonstrate traction may be justified as the application of the principle of not throwing good money after bad, but to me, the debacle of Google Wave is much more than a technology failure. It is the failure of Google, like most other companies, to include business strategy in product design.

The mantra of “if we build it, they will come” is only half the story. Going the last mile to understand and remove our user’s adoption hurdles is just as important, or “a miss is as good as a mile.” That is where business strategy exploration comes in. By business strategy, I do not mean drowning a team’s creativity through reams of speculative documents that no one wants to write or read. I mean instead an agile mindset where innovation teams explore the factors that drive value in product innovation, understand how these factors combine, and assess the uncertainty around these factors in order to prioritize their technology experimentation on the factors that really matter. Such a process allows the team to lay bare their assumptions and challenge them, in order to prepare for contingencies where their assumptions may be wrong.

Google, with its focus on customer use and data, goes half way, and produces products that people like.  Google Wave was loved by many users. However, a cool product and loyal customers are necessary, but not sufficient for success.  What Google missed was innovation around the business design.

From a user’s point of view, the core of Google Wave was a win.  I loved how easily I could hold discussions with others, both in real-time and offline. But it failed to fit into my broader context, clinging to the incredibly ambitious notion of replacing email.  What stopped me from using this lovely product was a lack of even basic integration (read notifications) with my email. Just as Fedex has not replaced postal mail, but complements it by using the same postal address for delivery, Google Wave should have shipped with email notifications based on user preferences right from the beginning. Perhaps a day might come when I would prefer to keep both my email and my waves open in separate browser tabs. But to get to that goal, there had to be stepping stones. Enough people may have complained about this and the product finally included email notifications in March 2010, five months before Google pulled the plug on it.

Simple notifications were not enough though. If the assumption was that people would find Google Wave so compelling that they’d stop using email, the decision to ignore tighter integration with email can be understood. But what if that assumption was wrong? Where did that assumption come from? We get some clues on this from Rasmussen’s HuffPo blog:

To share a few stories: Deloitte’s As One project team greatly accelerated productivity by using Wave in place of email. Lyn and Line use Wave to coordinate their software coding, Clear Channel Radio coordinates ad campaigns, a language class writes Latin poetry, a systems programmer runs his Web business, a group of artists teach virtual art classes, and a group of students write academic papers, all using Google Wave. Gina Trapani and Adam Pash used Wave to coordinate writing their book about Wave.

These testimonials are from individuals collaborating on a specific project, who have confirmed that they’ve found Google Wave useful to work together on a project. Not a single one of these champions claimed that they had used Google Wave to replace their primary mode of communication with the rest of the world. Google also seemed impervious to the default positioning of Wave as an email replacement, notwithstanding Rasmussen’s clear acknowledgment of the opposite:

It is clear that Google Wave’s early sweetspot lies with groups of people collaborating on specific projects.

Google had clear evidence that people working on projects would be happy to keep logging into Google Wave as their primary communication platform, while using email separately. The enthusiasm of early adopters may have blinded the product team into believing that such switching was not a significant burden, as the bravery of early adopters is often not representative of the larger population. And this is where Google Wave may have had a different and profitable future by defining development not as delivery of working code, but as delivery of a marketable business asset. 

To deliver a marketable business asset, one has to account for learning along the way. A powerful way to admit the importance of learning is to develop “Learning Plans” in our development strategy. What might have been a useful learning plan for Google to guide development? Here is an example:

A learning plan like this involves laying out proof points that help us test our assumptions. The proof points are responses to the question, “if I had to mortgage my house to fund this product, what proof do I need to see along the way that would reassure me that this is a good idea?”  Proof points not only help us with go/no-go decisions, they also help us work backwards to create important relationships with customers/users and nurture ecosystems that are needed for our products to reach users and deliver value. Good learning plans should be tied in to option development, which involve investing enough to have the freedom to change course quickly based on what we learn. Ignoring option development leaves us with an all-or-nothing mindset which is not wise for massive business bets, and is an invitation for internal politics to prevail over value-based decision-making. Google is just an example here, but this movie keeps playing with the latest casualty being Netflix’s CEO who put all his eggs in one basket and ended up with egg on his face. The attempt to get rid of the DVD business resulted in a more painful user experience and a massive flight of users, leading to a public retraction of the move. A clue to what may have led to such a blunder may be found in this quote from Businessweek:

“At Netflix (NFLX), new hires are drilled in Chief Executive Officer Reed Hastings’ guiding principles. Avoid “barnacles” that can slow down a fast-growing business, Hastings advises newcomers. Make tough decisions without agonizing and focus on great results rather than process, go his dictums, which are posted on the video service’s corporate site.”

It is easy to go too far in giving up on the process of learning about business requirements (including technology, customer and business design) and focusing instead on “results.” This false dichotomy between process and results is created by those who don’t realize that the path to great results is not through process or passion alone but a balanced combination of both. Without passion, a process has no life and will only serve to stifle creativity and lead to a lifeless and suffocating organization. Without a process that protects against our shortcomings and biases, passion can lead us away from our goal to be useful to others, taking us quickly up a cliff only to have a grand fall.

A great example of how passion and process combine comes from Apple. The iPod, by itself, would just have been a cool gizmo. What made the iPod truly compelling is the ecosystem in which it operates – iTunes, which is really a business strategy innovation that involved setting up several media partnerships that enabled legal downloading of music. To pull this off, a team had to be thinking about the entire ecosystem, and not just a single product innovation. Systems thinking of this kind is what a process around strategy can enforce as a discipline, to help bring great ideas to the market in a form from which many can benefit.

The irony is that Google itself is built on a business design innovation around advertising. It took a courageous journey to go from search-engine technology to the powerhouse that Google has become. The lesson learned from the success and failure of Google Wave: include business design as a key part of your innovation process.

Related Links
F&S Best Practice Guidebook: Based on work done for HP’s Printer Division, this guidebook shares best practices that include creating business design learning plans (see page 5)
Front End of Innovation Blog

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Subscribe







Get Social