Lessons from Winning Five Hackathons
Participating in online hackathons has phenomenal training for shipping products. Participating in incredible small teams, I have entered and won hackathons in all six hackathons I've entered since March 2022. After a break in April, I've started a hackathon every month since then.
We also won prizes in almost every hackathon - we delivered quality products consistently and before the deadline.
This regular discipline has served me well in forming better habits for more successful launches. Further, by watching the changes in our results and which projects (sometimes ours) went to the top, we could identify patterns for success that translate well to the entrepreneurial domain.
Hackathons are games. Games are systems comprised of rules and incentives. But the implicit, secret norms of the competition drive the profit. To understand the value of the hackathon, one should look at it as a system of all of these.
The usual explicit rules consist of the following:
Time constraint: in the case of the programs I participated in, between 24 and 45 days.
Public code repository: showing one's work is an essential part of the puzzle. In addition to leaning the projects toward public goods, this requirement helps enforce an original work requirement and the time constraint.
Working demo: The project needs to be more than slides and code - it should be able to deliver an experience that solves the problem.
Video: A short demo video is a submission requirement.
In our experience, these are table stakes - miss, and you might as well not have entered.
The explicit rewards are prizes. They fall into two categories:
Primary domain prizes. In all the competitions we entered, a company hosted the competition. The domain of the competition is their particular area of interest and technology. For example, a recent competition held by Polygon rewarded projects built on the Polygon chain or related technologies.
Secondary sponsor prizes: Larger competitions have sponsors other than the hosts who offer bounties for the "best" implementations of their particular technologies. For example, AWS and Filecoin were both sponsors of the hackathon mentioned above and provided prizes for working with their technologies.
Some of these come with specific statements about what would cause a team to qualify for a given prize. Often judging criteria for the primary award are broken into multiple buckets, like "completeness" and "wow factor." Those tend to be generic and don't inform how to go about the project - the informal incentives are more important.
Occasionally, we see prizes more akin to bounties: a reward for creating something that meets a particular specification. One hackathon we entered was rife with these. We didn't pursue these, but they seemed to have less competition: multiple bounties went un-delivered at the end of that event.
After clearing official hurdles, we found patterns about what drove the most successful entries. These broke into a few best practices, but the key was this: the rewards were about the sponsor and their business goals. Put a different way; winning projects answered the following question in the resounding affirmative:
The Question: If I reward this project, will my company look good?
We came to this conclusion after the first few hackathons in which we tried to understand why the winners - including us! - did well so we could do so consistently. Judges did not necessarily reward superior technical output. Stories that showed clever use of sponsor technology could go unrecognized.
The insight was different from what we expected at the outset. When we started, we thought the issue would be about how a project conformed to the rules and judging criteria. Rules mattered, but only as a filter: violating them got you disqualified, but how well they met the formal criteria was not a sort for top projects.
So how do you make the sponsor look good, and how do they make that determination? Based on looking at the patterns in the winners, we found a few essential practices that we now implement.
Lesson 1: The topic matters the most.
Connecting the sponsor to a cause meaningful to them or a trend in the market makes them look good. Most recently, linking to AI (e.g., large language models like those behind GPT-3) has been a hot area.
To take a counter-example: in our last hackathon, we struck out prize-wise because we connected to the wrong domain. We entered the Hellosign (now Dropbox Sign) competition integrating their product with web3. We lost the category we were competing for to another connected to AI.
We chose the project because we were interested in the connection and had built up credibility in web3 through our previous web3 webinars. But that was focusing on ourselves, not the sponsor. The sponsor is like a customer or a market. Their opinion is what matters because they are judging. The wiser move for us would have been to ask what they find most important. Connecting that topic with skill would have given us a better chance at victory.
And that approach - focusing on the customer and the market - is an excellent skill for any entrepreneur or product marketer looking to impact their venture.
Lesson 2: The video is paramount
The judges look at however many dozens or hundreds of submissions. Their main entry point is the video presentation, which is part of the formal rule set. Often the rules limit how long the video can be, but either way, the judges' time is primarily in the videos. The videos are all many judges will see of your presentation, digging deeper only if the video is among the elite.
Further, on their blog post or release announcing the winners, their main asset for sharing will be the video.
So the video is what will make them look good. Putting time into ensuring the video is clear, shareable, and a celebration of the sponsor and the topic pays dividends.
Lesson 3: Cut bone to ship
You can only win if you deliver before the deadline. Our first hackathon submission was terrible compared to our subsequent efforts. But by shipping, we were on a shortlist. Many stepped in, made big claims, and didn't deliver. When faced with time crunches, we cut ideas and features. The result, in that case, could have been more pretty, but it worked and demonstrated our concept. That, plus the quality of the idea, was enough to win us a small prize.
In subsequent launches, we figured out how to cut earlier so that our late stage could be a guaranteed ship, and we focused on how to make it a great one. Living in that space served us well for increasingly high-quality delivery in successive events.
Lesson 4: Practice makes perfect
We opened with the idea that shipping is of paramount importance and that it is a skill. That takes both theory and experience, and experience requires "reps." We did not exactly cover ourselves with glory in our first hackathon, but we won a small prize that incentivized us to the second. That was good luck - we corrected many of the previous mistakes. And we were better in our third. Even our most recent (sixth), not winning a prize, was a win because we are honing the craft, and we got attention from the sponsor and the community for our take due to the community connection.
Finally, I encourage anyone interested in shipping products to consider building up that muscle with a hackathon. One learns much about focus, delivery, and putting the market's needs first. It can be high-pressure, but so is the world of products.
If you submit to one of these competitions, please share a link to your project in a comment below! I'm always excited to see what people come up with and to celebrate that defining quality of a real artist:
Ship.
Photo by Braden Collum on Unsplash
