Skip to main content

Surviving Disruptive Innovation

Steve Denning recently wrote that disruptive innovation is a disease which has destroyed company after company. A number of comments challenged his use of the word "disease." What is a disruptive innovation? Is it a disease, are you getting it, and what can you do about it?

The term disruptive innovation was coined by Clayton Christensen in his book 'The Innovator's Dilemma.' A disruptive innovation occurs when a new technology is developed that is lower cost and qualitatively inferior to existing approaches -- measured along the criteria of the existing market -- but offers other unique advantages to a new market. The new technology innovates faster than the established technology and eventually replaces the old technology at a lower cost, destroying the established players.

So calling the problem a "disease" is pretty close to the mark. The disease is not disruptive innovation per se, but the inability of established companies to react to it properly. Perhaps calling the "Disruptive Innovation Syndrome" would be a better word.

I have been in the IT business long enough to remember:
  • Minicomputers displacing mainframes to the stratosphere
  • Unix Workstations displacing minicomputers and forcing them out of existence
  • Intel PCs doing the same to UNIX workstations
  • Linux/Intel Servers doing the same to UNIX servers
and the list goes on. Today were can observe
  • SSDs are starting to displace hard disk drives
  • Tablets are displacing netbooks
For an established player, there are many challenges to adopting a disruptive technology:
  1. Innovative ideas originate at the lowest levels of the organization. Without an innovation culture, these ideas do not filter up to the top-level decision makers.
  2. New, low-cost technologies do not have an obvious market. Getting a go from top management to invest is difficult due to the risk and uncertainty of a small, new market.
  3. The new technology is unlikely to contribute significantly to the bottom line or growth of a large organization in the first years after introduction.
  4. Investment decisions are not made just once at the top, but on a daily basis by middle management over the life of the project. It's called 'allocating resources' and established customers with well known needs are a lower risk than uncertain new markets. So products for established customers get the best resources.
  5. The company's marketing "value network", i.e. its sales channels, marketing approach, and cost-structure are oriented toward existing customers. A company often literally does not know how to identify new customers or how to sell to new markets. Because margins and volumes are low, it is not financially interesting to do so.
So most companies simply choose not enter disruptive markets. The task is too daunting! And in the few cases that they do, it is very difficult road and most attempts are not successful.

What does it take to combat this syndrome?

Christensen argues that the technology itself is not the problem. It's the value network around the company which traps the company into its business model. The most successful approach he has observed is creating new business units which are independent of the existing business units and proportional in size to the target markets. IBM took this approach launching their PC business -- and went on to lose the market when it brought the PC division back into the fold, building closed, IBM-only devices which were slower and more expensive than their competition.

Apple takes a variation of this approach due to the extreme secrecy within the organization. Apple behaves like multiple start-ups which are in many ways unaware of each other, preventing much politics between the departments.

Steve Denning argues that companies need to have much more room for innovation. They need to adopt a culture of continuous innovation. The focus on the bottom line is counterproductive in the face of disruptive innovation.

What should you do? I don't believe these approaches are mutually exclusive. If you emphasize creating happy customers over the bottom line, then you know there are times to develop new customers and that a short term drop in profitability is a small price to pay for the long term survival and growth of the the company.

You need to create space to explore disruptive technologies. You need to recognize that much learning is involved and some attempts may fail. You need to identify new markets and new marketing approaches. You need to accept that the new approach will initially have lower volumes and probably always will have lower margins than your mature, existing products.

Once you decide that one product is a potential winner, you need to ensure focus. This means shielding the people and budgets from the pressures of your mature high-volume products. If you say 'A', and expect to get to 'Z', then you need to say, B, C, D, etc. until you get to Z. So if you are going to develop a disruptive product, you need to have top people working on it and you may not pull them off the new product development to support your cash cow.

Does the new venture have to be a separate business unit? A priori no, but there is a lot of practical experience which suggests this is a good idea.


Popular posts from this blog

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

The team reports to the Scrum Master at the Daily ScrumPeople wait for instructions from the Scrum MasterTeam members don't hold each other responsible [for their commitments]The same impediment comes up twice"That's the way it is" => resignation"I" instead of "We"Flip charts are lonelyCulture of conflict-avoidanceDecisions processes are unclear, nor are they discussedPersonal goals are more important than team goals
To this list I would add my a couple of my favorites:
you don't see a triangle on the task board (not working according prioritization of stories)after the daily Scrum, people return directly to their desks (no collaboration)there are a least as many stories in progress as team members (no pairing)
P.S. You can join the …