Why Great Technology Isn’t Always Enough

By Ian Hopkins, Chief Commercial Officer

Having ideas is easy. Deploying them in a practical, safe and cost-effective way is rather harder.

I've spent much of my career around new technologies. While we naturally focus on whether the technology itself works, that's often only part of the challenge. Some very good technologies fail for reasons that have surprisingly little to do with the original idea. Making the technology work is important, but making everything around it work is equally so.

There are six areas which, in my experience, businesses consistently underestimate.

Mastering change

Humans naturally resist change, largely because change has an unfortunate habit of making working life seem harder, at least initially. New processes need to be learnt, established ways of working are challenged, and people are asked to abandon something familiar for something new. As a result, some of the best ideas can be stifled by resistance to change long before they've had the opportunity to demonstrate their real value.

Deploying new technology successfully therefore requires a mastery of change. It isn't enough to have the idea; you have to create an environment in which creativity can thrive, and change isn't allowed to become a barrier. For most established businesses, that's a significant cultural challenge and shift.

A start-up should have an advantage here. There isn't a supertanker of embedded culture that has to be slowly turned. You can challenge established thinking, move quickly and create the environment around the technology rather than trying to force the technology into decades of established behaviour. That advantage shouldn't be underestimated.

Making it work is only half the battle

Once you've made something work, you then have to make it qualify. What does that actually mean?

First, there's commercial qualification. Will the technology shift the incumbent way of doing things? Does it offer an advantage in cost, quality, time or sustainability, or some combination of them? A technology may be clever, but it has to offer a compelling enough reason for somebody to use it.

Then there's statutory qualification. Will it actually be allowed to operate? Does it meet the necessary codes, regulations and approvals for its target environments and geographies?

There can be a substantial difference between proving that something works and proving that it can be deployed. Both matter.

Knowing when to stop

Then we come to risk. Commercially, where does the spending trajectory cross the viability threshold? When do you stop a particular course, admit defeat and move on, rather than continuing to pump money into it in the hope of the breakthrough?

It's one of the hardest judgements in developing new technology. Stop too soon, and you might walk away just before the breakthrough; keep going for too long and determination can become very expensive stubbornness.

There is also physical, or product, risk. Can the technology ever be made safe? If it can, will it be too costly to make it safe? At some point, technical possibility has to meet commercial reality, and knowing where that point sits isn't always obvious.

Are your suppliers on the bus

Don't underestimate the need to bring the supply chain along with you. 

Making a prototype is one thing; scaling it is quite another. Components need to be available, suppliers need to be capable of supporting you, quality has to be repeatable, and the economics have to continue to make sense as volumes increase. The question quickly moves from "Can we make it?" to "Can we keep making it? Can we make enough of it? Is there adequate capacity and competition in the supply chain?"

The supply chain may not be the most exciting part of developing a great technology, but neglect it, and it can very quickly become your biggest barrier.

You need champions

In a world where change has a habit of being feared, you need internal champions. These are the people who relish each day's problems as they arise, who are perhaps slightly uncomfortable when things are going too well, and who see a seemingly insurmountable obstacle as something to attack rather than a reason to stop.

There will be plenty of those obstacles between an idea and a great technology. Internal champions fuel strong teams, keeping them enthusiastic and energetic as they work through obstacles, maintaining momentum when the original excitement has worn off, and the difficult reality of implementation has arrived.

Technology needs clever people, but successful technology also needs people who refuse to let the problems win.

How long is a piece of string?

The only certainty with new technology is that your first guess at the timeline to readiness will be wrong. You'll rework it, and it will still be wrong. It may well remain wrong right up until the day of launch, at which point you'll look back and understand all the things that happened along the way and why you could never have forecast the date correctly in the first place.

But that doesn't mean you shouldn't plan. You can model effectively and, importantly, recognise timescale as an output of the development process rather than simply an input.

That doesn't mean abandoning ambitious goals either. Set them, build the plan and then keep plugging new information back into it as the technology develops and adjust accordingly. Some things happen surprisingly quickly; others are unfathomably slow. That's simply the nature of doing something that hasn't been done before.

Great technology isn't enough

None of this makes the technology itself any less important. Without something that works and delivers genuine value, there isn't much to commercialise in the first place. But that's the starting point, not the finishing line.

Great technologies have to survive change, qualify commercially and technically, navigate risk, build a supply chain, find their internal champions and somehow accommodate a timescale that refuses to behave itself.

Perhaps that's why truly successful innovation is so difficult. Having the idea is the easy bit.



Eloise Stanley