Disruptive Technology
If thirty years of designing products has taught me anything, it is that customers only ever demand a slightly better version of what they have and know. Customers know their business – as it exists today – and they know how to use the tools and technologies they are offered, today.
Step changes in products, processes, business - and ultimately in our way of life – come from bold, visionary ideas that come when we tear off our blinkers and imagine how things could be, if only…
As the saying goes, “God created the world in just seven days – but he didn’t have an installed base”. This planet has colossal investments in the way we do business and live our lives today. That is not to say that there isn’t a better option out there. At the risk of being labelled politically incorrect – or even racist (as someone from Northern Ireland myself – hence claiming immunity from accusations of racism in favour of self-deprecation) - I recall an entry in a book of Irish jokes in which an Englishman asked for directions and was told:
“Well if I was going there I wouldn’t start from here!”
My most successful and innovative products to date have come about after learning about a requirement for some time and then imagining how I would solve the problem if none of the existing products, services or infrastructure existed and I was forced to start from scratch. The steps go like this...
First, clearly define and really understand what the underlying objectives of the product or service are. This should have nothing to do with how those objectives are currently addressed. It’s actually the toughest part of the exercise as the existing “experts” who live and breathe it are themselves blinkered by the current tools and methods hence find it difficult to articulate the true goals. Often one has to go several layers up through management to understand the real objectives – as opposed to the metrics that have been set by the various layers of management as proxies for these. Think, for example of a call centre. Talk to the call centre manager and he might tell you his goal is to handle as many calls as possible within his budget. Talk the CFO and he’ll tell you that he’d love that call centre to take no calls – as it only handles warranty claims!
That stage of the process is basically what this Chapter has been about up to now. I then investigate set out all of the available technologies, tools and building blocks. I look for parallels in other fields and try to understand what is available off-the-shelf, what just requires effort and what might require something more innovative.
Next, trends and timescales have to be taken into account. Everyone knows that Moore’s law describes the relentless increase of processing “bang per buck” – doubling every eighteen months or so. Data storage costs are dropping even faster. Labour, fuel and taxes are going the other way.
It’s then a matter of evaluating a few permutations of combinations of technology and effort – each of which gives a possible approach that could be taken and, crucially, the timescale in which it is delivered. It’s not actually when the first prototype or even the first field-deployment occurs that matters. Rather, it’s when is the steep slope of market adoption going to be. For it’s at that time that your solution has to be the “right” one. It mustn’t be based on technology or platforms that are going to be considered obsolete at that time – nor must they still be “bleeding edge”. Above all they must be cost effective.
Once I understand a couple of such scenarios, I then set out to tell a credible story. I have to be able to explain to someone what the new product or service looks and feels like. I’ll often go as far as writing a dummy user manual to see how well the concept hangs together. Working through these “use cases” puts flesh on the bones of the idea and exposes any holes in it. You'll find these “stories” in the next Chapter.