Before jumping into ANY innovation activities of any kind, particularly design thinking workshops and hackathons, it is prudent to run a ‘reverse hackathon’ first. Before I introduce what that is, let’s understand the context in which this idea lies.
The starting point of any innovation project is to develop a problem statement, nothing controversial there. But the critical shortcoming I usually encounter is that there is very little debate within an organisation, and even more importantly with customers or end users, whether the problem statement is in fact the right problem to solve. Quite often problem statements address a symptomatic vs root problem.
And in organisations, it is also important to understand what are the constraints to possible solutions. Startups on the other hand quite have an open canvas as they don’t have fixed resources to optimise. Their challenge is then to get funding for the right resources once they validate their concept and show that is scalable.
But for organisations, scoping out the problems diligently establishes a sort of ‘Landing zone’ for solutions. For me a problem statement articulates the landing zone AND it is agreed by all key stakeholders BEFORE we start off innovating. Unfortunately, failure to do this properly is the norm and thus many innovation projects fail.
Why does this happen?
If you do a search on Google image for ‘innovation process’ you will see many variations of the process and many actually start with ideating (which is wrong). Of the ones that include ‘define’ the problem, this is seen as just one step in a process. My argument is that this step in itself should be its own process as it is that complicated and that essential to get right.
I think most people equate being innovative with ‘being creative’. So when we look at the innovation process they want to focus the majority of effort on the creative parts, AND they are eager to do so. What a better way to bring diverse people together, a key ingredient for innovation, than to bring out a box of Lego or cans of Playdoh? I know, let’s cover the walls with colourful Post it notes and that will really look like we are innovating! Great, now that the walls are covered, let’s take a few pictures and post this to social media. YES LinkedIn world we are rocking it as innovators!!!
So what do I propose?
Disclaimer: This is not the creative part of innovation. This is not the fun part. This is the tough part and often the most emotionally draining part of the process. This is the part of the process which separates the amateurs from the pros.
As I implied earlier, organisations need more discipline in the ‘fuzzy front end’ of the innovation funnel. This means a robust process to align both customer needs with organisational appetite to create the innovation landing zone I talked about earlier. This establishes a critical stake in the ground for an organisation that says here is the space in which we will innovate.
The fact is that most innovations fail and that is fine. But how far back did we fail? If we are confident that the landing zone is mostly correct, then we should build upon our learnings and iterate. But what doesn’t gel for me is when innovation project teams go back and say ‘maybe we are not addressing the right problem’. In this situation, many of the learnings from our failures are not helpful. Let me illustrate this in an example.
If we use the analogy of innovation as building a house, the problem statement is equivalent to the foundation. We should only start investing resources into building the house itself once we believe the foundation is in the right place and is strong enough to build upon. If we discover that during construction something is a bit off and we need to adjust, we can ‘fail fast, fail often, but always fail forward’ as they saying from John C. Maxwell goes.
But what if we find out that we are building the house in the wrong place after half the house is built? Or that the foundation is not holding up? In this situation, can we really salvage the resources invested and apply it to building a new house? Usually the answer no.
Want a business example? Imagine a team starts building an app for customers. They apply agile methodology and the project gets to the full market testing stage. But during this phase it is comes to light that most customers will not install a new app on their phone but would rather use an existing company website which they log into to solve particular problems? Can we salvage the UX/UI created for the app? No you can’t.
For me, the problem with this is that the problem statement wasn’t adequately validated internally, externally or both. So the ideation phase had begun on a rocky footing and the team has now hit a point where they are not only questioning their tactical failures (those are OK with me) but their strategic direction (not OK with me). Iteration is part of innovation, but I think that this should happen almost exclusively in the post-problem statement stages.
Having said this, we don’t always get this right and I have myself cocked this part up more than once, and it is a painful learning. But when conducting a debrief with the team it was ALWAYS a case of us acting too quickly on assumptions and not diligently validating if it was the right problem to solve.
So what organisations need is a way to professionally manage this ‘fuzzy front end’ so innovation projects can move forward with full confidence and focus.
Introducing the ‘Reverse Hackathon’ concept
A reverse hackathon is a structured process to properly define and then map out problem statements within an organisation or value chain. It is an iterative process that brings clarity to the key problems to solve and alignment on the hierarchy of those problems. While a traditional hackathon is a structured process to generate solutions, a reverse hackathon is a structured process to professionally understand and manage problem statements. And while hackathons typically group fixed teams together early on, reverse hackathons will flow back and forth between teams and individuals to maintain both divergent and convergent thinking until a logical hierarchy of problems is established.
Here is the output we can expect
1) The ‘landing zone’ for innovation is established and everyone is on board.
2) Problems statements are structured in hierarchy which focuses the organization's efforts on where to start.
Now, bringing back the analogy of building a house, the organisation and the market are aligned on where to build the foundation for our innovation. While we will make tactical mistakes as we build the house, we can have full confidence that any mistakes we make will be helpful in getting us closer to the right answer.