The way I see it disruptive innovation is an illusion to observers who have not had the same focus. From my experience that apparent disruptive innovation actually comes from companies who have invested and honed very tight, very frugal or cost effective product iterations on what is ultimately a predictable destination. In other words, to be truly innovative in a digital landscape you just need to be very efficient.
One of things that fascinates me about organisational change is how teams can refine their technology stacks to allow for painless, fail-fast model around new ideas – the kind of thing Eric Ries discusses in “The Lean Startup” but seems to be impossible when reflected back on your own organisation. For me that failure raises two questions:
- How do you target your innovation practices to achieve what appears to be at times at least, disruptive?
- Is disruptive innovation actually real?
Here’s the dilemma. The mecca for every large organisation is to have reliable operational structures that facilitate continuous product iteration. Roadmaps and strategy allow large organisations to predictably assign budgets. In the case of a previous employer, the BBC, constraints on where they should provide value to licence fee holders provide another set of rails from which it can be hard to divert. How do you innovate and continue to provide stable roadmaps with known costs. You need to make the two work together.
Innovation and the eye of the Beholder
I’d argue that disruptive innovation doesn’t actually exist. It might seem odd but I’ve come to this conclusion because of where I worked – in a team tasked with enabling processes to make disruptive innovation possible. Innovation is all in the eye of the beholder. What appears to come from nowhere is of course really just tight loops of product development where the team decide that the first release is suitably mature to ship. Companies who repeatedly appear to deliver ideas from “outside the box” are really very, very good at small, tight, iterative loops and above all, fundamentally understand how to extract the learning from every iteration and push it back into the next one. Maybe, innovation isn’t even in the technical domain? Consider.
YouTube as an example – To the public at large, YouTube appeared very much come from nowhere. In fact, anyone working within the video technology area at that time would tell you that the planets were starting to align in this world.
- Availability of lower cost hardware or provisioning
- A stable, high level set of client technologies to support distribution to 90% of the end- user market at very low cost
- Development of fast, good quality, low-cost codecs etc
None of this is innovative in terms of practice. Was the idea of having a location where users watch each others content innovative? No. Yet Youtube was a stroke of genius, purely because they did the one thing that no-one else had dared do. They allowed people to publish content on their site regardless of rights model and clearance of content, and by doing so, made themselves a target for an industry already bloodied and bruised by the onslaught of digital formats and copyright protection. This unflinching approach and self assurance that demand would force delivery of a working product to the masses, and not a lawsuit (thanks to Google) was the one in a million step. Pure guts. That was the innovation, right there. Just.That.Bit.
Innovation and efficiency
A constant criticism of large organisations is that people don’t need programmes to be creative or innovative. Teams will be innovative if left to their own devices. Whilst working in Sport at the BBC, I was as vocal on this as anyone. Later when I worked in BBC Connected Studio, we faced a similar barrage.
But, actually, I no longer think that’s right. One thing is for sure – if you don’t write code, you won’t ever move the needle. The trick is to move the needle as far as possible with the least possible effort, and this requires efficient and effective management of ideas.
In essence, you can think of like this … Making mistakes is fine (embrace failure etc), but making the same mistake twice isn’t. This is the critical Build/Measure/Learn mantra of Eric Ries. If you don’t do that learning bit, you are doomed, but if you get good at it – the technical process and the mindset required to make the leap as we saw in the YouTube example, you might just be able to pull stuff out the bag at a rate that will baffle your competitors. Most organisations have good ideas but very few can ship them.