Why hackathons fail and what you can do about it

A hackathon is a great opportunity to boost innovation in a company. It is usually a fun time of the year that boosts team morale and strengthens collaboration across the company.

Unfortunately, winning ideas often don't make it to production. The team is great, the idea is great, the proof-of-concept (POC) is convincing, everybody loves it... but alas, the POC never becomes the magical product that everyone was dreaming of.

Why is this happening?

The inconvenient truth is that, quite often, hackathon projects are product features/ideas that have already been discussed many times over during the product roadmap. The idea was killed or de-prioritized, most likely for a good reason. Yet, the idea comes back in the form of a hackathon, sometimes for many years in a row. And because it was already de-prioritized during the product roadmap, the idea just does not get traction after the hackathon [1].

This issue stems from the conventional wisdom that anyone should feel free to work on any topic they want during a hackathon. After all, shouldn't a hackathon be a place for free and unleashed innovation? The problem with this approach is that, while it seems logical and convenient at the first place, it actually opens the door to the problem described above.

And so, the main problem that needs to be solved for a successful hackathon is to balance the freedom of exploration on one hand, and the likelihood of business impact on the other (obviously, if the goal is simply for people to have fun for a few days, then this problem is irrelevant and we can just move on).

What to do?

One way to address this challenge is to dedicate one track of the hackathon to "business efficiencies". Because these ideas are orthogonal to the product roadmap, they are less likely to have been arbitraged already. Also, they often imply either business savings for the company or more convenience for the employees (or both), and therefore gather traction fairly easily.

The hard part is about the other track, the one impacting the product directly. One approach consists in having representatives of the business/growth team in the jury. While this is a good prerequisite, it is unfortunately not good enough. Indeed, ideas that conflict with the product roadmap still make it through the selection process (based on the "free exploration" principle). Giving a veto right to a single member of the jury would solve this problem, but feels fairly involved.

The key idea is to provide guidance to the hackathon teams ahead of the hackathon. This guidance can come in two forms:

  • a list of previously explored ideas that did not pass the product arbitrage stage -- the discussion would still be open on these topics but at least you are not wasting hackathon efforts on them. Think of it as the Google Cemetery.
  • a list of interesting areas/domains to explore that the business/growth teams would happily (and truly) support, were the idea to win the hackathon. Think of it as the Request For Startups by YC.

Another idea is to have a rule stating that each team should have at least one member coming from the business/growth department. Much like the business-member-in-the-jury idea, this is not a silver bullet but certainly helps.

How do we make sure ideas make it to production anyways?

Assuming that the ideas have truly gained business/growth traction, another challenge remains: that of making sure that the idea makes it to production.

Here again, we need to be honest. A POC will only make it to production if it becomes an integral part of the product roadmap. Else, it just becomes technical debt that sits in production for some time, only to become a zombie project that nobody maintains or cares about.

Therefore, the idea needs to have a real sponsor from the senior level on the product/business side. It should make it to the OKRs and become a first-class citizen in the product roadmap. It should have a dedicated hosting team in Tech.

None of these concepts are cheap or easy to implement, but like with many things in life, there is no free lunch :)

[1] Depending on the culture of the company, the hackathon team may or may not get explicit feedback about why their idea is not getting traction. There is an opportunity here to provide constructive feedback to tech teams about a specific ideas that they think is very cool, but truly does not make sense from the product/business stand point. One could still argue that the idea would make sense in a different context or in a different company. But in the end, we need to be able to disagree-and-commit at the company level instead of leaving strategic questions unanswered.