If you are an innovation manager, CIO or involved in innovation in your organization, I wouldn’t be surprised to hear from you that one of your bigger challenges concerns prioritizing your innovation projects or ideas. When we were shaping our innovation offering at AE and ‘got out of the building’ (eating our own dogfood) to ask people like you about what keeps them up at night, this topic has come up in most of the interviews we had.
Since we are curious people and passionate about solving problems, we challenged ourselves to find a solution aligned with our innovative mindset and the principles we believe in.
In search of this solution, we discovered Itamar Gilad’s blog posts about this topic. In these posts, he explains how to solve this complicated problem in an easy and straightforward way. Even more so when we found out that we had already been following this way of working when executing our innovation projects. When time & resources are limited, it’s all about making the right choices.
In this blog post, we’ll explain how to make those choices when you need to decide on which ideas to pursue and which to abandon.
With the technique of GIST planning, you learn how to define your roadmap in a way that is in line with the agile mindset crucial in innovation projects.
G = Goal
What strategic goal are you pursuing?
A goal should be expressed as an objective and a key result. By making these a sharp and measurable as possible, you end up with a tangible target that people can commit to.
I = Ideas
Give people a goal and they’ll come up with ideas to reach them. That’s what this is about.
Please keep in mind that it’s extremely hard to determine if an idea is good or bad based on what you and your management team are thinking. If you recognize this behavior, you are guilty of ‘God-like thinking’. A god does not ask his subjects for their opinion but imposes his own.
You could argue that a god is omniscient and does not need to go outside the building to check if his assumption is correct. A manager, however, is not omniscient. This means that you DO need to get out of the building to become confident about the fact that your idea is the right one to pursue.
In the second technique we will tell you more about ICE scores which are a hands-on way to prioritize ideas in an objective and effective way.
S = Step projects
Realizing an idea (or any change for that matter) is done by executing a project.
Instead of defining a project that aims to realize the full implementation, you should try to define small (step) projects that can be executed chronologically and have as goal to increase your confidence (by updating your ICE score).
T = Tasks
This part probably doesn’t need a lot of explanation.
Tasks are the things you need to do to realize a step project. Think Kanban style follow up. Anyone familiar with agile methodologies will know what we’re talking about here. If not, let us know, because we can help.
If you have a bunch of ideas that all promise to some extent to realize a strategic goal, you’ll want to know which ones to pursue and which ones not to pursue. To compare the different ideas, you can score them with the ICE methodology:
ICE score = Impact * Confidence * Ease
When you implement the concept of ICE scores, you will be able to prioritize ideas or pursue them in parallel projects so you can learn as fast as possible which ideas are more likely to lead to success.
Let’s start by defining each aspect of the ICE score.
Impact is an estimate of how much the idea will help in realizing your goal or will positively impact the key metrics you are pursuing.
How confident are we in the idea? You can be confident about how difficult it would be to implement the idea (complex vs. easy), but by ‘confident’ we mean the confidence about the product-market fit.
When you want to measure the level of confidence in your project, you could start with the confidence of implementation effort, how easy you estimate the effort of implementation will be, but we believe that confidence should primarily be built in the product/market fit area. You must assure that you are building something that enough people see as a problem worth solving and that enough people show willingness to pay for your solution.
The confidence level can be defined pretty objectively. You can define your own scores and definitions, but we think this image will give you a head start.
This stands for the ease of implementation. The higher the score, the easier the implementation will be. You can define your own scale. We made a proposal for a customer based on the estimated required IT budget to develop the idea. The lower the estimated number of days, the higher the score.
ICE scores are not static, they evolve with each learning iteration
Each element of the ICE score should be within a 1 to 10 range. By multiplying the factors, you end up with an ICE score between 1 and 1000. It’s as easy as that. All you need now is a rhythm to update your scores. Our proposal is to do this after the execution of a step project, provided you have learned enough.
The following image illustrates how 2 ideas were executed in parallel and what the outcome was after 5 iterations.
After a first step project (which could be an online survey), you‘d expect that both options are equal. Only after the execution of a few additional experiments, it became clear that the “dashboard solution” was definitely the way to go.
Important note: don’t draw a conclusion too fast. Build the evidence you need to reduce the risk in the next phase of your product/service development.
Read the full story behind the graph above
And that’s it. We talked about one technique to defining your projects and a second to score them. These techniques aren’t new, I would especially like to thank Itamar Gilad for sharing his thoughts on these interesting challenges.
We’re anxious to hear about your experiences in your prioritizing innovation projects. If you have tried any of these techniques or have some questions on implementing them, fill in the form below! We would be happy to help.