There are many ways of running innovation processes and programmes. The following describes a broad approach — the result of many years, and many mistakes — that has been successful.
We think of the approach in three broad tracks: governance for how the work is controlled; measurement for how progress is tracked; and delivery for how the work itself is done. Often people concentrate on the last to the detriment of the first two; they’re all important.
We start with two important things:
- Whatever measurement you do — commercial performance, awareness, customer engagement, rank against competitors, participation in your company — always establish a baseline. It’s amazing how often people don’t do this, and it’s a shame because it means you miss out on credit for your achievements.
- When it comes to governance, recruitment is key: think hard about the right people in your organisation to get involved. You’ll want people who can help you to achieve your goals — “political hackers” who understand your organisation and how to unblock decisions — as well as evangelists. In many industries, compliance or regulatory teams are frequently seen as “no” people: getting them onto your team turns them into allies.
Then we get into the first of the three big stages — defining the challenge or problem. There are many ways to uncover problems. For example:
- Talking to and observing users to understand their problems and unmet needs (observing is key, and a specialist task — there is a big difference between what people do and what they say they do);
- Understanding the pressures and ambitions of stakeholders — leaders in your company, commercial clients and partners, subject matter experts;
- Carrying out analysis — for example, of operational or customer data, or of market behaviour;
- Talking to existing and potential partners. There’s a tendency to focus on start-ups in this category; take as broad a view as possible.
The most important lesson in this stage is: spend more time on the problem.
It’s usually faster and cheaper to do this than to go to the effort of designing and building things. If you want to do something innovative, you can take an existing problem and solve it a brand new way (good luck), or you can uncover a brand new problem that nobody has ever identified before and “merely” solve it.
There is a gate at this point because an important function of governance in innovation is to reject challenges that are not properly thought through. Don’t be afraid to insist on originality in the problem.
Once you have a challenge, you get into solving it.
This is a typical iterative process. We pull out initial concepts as a way of communicating the ambition of solution in a compelling way. This should not take long: it’s a useful first filter on possible approaches, and a good point to inject some competition into your process, with teams competing to get their concepts chosen.
Once into iterations, we distinguish three types of activity with three questions:
- If we have to ask, “Is this possible?”, do convincers — the smallest experiments we can to ensure feasibility. If you have any of these, best to do them first. The concept of minimum viable product or MVP often works counter to this; people start by building the easy bits. I prefer to think in terms of riskiest assumption tests or RATs.
- If we have to ask, “Do people understand/want this?”, do pilots. These are tests in the real world with real people. It’s important that we are not talking about focus groups: people must feel like they’re using a real product or service. Sometimes that can be done with an existing product or service. It can also be done by faking it, particularly for a small test.
- If we have to ask, “Will this work in our operational environment?”, do beta tests, in which a real product or service runs at a limited scale in some way (limited or opt-in distribution; limited geographic area etc.)
Not every project moves through all stages. We direct iterations based on what we need to test. A way of formalising this is to construct a value model for the concept right at the start, including — necessarily — substantial uncertainty in all aspects. Each iteration should be designed to reduce uncertainty as quickly and economically as possible — either to improve our confidence in the ultimate value or to encourage us to stop work on this concept.
The partnerships and funding box represents the need to think about how something will be operationalised at scale early on. Many companies have experimented with processes like these and created interesting prototypes, only to find that they are held up when it comes — later — to figuring out these details. Who should own it? Where should it sit? Out of whose budget will investment come? These questions may be resolvable; yet, substantial loss of momentum can be enough to kill a promising concept. Get this sort of thing buttoned down early, and involve the right people in the development.
There is no fixed formula for how long something spends in the exploratory, iterative phase; from a governance perspective it’s important for any project or programme to have a scale gate which defines the point at which to scale based on the measurement approach. For example, when expected ROI (the statistical use of “expected” — sum of probability × ROI) exceeds an agreed threshold.
Moving from exploratory to scaled operation is typically where something moves out of the domain of an “innovation process”. It’s important that the innovation activity continues to capture operating metrics in its measurement scheme, so that it can claim proper attribution for later success.
Finally, throughout any such work, communication is essential. Blogs and video are simple and effective. Openness is generally good: certainly within your organisation and, if possible, in public.