Links

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!

This spring I had the pleasure of lecturing at MIT in two different courses on innovation - both taught by the always fascinating Eric Von Hippel. The first was to a group of MBA students and Sloan Fellows at the MIT Sloan School of Management as part of a course entitled, “Innovation in the Internet Age: Emerging Trends“. The purpose of my lecture was to provide a real-world example of a company struggling to rapidly evolve an innovative web platform using as a case study, Knowligent’s IP Portfolio software for managing innovation and intellectual property.

In my session, I briefly recounted Knowligent’s experiences innovating a complex enterprise system and the way that customers essentially negotiate to introduce their ideas into the design of the product. Eric’s objective for bringing me in to lecture was to provide proof for his overarching thesis - which is essentially that a lot of innovation comes from end-users, and companies that embrace this reality are better off for it. Of course this is absolutely true, and Eric has become a sort of collector of cases and evidence in support of this “Open Innovation” idea. The students were very intellectually engaged and a lively discussion ensued over the basic issue of whether customer-driven ideas can be trusted to lead a company’s innovation in the right direction. It was typical of MIT - very probing, questioning, and spirited - and it was a lot of fun! A few things came out of the discussion and my subsequent pondering after that I feel are particularly interesting and useful…

1. Enterprise software is actually a pretty good example of an industry where innovation has been heavily user-driven. Many if not most business software companies originated out of home-grown IT projects within companies for from corporate “wish lists”. Even after a project has spun-out, the vendor tends to be dependent on a small group of corporate customers for at least the first few years of their development, and these customers can exercise enormous power over the development trajectory of the product.

2. However, although a majority of ideas for new features and capabilities originate with end-users, only a small subset tend to have broad appeal. That is, customers can quite easily produce a large volume of ideas for new functions mostly because they have so many jobs to do. But these features make for complex, and usually expensive, software. If the vendor isn’t vigilant in controlling the code base, this significantly restricts the appeal of the software and I think that this can be a very dangerous trap for a software company to fall into.

3. More importantly, it is arguable that these user-driven features aren’t really “innovation” at all. Just because a customer demands certain features doesn’t mean that they are innovating for you. Much of the time this is really just “invention” (as distinct from “innovation”), and often it isn’t even that. The danger is that companies may come to think that they are innovating because they are adding a lot of new “features” to their products.

4. Enterprise/business software seems at the moment also to be a good example of another interesting theory of innovation - namely Clayton Christensen’s idea of “Disruptive Innovation”. Disruption usually happens when new products are introduced that actually offer less of the kind of functionality traditionally demanded by the existing (and influential) customers. So, running counter to the urge to create customer-driven “bloat-ware” is an urge to create software that is actually less functional but which may be easier and cheaper to deliver and use and is frequently innovative in other dimensions. For examples, I point to Google Docs, 37 Signals, and Mint.com as just a few of my personal favorites demonstrating this kind of disruptive innovation in the world of software. In other words, the current tide of “innovation” in software seems to be moving in the opposite direction than the one that big and influential enterprise customers may want to go. As the theory predicts, over time these offerings will likely become ever more functional and ultimately displace their predecessors. It’s this changing of the dimension of innovation that makes disruptive innovation so powerful.

The question that comes out of all this is whether your biggest and most influential customers are likely to lead you in a direction that makes you more or less innovative. My own feeling and experience (from the world of management software) is that involving customers and end-users in driving your product design usually makes you more inventive but can make your products less innovative overall. It is probably true that this will be different in other sectors. However, at the very least this supports the idea that there is a need to carefully evaluate the direction your customer input is driving you and to distinguish between “inventiveness” and “innovation”.