Hackathons are the new black. They seem to be all the rage these days and everybody seems to be doing it. I, for one, always wanted to go to one but never had the chance until two weeks ago when I attended Angelhack NYC.
What finally made it possible for me was a fortuitous combination of: (1) a free weekend, (2) a moderate ticket price, and (3) an event with decent reputation. So if you want me to come to your next hackathon, you know what you need to do. Don’t overcharge and make it good.
But I digress. How to put together an awesome hackathon is a topic for another post. For now I’d like talk about my personal takeaways – what went right, what went wrong, and what I could have done differently to get more out of the event.
If you are a first-time hackathon attendee, I sure hope you’ll find this bit of anecdotal observation useful. If you are feeling impatient, feel free to skip ahead to the summary section below.
Prepare the Right Idea
The set of ideas you’d want to bring to a hackathon are not necessarily the same ideas you’d want to build a business around. For one, I would argue that not all businesses have a prototype that can be built in 24 or 48 hours. The other problem is that if a prototype can be built quickly, then it’s not necessarily a prototype that can make an effective and snappy demo.
This wasn’t so much the problem for this hackathon since the judges seem to be preoccupied with the business side of things, which was refreshing. I suppose other hackathons are more hacking and less business-y, so your mileages may vary. In any case, it would have helped to keep in mind or sketch what would be a reasonable demonstrator for what you plan to work on.
Ideally this would be part of the pre-hackathon brainstorming session you have with your team. I didn’t have a team going in, and I didn’t prepare enough solid hack-worthy ideas to recruit a team on the spot.
In the absence of a pre-hackathon brainstorming session, I would have still tried to do a better job pitching my ideas. Problem was I was half-convinced that my idea was worth doing, and that really put a damper on my recruiting efforts. If you pitch potential teammates, you should exude confidence and be absolutely certain that you’ll kill it.
This doesn’t mean that you can’t pivot together once you have a team, but be sure to have something to be unabashedly excited about when you get to the event.
Get a Team Together
This is perhaps the greatest asset you can build prior to arriving at the actual event. I feel like this is far more important than having the right, hackable idea tailored for the hackathon format.
Let’s be frank. Getting people to follow you is hard. Getting people to follow you because of your idea when there are dozens equally good ideas floating around is doubly hard. Angelhack used Hackathon.io to allow hackathon participants to network prior to the event, which was a welcome touch.
I used the site to chat with a few people and to assemble a kind of proto-team of potential people I could work with. We discussed a number of ideas and agreed to work together on something. That was really a key omission.
We didn’t commit to working on anything specific prior to the hackathon, so there was very little to keep this proto-team together and resist the temptation to wander off and work on other cool stuff, which is exactly what ended up happening. People wandered off to do other things with other people.
If I had to do it over again, I would have done more homework getting to know my potential teammates. Meeting in person prior to the day of the hackathon is a must. Willingness to meet in person prior to the event is a really good way to gauge people’s commitment to work together.
It helps not to think of the demo simply as a way to show of what you’ve built. The demo is your opportunity to frame the problem that you are solving and to give a hint of how you are solving it. Fully-functional, working prototypes are rare and are usually a sign of some serious prep.
As my proto-team disintegrated and I wasn’t able to join another, I ended up working on one of the ideas I had for a while – Haircue. Needless to say, I didn’t get nearly far enough to demo anything, but I did stick around for other teams’ demos.
I can say that the most successful demos really benefited from effective storytelling. Come to think of it, storytelling trumped everything. Technical execution, business viability and a host of other essentials pieces took a backseat to a powerful, compelling story told in 90 seconds or less.
If I had to do it again tomorrow, here’s what I’d do differently this time around (btw, I don’t have to do it again tomorrow, but I will have to do it again on August 4-5 when I attend eCommerceHackday):
- Think of a big idea for which a nicely-sized, neat prototype can be done in 24-48 hours. Think of 5% of target functionality that you’d actually demo.
- Invest time in meeting the team and get them to commit to work together prior to the event. Confidence is infectious and will serve to bind the team together. Be sure of success.
- Don’t fret the demo. Fret the story to back and uplift the demo. I feel like that’s the most important piece of the puzzle. Just ask these guys: Mailmoat, Monnected, Mentor.im, WakieTalkie, The Stayover, Mediawire.co, and Wrkstrm. They all advanced from the first round.
Got all the way here? You should probably follow me on Twitter.