Google’s Chrome is a Disruptive Threat

September 13th, 2008 Greg Daines Posted in Disruptive Innovation, Innovation, Software 3 Comments »

Ever since Google released its new browser, “Chrome” last week, it has been the subject of hot debate. People are arguing whether the world needs another browser, whether this new browser is any good, and whether or not this is really innovation. A very interesting post by Scott Anthony on his blog takes the position that Chrome shows signs of classic disruption: easier and faster to run web apps, open source, and free. Anthony makes the argument that Chrome is a disruptive threat not just to Microsoft’s now-dominant browser, Internet Explorer, but even to Microsoft’s other flaghsip products - Office and Windows.

This is much more serious statement than many realize. For some time a lot of people have been predicting that the web browser will supplant the traditional Operating System as the layer for which most applications will ultimately be designed. We now see that this vision has the very real potential of becoming reality. Companies such as Salesforce.com and many others have shown that industrial-strength applications can run in web browsers, and Google’s own applications which compete with Microsoft’s Office suite offer a tantalizing taste of what is to come.

But the browser itself has long been the limiting factor. Among the biggest problems with the current crop of browsers are their poor memory and process management. Sophisticated web apps can choke a browser, and the problems get worse when there are multiple windows and tabs open. Microsoft’s Internet Explorer which is used by 70% of the market has been particularly slow to evolve in this dimension and seems to have been spurred-on mostly by the competition - particularly Firefox. There is little doubt that IE wouldn’t have moved very far without the Firefox threat looming.

I think a lot of people have missed the point with Chrome. Google doesn’t really want to compete in the browser market. I believe that their intention is to move browser technology in the direction it wants to go - toward making browsers a more robust application platform. This is the reason that I would argue Chrome will ultimately turn out to be disruptive even if it never consolidates any substantial market share. Many have argued that Chrome’s new features will not be difficult for the market leaders such as IE and Firefox to adopt and that will obviate any demand for Chrome. I think that this is exactly what Google wants. They are lighting a fire under the IE development team. They may or may not want to be the new king of the browser hill - but they certainly want browsers to be capable of delivering the new generation of applications and services that they envision.

That’s why Chrome is not as disruptive of other browsers as it is of traditional software applications like Office and operating systems such as Windows and Macintosh OSX. When the browser becomes the platform of choice for application delivery, we will be able to get our software over the web, and the operating system I use (currently: Macintosh OSX by the way), will recede into the background. In fact, if I am getting my apps over the web, why should I pay a premium for a commercial OS at all when there are free alternatives that support a modern browser just fine. Chrome is disruptive without specifically needing to disrupt any particular product directly. This is because it is going to change the balance of power between traditional computing platforms and the web-based computing juggernaut on the horizon. I think Chrome will prove disruptive whether anyone uses it or not.

AddThis Social Bookmark Button

When Is Less Invention More or Less Innovation?

June 19th, 2008 Greg Daines Posted in Disruptive Innovation, Software No Comments »

I wanted to follow-up on the theme of my last posting by asking: when is less invention more or less innovation? One of the things that I referred to was the company 37 Signals. As you probably know, there has been a terrific debate about 37 Signals and their widely-publicized call to arms against feature complexity (eg. “Bloatware”) in software. Basically, they are the “less is more” poster child for the world of software. Probably the best example that I have found of this debate flowed out of a blog posting way back in 2006 by my friend Dharmesh Shah on his phenomenal blog: OnStartups.com.

The Debate: Basically the debate can be boiled down to this:

The 37 Signals school of thought is that the mere act of reducing features can add value to software for many if not most users, and is its own form of innovation.

The counter-argument articulated by Dharmesh is that most of the interesting problems that software can help solve aren’t simple enough to be solved by simple software. His argument is that software should be no more complex then is necessary to meet the need.

What vs. Who

I actually think that both “sides” in this debate are saying something true, and that the tension between them is actually artificial in that it is mostly based on another factor. As Dharmesh himself points out in his post, “Many can (and have) argued that nobody uses more than 20% of the features in Word. That’s likely true. The issue is that it is a different set of features for each user, and within that set, one or more features are very important.” So I think that the question is not how many features to offer, the correct question is how many people to offer the features to.

The example of Word (and a lot of other software from the past 20 years), is of a product that needed to fulfill the needs of most everyone and therefore had to include a lot of functionality to meet everyone’s needs. But this requirement is really driven by the business model which led to loading every conceivable capability into a single, gigantic product. When you look at any particular person or group, it is much easier to identify what my friend Clayton Christensen calls “jobs to be done“, and the features and capabilities that are needed naturally fall out of that. More importantly, using the “jobs to be done” concept clarifies which dimension of performance defines the correct innovation trajectory.

It’s the Business Model

I would argue that for 37 Signals and others in the new generation of Web 2.0 and Software as a Service (SaaS), what has changed isn’t really the philosophy - it’s the business model. These companies build and deploy software in a completely different way (as internet services) and into much more sophisticated and heterogeneous markets. The result is a different software business model with very different economics. It enables, and I would say even encourages, software companies to form solutions around much more homogeneous markets defined by common “jobs to be done” and a shared vision of the dimension of performance.

What this leads me to is the concept of “requisite complexity” which I first encountered many years ago while I was studying innovation at Cambridge University. The idea is that solutions will not be less complex than the problems they solve. I would hypothesize that neither side of the debate would disagree with this idea (I hope - anyone out there want to speak to this?).But, the only way to reconcile the very real conflict between these ideas is to understand that they represent different business models (eg. the traditional mass-market software application vs. jobs/market-specific software).

Many in the Web 2.0 world are very enthusiastic about Christensen’s “Disruptive Innovation” thesis because it appears to offer a roadmap for success. I think that they are right, and I am satisfied that the success of Salesforce.com is an example of classic disruption. But I also think that this new generation of software entrepreneurs would be wise to take another page out of Clayton’s book (literally!), and make sure that they understand and align their solutions with the “jobs” that their customers “hire” them to do.

So this may be a starting formula for software success right now:


identify the “jobs to be done”

(and understand what that “market” looks like”)

+

build solutions of “requisite complexity”
(not “less” or “more” - but “just right”!)

+

wrap them in the right business model
(and delivery mode etc.)

To me, Web 2.0 is really about a new business model for software, and not really about technology (though technology has been a key enabler). This helps explain the profusion of smaller, more specialized, software companies and the blurring of the lines between software “products” and “services”. My own company offers IP management software and represents this trend. As a specialized vendor, our solutions have come to be defined by a unique “jobs to be done” profile. Ultimately, our evolution toward the SaaS business model has been driven by the economics of serving these kinds of specialized markets. This model allows us to deploy many different versions or “flavors” of the product to address the need for requisite complexity for each “jobs to be done” profile - and make money. Said more simply: our objective is to profitably offer everyone with IP just the software they need to effectively manage their IP. Simple to say - difficult to do!

AddThis Social Bookmark Button