Enterprise Software Innovator’s Dilemma
In his classical book The Innovator’s Dilemma, author Clayton M. Christensen introduced a framework for analyzing disruptive technological changes. The framework is based on four principles, as follows:
- Companies Depend on Customers and Investors for Resources.
- Small Markets Don’t Solve the Growth Needs of Large Companies
- Market that Don’t Exist Can’t be Analyzed
- The Technology Supply May not Equal Market Demand
Christensen illustrates how the four principles apply to computers, retailing, pharmaceuticals, automobiles and steel at various critical junctures along the road. In the software industry, Netscape’s web browser technology is an enlightening example of disruptive technology in action.
Enterprise Software Innovator’s Dilemma
The key point this charts gets across is that Open Source Software is becoming “good enough”. It has already met or will soon be meeting the minimum requirements of the enterprise customer. By so doing, Open Source Software will steadily gain ground from traditional enterprise software vendors.
Strategic Implications for the Incumbent
The maturation of Open Source Software forces incumbent software vendors to seek differentiation for their proprietary products. Such differentiation usually attempts to follow one or more of the following three patterns:
- Strategy of fear, uncertainty and doubt (FUD), portraying open source products and the communities behind them as not quite appropriate for mission critical applications. As the open source community has been tackling more complicated problems and producing increasingly sophisticated products, the FUD strategy has lost much of its effectiveness.
- Functional differentiation through features that are not available in open source products. This kind of differentiation loses much of its effectiveness once the “good enough” open source software line in the chart above intersects with the enterprise customer requirements line (the purple line in the chart). The extra features might indeed be included in the proprietary software, but the incremental value to the customer diminishes.
- Customizing proprietary software offerings to the particular requirements of top customers. This differentiation stratergy is discussed in the next section.
Given the ineffectiveness of the first two strategies to deal with Open Source, various incumbent enterprise software vendors try to protect their business by way of customizing their vanilla offerings to the particular environments, needs and use patterns of their top customers. Such customization is typically done through professional services engagements for which the customer usually pays. Under this business design, IT service revenues – professional services as well as customer support – often become more important than product revenues. The attach rate – the ratio of service revenues to product revenues tends to hover in the 100- 400% range. In other words, for every dollar a sales rep brings in, in the form of product revenue, he is expected (and often goaled) to bring as much as one to four dollars in service revenues.
Although a high attach rate might be attractive from a revenue stream perspective, it is counter strategic on three critical accounts:
- It completely distorts the economics of the product – a $1 product could for most practical purposes cost $2-5. Readers of the Customer Intimacy post in this blog might recall the characterization given by Crawford and Mathews to Consumer Underworld relationship between vendor and customer: “Be inconsistent, unclear, or misleading in your pricing”.
- It accentuates the customer frustration with the enterprise software model, tilting the balance further in favor of Open Source Software. IT services are seen for what they often are – complementary business to unsatisfactory enterprise software.
- The attach rate dives like a rock in difficult economic times such as the current macro-economic crisis. The phenomenon is described in the recent MGI Research article on the subject.
Agile Based Market-of-One
Hyper-productive Agile teams are sure-footed in moving requirements back and forth between release and backlog. This flexibility in changing the release contents quickly can be channeled toward customizing software to the needs of top customers straight from the R&D lab. Instead of doing it through professional services, R&D tailors custom releases. In other words, the enterprise software vendor produces markets of one in an efficient manner through Agile methods. If these efficiencies are passed on to the customer, the customer-vendor relation with respect to price could be transformed from Consumer Underworld all the way to Customer seeks the Company.
Although the development of market of one software through Agile methods in the lab can be quite effective, its distribution, deployment and subsequent operation in the customer environment need to be equally efficient. The “containerization”, distribution and provisioning of the output of hyper-productive Agile teams enables the achievement of end-to-end agility. This topic will be explored in forthcoming posts with special emphasis on three important business aspects, as follows: