The Agile Executive

Making Agile Work

Enterprise Software Innovator’s Dilemma

with 10 comments

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:

  1. Companies Depend on Customers and Investors for Resources.
  2. Small Markets Don’t Solve the Growth Needs of Large Companies
  3. Market that Don’t Exist Can’t be Analyzed
  4. 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

A couple of years ago, my colleague and friend Sebastian Hassinger characterized the state of affairs in enterprise software by the following chart a la Christensen:

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.

IT Services

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:

Written by israelgat

January 27, 2009 at 9:45 pm

10 Responses

Subscribe to comments with RSS.

  1. Very interesting and widens horizons.

    The info is very constructive

    Please continue it help to understand the process.

    Thanks L


    January 28, 2009 at 12:49 pm

  2. I am skeptical but intrigued, as I presume you’ll
    present some answers to what must be the obvious
    concerns about this Market of One concept, such as:

    * maintenance of customer-specific changes alongside future development in the code base. This just seems like a nightmare if you’re accumulating custom-build features into your code but trying to move all versions of your software forward (or am I misunderstanding the idea? Are these “custom release” features all developed in the main line of code?)

    * support issues when each customer could be running a distinct version of the software

    * what continuous integration looks like in this world

    * whether focusing on Markets of One and their desired features is the enemy of the kinds of innovation that could “raise the bar” and move that Customer Requirements line up.

    I know, this last point is trying to make the case for keeping focus on approach 2 in this article, of “functional differentiation” – which is claimed here to be less promising in today’s world of competing with OSS. Still, the title of this article implies
    an interest in innovation, so I’m wondering whether
    one can still pursue it while following this

    — Jamie

    Jamison Gray

    February 3, 2009 at 8:32 pm

    • Hi Jamison,

      The good points you bring up are discussed in my recent Cutter Consortium essay “To Release No More or To “Release” Always” Here is a quote from the essay:

      As an example, PatientKeeper maintains “…at least 45 releases in the field at any one time.” Using VPN technology, PatientKeeper “… try to get everyone on the latest release about once a year.”

      As Michael and I write in this blog about striking a balance between engineering considerations, market considerations and customer considerations, we will address additional aspects of market-of-one. Stay tuned…




      February 4, 2009 at 8:45 am

  3. […] requisite and turning a few heads. In the enterprise we are also seeing OpenSource as being ‘good enough‘ and I don’t mean that in a bad way, good enough is really important and is a definite […]

  4. […] a low-cost input for traditional enterprise software vendors are dire. As pointed out in the post Enterprise Software Innovator’s Dilemma, some low-cost input effects are already manifesting themselves through Open Source […]

  5. […] about the Innovator’s Dilemma in the enterprise software space comes from this blog post, Enterprise Software Innovator’s Dilemma. Existing vendors expand the functionality of their products, heavily relying on the requests of […]

  6. […] software companies, the impact of “good enough” Open Source Software should be assessed in conjunction with close examination of the market value to revenues ratio. […]

  7. […] was pointed out in Enterprise Software Innovator’s Dilemma that ”good enough” Open Source Software is inevitably becoming good enough. If you […]

  8. […] a comment » Readers of the posts Customer Intimacy and Enterprise Software Innovator’s Dilemma might recall two observations made in this […]

  9. […] Market-of-One […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: