Within the engineering and environment sectors, innovation can be a rather enigmatic concept. I find that there are plenty of people who make hay from this misunderstanding so this blog is all about ripping the jargon out and describing how we make useful things in plain English.
My aim is to get as close as possible to XKCD’s rule of “explaining only using the ten hundred words people use most often” whilst still writing concisely. I was struck by how brilliant this was on their Up Goer 5 comic but I doubt this blog quite hits that mark. But hey, at least it’s not riddled with jargon either.
Innovation is about people not technology
As a consultant you’re asked to provide a solution and technology is a useful aspect of this. But to create a useful innovation you first need to understand the problem that is being solved and who is involved in solving it.
Engineers and scientists are taught to solve problems based on reasoning. Where physical relationships are known we use deductive reasoning to calculate a solution, this is how we design buildings that stand up. Where correlations are estimated we induce a realistic conclusion across a range of scenarios, this is how we predict and prepare for flooding.
Innovation is less about physical relationships and more about people relationships. When you combine two areas of engineering to get an innovative product or service it’s the people that spot the innovation, not the numbers. But to understand whether it’s a useful product requires you to understand whether it would be valuable to other people.
This requires assumption and exploration using abductive reasoning. Something that engineers and scientists are not initially comfortable with but really enjoy once they have the space to explore.
Everybody is an expert of their own experience, so you can’t design solutions for other people without asking them questions. So the most rewarding part of designing a new product or service is learning about other people’s areas of expertise.
Collaborate to define problems then solutions
Before I worked at Royal HaskoningDHV I helped develop affordable sanitation businesses Uganda and then in Ghana. Most of the time, whenever we hit a problem there wasn’t an obvious solution or noted expert to help us, so we had to work out who to ask. If you do this you’ll found that people are surprisingly happy to collaborate when you have a genuine desire to do something good. Especially when it’s combined with a potential to create something useful for them.
If we wanted to know what challenges pit latrine emptiers (yes that’s a business sector with a huge market) faced, we spent time with them following what they did and noting where their biggest challenges were. Then we developed and tested possible solutions with them.
If we wanted to know how people imported toilets we went to the plumbing district of Kampala. We asked the store holders how they imported things and what problems they had importing them. Then we set about figuring out how we could overcome these challenges.
When you’re working out what the problem really is and what the solution may be, you’ll make assumptions. The trick is to recognise what your assumptions are and then how to test them. In the early days, you can validate assumptions mainly by asking people without the need for costly models or prototypes. This allows you to quickly explore a range of ideas at low cost until you find one that sticks.
It’s no different if you’re considering digital solutions in the business to business arena. First you need to understand the problem by asking a variety of stakeholders and specialists. Once you’ve got some clear problems you need to ask data scientists if it can be solved using data and software developers how best to build your solution. All of these people speak in different jargon!
How do you get your idea off the ground?
Few people demonstrate how to do this better than Richard Browning of Gravity Industries (see video). He starts with a metal tube, a mop buck and a gas turbine on his arm. That worked, so he kept on going. Iteratively building on what had gone before until he developed a commercially viable jet suit.
Similarly (in a previous role) when developing solutions to the one of the most underestimated challenges in developing countries, household sanitation, we knew that we needed to prototype and test quickly. In Uganda we first mapped the sanitation value chain which led us to defining challenges in enabling each link in the chain. Things like, how do you pump material below a certain depth or with a certain viscosity only using a hand pump? Or, how do you test pumps safely and effectively on material that is highly variable?
Defining problems opened up the solution space and enabled creativity.
We identified fabricators to build simple pumps with us and then subsidised micro-entrepreneurs to test them in real life. Materials and labour were relatively cheap so this was an affordable approach but it was smelly and somewhat erratic.
Realising that we needed to standardise the testing a bit I collaborated with a researcher at the University of Cambridge who had developed a synthetic sludge using compost and kaolin clay. We reproduced this in Uganda with available material and created a testing facility. The team then collaborated with similar companies from Kenya and Rwanda who were testing their pumps in the facility we created before testing them on real pits. Gradually building on what was learnt until they developed the Sanitation Solutions Group.
But prototyping doesn’t need to be physical, just tangible.
At Royal HaskoningDHV we have a simple approach to prototyping that starts with an Idea Napkin. This fleshes out the idea, describes the problem and the solution. With this we can start validating whether or not the idea is feasible, building on the elements that work and quickly discarding the elements that don’t work.
Iteratively prototyping in this way will allow you to quickly find the problem that is most valuable to the people you are designing for. It gives your idea body and makes it tangible so that you can talk about it in real terms. Rather than ringing a friendly client and saying, “Hey can I come to talk to you about the digital innovation whizzy thing we’ve cooked up?” You can call your client and say, “I’ve recognised a challenge with [insert headache here]. Would you like to see how we could solve that together?”
Once you’re sure that you’ve got something that would potentially work and be valuable to somebody else, then you can start spending time and money on a physical (or digital) prototype. The first one could be as simple an interactive slide deck to show the journey through the service or a simple model to show what it would look like. And I strongly recommend you don’t spend too much time or money until you’ve built, tested and validated those early prototypes. Otherwise you could build something nobody wants to use and you’ve wasted all your money. This could bring your idea back down with a bump!
