Over the past few years I’ve had great fun and met a lot of interesting people by attending open hackthons. I’ve explored inspiring problems, and delivered concept pitches for the hackathon jury. I even won a few of the hacks I participated in. However, I’ve noticed that the outcomes of a hackathon, most often die immediately after receiving the hackathon price. I’ve spent some time with the problem and I have come up with a potential solution.
The problem with hackathons
Hackathons originated in the tech industry, where companies started putting a few days aside to escape their daily work tasks and prioritise discovering, building(coding) and exploring new ideas. Today the hackathon ‘method’ has been adopted by everything from government organisations to the fashion industry.
Non-coding hackathons give a lot of immediate ‘soft’ value — like networking, recruitment, education and marketing/storytelling value. But that’s not why most organisers make hackathons — they usually have a problem they’d like to explore— so why aren’t the organisers needs and motives and the outcome aligned?
Why don’t we make hackathons that bring us closer to actual solutions to the given problem?
Most non-coding hackathons revolve around the early phase of concept development. Starting with a discovery phase, an ideation phase and a definition phase where one comes up with a solution to the challenge at hand: an idea to pitch.
The discovery and ideation-phase is of course super important. But the real work starts when you have to define what you are actually going to build, and when you start actually building. That’s when actual definition happens, and you can start to fail, tweak and validate your idea. And it’s from that point on is that things get really interesting.
I belive there are two major flaws with the common ways of doing non-coding hackathons today:
- The incentives are not aligned to achieve the intended end goal.
- The ideas are rarely built, tested and iterated upon.
So, how can we make better idea hackathons that actually drive innovation?
My home municipality recently asked me if I could help them produce a hackathon to explore the potential of open data. They were open to suggestions on how it could be organised, and I found this to be a great opportunity to spend a few days pondering a problem I had observed:
Why were most of the hackathons I’d experienced, unable to build on the best ideas when the hackathon was over?
Aligning incentives with desired outcome
When companies and organisations use hackathons to crowdsource creativity, they most often bring an actual, and relevant problem they want to explore. From what I’ve seen, hackathon organisers find it hard to nurture or keep exploring the best ideas that they were handed. It would demand budgets, hours and perhaps interfere with their current business or organisational model. For most organisations, this is simply not something they can prioritise without proper validation.
After some thorough thinking, I came up with another question:
When doing hackathons where the produced ideas are digital solutions, why not just build the suggested solution?
To define a concept in a way that makes it possible to build takes time — and is ideally something you’d want to do in a diverse team. Now that’s exactly what companies and organisations invest in when they make a hackathon. They invest in concept development. But they rarely find the right incentives to make the winners build it after the hackathon is finished. And the organisers for sure do not have time themselves. So what usually happens is; nothing.. Why not test more of these ideas? Why not build light MVPs and iterate on them?
For the hackathon I made for my municipality, I suggested something I’d never seen as a hackathon prize before.
For the open data hackathon I suggested we awarded three winner concepts with hired professional developers, paid by the organizer/owner(in this case being the municipality), to build functional MVPs of the winning concepts.
The benefits
Replacing at least some of the price money, flashy items or cool privileges that usually are announced prices for hackathon winners, with the opportunity to have your winning concept built, makes sense in a lot of ways:
For the winning team:
Skilled developers at your disposal! Which can be really hard to find on your own if you don’t know how to assess them or what they are building.
A finished project you’ve done or contributed to for your CV/resumé. You can even contribute in the building process if you have the right skills.
You’ll be left with everything you need to validate your idea — tweak the solution until you’ve got happy test users. Use your MVP to build a business or your validated concept to get further funding.
For the hosting business/organisation:
New innovative MVPs that are ready to be tested and validated!
Even more stories to tell from the hackathon (you can for instance share stories on each finished MVP — and maybe even a success product after some time?).
You can distribute the rights as you prefer. Adapt the distribution of ownership of the MVPs in accordance with your business/organisational model and your participants motivation: do you need to retain ownership in your company/organisation? Or do you attract the right crowd by giving the rights to the winners? Align your incentives with the desired outcome.
..there are also a few pitfalls to watch. For instance the transition phase from concept to actual user experience. Say an inexperienced team wins with a great idea. Maybe they’ll need some guidance before they define what the developers should prioritise when building. Maybe I’ll have to revisit this subject when I’ve manage to use this model a couple of times..
Who should own the outcome?
Who should own a MVP that is built as a result of a hackathon? This question is a key element of the incentive structure you create when you organize a hackathon, and it should be tailored to your and your hack participants needs and motivations.
Winners of a concept development hackathon, will have approximately 3 personas:
The entrepreneur: “I want to own the concept and make it my business or hobby!”
The engaged citizen: “It would be nice to have contributed to this and maybe I’d like to stay engaged in my spare time, but also maybe not..”
The student: “I’m just in it for the fun, the learning and the free pizza — and to have it on my CV/resume.”
The entrepreneur will probably want to own the rights of the MVP, but the two latter probably won’t. The rights can then be retained by the organiser — or, as Christian Landgren, who I invited to mentor and talk about digitalisation and Öppna skolplattformen at the open data hackathon suggested; why not just have it be open source?
Let’s get creative and.. build!
Big budgets does not automatically fix problems or innovate stuff. Incentivising building solutions, that can be tested and iterated upon does. A lot of suggested solutions will fall short — but to find out which, and which of them might succeed, we need to put the idea out there, actually build and test it.
The original purpose of hackathons was to build new experiments — but somehow, we lost something along the way, as the hackathon method was adopted by the broader public.
Currently a small developer team is working on building the 3 winning suggestions of the above mentioned hackathon for my home municipality Bodø Kommune. It’ll be exciting to see the end products. I hope they all manage to make something that can go live and have test users.