I have been to a few hackathons and startup weekends over the last few years and I have a pretty good prize rate (I have placed at more than 50% of the events). After my back to back win of the ATT and FinApps hackathons, I want to share my thoughts on what it takes to be a winning team.
The best prize is the easiest
Your first goal of each event though should be building out your network. I have met some very interesting individuals (a VC, and awesome developers and designers, etc.) by attending these events. Meeting other smart and talented like-minded people is infinitely more valuable (and easier to obtain) than any monetary prize.
I try to avoid grouping with people that I already know, because I want to find people I will work with again in the future. My friends are known variables. While awesome, I want to see who else is awesome to work with.
Winning the competition
First and foremost, as with starting a company, building a software product, or pretty much any other group activity, you need to have a solid team.
There are two types of people on a good Hackathon team: The Coder and The Presenter.
The coders have the easiest job. They have to develop a working prototype in 18 hours. Good coders can work independently and solve problems they run into quickly.
Coders have to deliver. It is more important to have a simple 100% finished product than an advanced 80% finished product. During the presentation, don’t make the judges put on their imagination hats and tell them what you could of done if you insert lame excuse here.
You need one presenter and that person needs to be awesome at public speaking. Typically they will also provide product development guidance. The good presenter is just as valuable as a good coder, if not more.
I have seen judges destroy teams without solid presenters during questioning. Some judges will ask some really hard questions and you have to have someone be able to deliver awesome answers on the fly.
An example of this was at the FinApps hackathon, a judge asked us how we secured our application.
Rather than saying, “oh, uhh… that is a good point. we didn’t think of that”. Our presenter said, “Our goal for this hackathon was deliver a functioning credit card selector to accomplish one of the goals laid out by the hackathon. We have strategies for adding security into the project, but it was not a target for our team.”
You need to have an idea that is a tiny bit sexy, flexible, and a lot do-able.
You don’t have to bring your own idea, but having one definitely help. I am not very creative and I typically join other teams. My first requirement for a team is not if I like their idea, but if I think they have a solid presenter.
I have seen teams enter the competition with an idea, but end up finding out it was physically impossible to execute that idea. Don’t be married to one concept. 13 teams registered for the FinApp’s $30,000 prize and only 7 presented. A big issue was that there wasn’t a hardware means of executing their ideas and they ended up going home.
Your idea should easily be understood in 5 minutes or less by a panel of non-technical judges.
Please make sure you have the skillset and the time to execute your idea. Many teams end up not being able to accomplish anything during a weekend because they were missing a developer, couldn’t get it to work, or ran out of time.
I have seen many teams get up there and say “hey, everyone reach under your seats and pull out that imagination hat that I put under your seat, because I didn’t get anything done this weekend except this 5 min power point presentation.”
Technically you are not allowed to do this before most hackathon events. Organizers require all work to be at the competition. But I think there are still a few things you can ‘legally’ do to help improve your chances of winning.
If you know you are going to work with a certain technology, set up your environment before hand. Don’t go to the hackathon needing to install android studio, ruby on rails, or whatever technology stack you plan on using. As with any installation, there will be headaches that you should solve before the competition.
If you are working with hardware or an API, make sure your machine can deploy to this hardware before you arrive at the competition. Many teams loose hours of coding time trying to communicate with a device or API unnecessarily.
This is where many teams mess this up. I have seen some really awesome presentations by people that don’t have that impressive of a product and I have seen some terrible presentations by people that could of had a good product.
If you don’t have a presenter, please go learn some basic presentation skills.
- Don’t go up there to show off source code.
- Focus on what you accomplished, not what you could do if you had the right resources.
- Test your application over and over before presenting. Don’t let it crash!
- The basic format should be
- Introduction of members
- Problem you tried to solve
- How you solved the problem
- Demonstration of the prototype
- Be funny. Start of with a Joke or a “ask the audience” question like “How many of you have this problem?”
Don’t forget to bring business cards! Remember this event should be about the networking and not the prize.
Be sure to communicate with everyone you talk with what your skillset is and what you are interested in. This will help them understand how you can help them in the future (and how they can help you).