This article was co-written by Aldo de Jong and Yannick Rennhard.
The idea of a hackathon is quite intriguing: bring together a group of developers and let them forget their daily routine for a moment. Let them explore. Let them collaborate with no agenda, with just fellow developers, their creativity and their code. Letting go of constraints must be great for innovation, no? Well, no. This is another example of corporates trying to be innovative by acting or engaging like startups, another example of throwing mud at the wall and seeing what sticks, see our previous article in this series, ‘Are you sure you want to innovate like a startup?‘. Hackathons are valuable to help developers find an application for their skills. They’re ideal to foster dialogue within the discipline and to push technology adoption. But if you think you can use hackathons for innovation, you’re fooling yourself.
Let’s look at an example. At Claro, we’ve worked together with a large tech company that wanted to do exactly this: sparking new ideas for innovation by hosting a series of hackathons all over the world. From 200 finalists, the best five ideas were selected to join a remote acceleration programme which we facilitated. We realised quickly that even the best 2.5% of ideas were terrible from a human-centric design perspective. They were solutions looking for a problem and created very little value for the user: a recipe for solutions failing to gain any market traction. This is precisely why our approach to acceleration programs is highly focused on customer understanding, value proposition development and customer validation.
The foundation of successful innovative solutions is always a deep understanding of people’s needs. This is why if you want to innovate, you should organise an anti-hackathon – a “Jam”, as we call them.
At Claro, we have organised about 15 events like this so far – ranging from the Barcelona Service Jam, the jamjam or derivatives like IoT Lab and the Fintech Jam for Good. Some of these were for corporations, such as Suez, Intel and 3M.
The first key to success is pushing for a good balance of anthropologists, designers, strategists and developers amongst the participants. That way not only the outcome of the Jam will be improved, but by working alongside people with different expertise and knowledge, each participant will himself become better at innovating when he comes back to his business as usual. We always start with a user need and don’t start coding until late in Day 1.
At the end of the event, we always invite early-stage investors or senior executives, and their feedback is unequivocal. The “investability” and innovation potential of the projects is consistently higher than with hackathons: a larger percentage of projects are deemed viable because of sufficient team strength, concept originality and actually solving a problem worth solving. Also, many of our past hacker participants have told us that there’s considerable hackathon fatigue among the greatest talents in the field and that they prefer this kind of setup with different disciplines involved, and user-centric problems to solve.
Dear hackathon enthusiasts, we think it’s time to stop gathering the same experts with the same mindsets in the same comfort-zone setup. We think it’s time to put the user at the centre, to think across disciplines and to make things a little bit more unsure and uncomfortable. Ladies and gentlemen, it’s time to jam!