What does it take to win a modern hackathon?
And as an external viewer, and sponsor, we want to share our impressions about what it takes to win a modern hackathon. Besides the fun and learning about new technologies (provided by the great sponsors like us 😉 ), winning a renowned hackathon where more than 100 participants gather can be easier than you think. As always there is no recipe for success but if you follow our advice, you might increase your chances.
Myths and Prejudices – Don’t put all your eggs in the same basket
First, let’s sweep away some myths and prejudices. You don’t need a track record of many participations in hackathons nor do you need THE winning team. The 1st prize winner at OktoberHackFest formed during the team building before the official start and only came with the idea 4 hours after the start (actually after attending our workshop). Also, a winning team is not a team of 3-4 engineers or computer science students. Try to have a team with different skill sets. The best ideas often come from those teams. Also, if you intend to hack the next BitCoin technology, go your way and head to smaller, more focused, hackathons.
Strategize – Forewarned is forearmed
It’s time then to choose your strategy: you have to decide whether you’re aiming at one of the tracks/challenge prizes (awarded by sponsors) or the overall bigger prize (or simply have fun). Going for one of the tracks or challenges is a safe bet as teams will split among the different tracks, often not evenly (not all APIs are created equal 😉 ). To increase your chances, combine different sponsored APIs. Sponsors love it! Ohhh, I hear you complaining, this goes against the whole philosophy of hackathons… Well, see this as a challenge: constraints are often a source of creativity! And if you decide to aim at the overall prize, you don’t necessarily need to use any of the sponsored APIs but if you do, choose the most appealing to you and your team.
Code Lola, Code! – But let’s not put the cart before the horse
Finished with strategizing, let’s start coding. Wait a minute! Don’t forget you’re building a mini product of its own. This entails a clear working methodology. Without going as far as SCRUM, make sure you design your project in 2-3 iterations and try to have an end-to-end prototype of your product as early as possible. Don’t postpone integration tests to the last minute!
Time to pitch
Even if the evaluation criteria includes code reviews, novelty and others, needless to say that the pitch and demo is the most crucial part. Even more so after after 30-40h of coding. You have to convince the jury or sponsors that you are the winning team, not the rest of the (sleepy…zzz…zzz…stinky) audience! Jury members are often former hackathon winners but a lot of water has flowed under the bridge since then. They are now working as C*Os of startups and renowned companies and their expectations about the quality of a presentation are high. These guys spend their days attending meetings and presentations. Besides, they are on the lookout for projects which have potential as a product, not a hack even if it’s the next technology powering BitCoins. This means a mini product. According to Vital Meyer, Jury Member for CTI, their task was not really easy but in the end, he says, “the quality of the presentations finally really made the difference!” and concludes that #NerdishByNature‘s app (1st prize) was seen as targeting a “niche market but with a very clear value proposition and a convincing team”. As a matter of fact, many successful products started as niche be it FaceBook (overnight dorm project), Paypal (beaming money by infrared with Palm Pilots), Ebay (auctioning collectibles such as stamps), you name it. Another of Vital’s favourite was the project from the #probably first ladies team on hackzurich but “they did not make it albeit it was very convincing, but too modestly presented…”
Take Home message
So here is our final advice: 1) It doesn’t matter if you don’t have a team. Just make sure your focus is dedicated to creativity and you have a clear working methodology (and please don’t re-install your dev environment in the middle of the hackathon). 2) Don’t be too disruptive, keep this for small hackathons. Keep in mind that big hackathons are judged by professionals, not your peers. 3) Don’t overlook your final presentation – that’s what makes the difference in the jury’s (subjective) mind. And the whole community can only gain from better presentations. So prepare and rehearse your pitch! And I leave the final word to Tal Heskia, Uepaa’s p2pkit product manager: “A hackathon is a delicate balance between planning and just trying. And the biggest risk is yourself. If you’re an engineer try to think product, if you are designer or marketer try to think a bit engineer. Finally the magic mix needs to have both. And as with cooking, it depends on what you cook. 30 to 40 hours are short, so don’t overthink it and follow your guts. In the end, have fun, that’s what it’s all about!”
Carpe Diem et Technicam!
PPS: we’re planning to organize a p2pkit hachathon at Uepaa, if you are interested, please pre-register here (no commitment).