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!