Last week we wrote about how companies often make the mistake of beginning an innovation project without clearly identifying the problem. Two of the main reasons this happens is that:
- The company starts with an idea (usually one that a senior manager likes) rather than really investigating the problem.
- Neglects to do (real) consumer testing.
But there are also two other common failures:
3. Even when companies think they have identified the problem, it’s not the actual problem.
Companies regularly approach us to help kick-start a product-building process and tell us why they want to do this. They present the problem and some first indications on how it could be solved. We have learned (the hard way) to never take this at face value.
If it is an internal company problem, it is important to start by understanding the company structure and culture, previous innovation initiatives and the business units that ran them. You have to understand how processes work and who is responsible for them, as this will help you getting insight into the actual problem.
Why is this important? Only if you know how things are done, who is responsible, and which intermediate stations exist within let’s say the production you can identify where the crux of the matter is.
In one of our banking & finance projects, for example, we discovered during the process that another innovation department had also created ideas for payment solutions. Afterwards, we naturally had to clarify any overlaps with this one, which slowed down the further innovation process. An in-depth analysis saves such experiences because the other unit could have been involved in the process immediately.
If it is an external customer problem, it is important to talk to as many of them as possible, so you can get enough detail about the customer’s negative experiences while using your product. Check all the data available to you. Interviews and data are very often the key to identifying both internal and external issues.
The first task is to question everything that might lead to the problem in order to find out what the real one is. If you don’t do this, you are very likely to take the wrong route, burning money and time that are scarce resources in innovation units.
4. Being too specific — or not specific enough — about what you plan to do about the problem.
Once the problem is identified, you have to be clear exactly what you want to do to address it. Many follow-up actions will involve team members with different backgrounds who were not involved from the beginning — and thus have not played a role in the problem identification.
You need to have a concrete, actionable and technically feasible problem description that can be read and understood by everyone. If it is too general, nobody knows where the process should begin. If it is too specific, there is no room for adjustments and adaptations. Additionally, from a technical point of view, if it is not feasible, the problem will leave the team members frustrated and unmotivated.
The Discovery Bootcamp fix
The Discovery Bootcamp has been our way to encourage companies to cut through the no-problem problem. It lasts three weeks and is conducted before each ideation or implementation phase. The purpose of all this is to be able to make informed decisions about whether or not a problem is worth solving or what it actually is. This process enables a structured and informed start in an innovation project and protects the company from wrongly investing money, unwanted products and furthermore a lack of in-house support.
In week one we start with a workshop series that allows us to get a deep-dive into the company. First we want to know how the company is set up, who runs which departments that are important to us, who reports to whom and so on. Secondly, are there already any innovation initiatives currently running and what can we learn from them? Thirdly and finally, it is necessary to go through the exact definition of the objectives again to get an overall picture of the project.
The banking sector project where we discovered another business unit working on the same kind of solution was a hard learning for us. But it led us to come up with this first part of the Bootcamp — taking time to identify everything that we need to succeed.
In week two and three we explore challenges within the company and start coming up with hypotheses to those challenges. When having those on the wall, we do in-depth research both as a team and individually, depending on the challenges, and conduct interviews with people that are affected by the challenge. Through both the interviews and the research we test the hypotheses to whether the problem is the right one or not.
In one project we had a use case for a payment service in the retail space and assumed that customers would need this solution to solve an identified problem. By conducting the research and the interviews we gained insights into what already exists, how customers, banks, retailers and suppliers of processors think about it and how we should then proceed.
We found out, for example, that customers were looking for a payment solution to solve an actual problem — but most of them didn’t want to download another app for this single purpose. So we ended up adapting the hypotheses and assumed problems. In this way we were getting closer to what we really needed to solve.
Very often you will also see, and we did in this case, that the overall problem has been identified but slight adaptions might be needed to better address it.
Last but not least, at the end of week 3 we put together a problem statement that is concrete, actionable and technically feasible. It is only then that you know where to start, and the project can begin.
Erik Muckenschnabel is an innovation consultant at Pioneers.io, the Austrian innovation consultancy.