Monday, September 27, 2010

10 Things I learned at the TechCrunch Disrupt Hackathon

Mimi Sun, Chris Lambert and I spent this weekend at the TechCrunch Disrupt Hackathon, building www.upquote.com. Here are the lessons that we learned.

Have your tools setup before getting there
The first few hours are crucial as when fatigue sets in it becomes much harder to make difficult decisions. You don’t want to waste that precious time wrestling with plug-in version compatibility issues while trying to download large SDKs over a congested WiFi network.

Choose technologies carefully
Every new programming project has trade-offs between learning something new and being productive. It’s up to you to choose what balance to strike, but I suggest having a bias towards deepening the knowledge of something you’re already familiar with. For Upquote.com, we built a website using App Engine with GWT, a Chrome extension for publishing quotes and an Iphone app for quote consumption which would not have been possible to build within 24 hours without some prior familiarity with these technologies.

Practice your demo with someone who is unfamiliar with the project
You’re one of the few teams who managed to stay up the entire night coding. You have a great idea, and flawlessly implemented all of the key features on time. Once people see your 60 second demo, they will instantly see its utility and call all their angel investor contacts to tell them how amazing and useful this product is... right? Not exactly.

The problem is it takes time to build a proper mental model of a new product. To help better understand the gap between how you see the product and how others perceive it, you should practice your presentation with an unbiased 3rd party. The central idea that differentiates Upquote from sites like Digg and Reddit is that they aggregate based on a webpage model, while Upquote takes this a step further by surfacing the best snippets of information from webpages, allowing readers to discover and vote on the key concepts of popular content without having to read entire articles. We did a practice run of our demo with TechCrunch writer Lora Kolodny and realized that after 24 hours of hacking on the product, its central concept was so intuitive to us that we didn’t surface it at all during our demo (huge thanks Lora for the help!). Her feedback allowed us to make significant changes to our pitch which resulted in a much stronger demo.

It’s all about picking the right features
You’ll start the day with lots of energy and enthusiasm, and this is when you want to make the hard decisions as to what features are the most important to implement and which ones are ‘nice to have’. You can adjust along the way, but as you get closer to 3 or 4 am you should really just be focusing on implementation details.

Also be careful of easy features. They can eat up much more time than you think so it’s important to weigh their benefits thoughtfully before deciding to implement them. A good rule of thumb is that out of 5 easy features, 1 of them will take the time you expect, 3 will take twice as long and 1 will be full of unexpected difficulties which will make it a huge time killer.

Wear layers, bring a sleeping bag
Hackathons are often conducted in large auditoriums which do not typically have overnight guests nor have proper heating or cooling. Temperatures went from extremely warm during the day to very cold at night. When battling fatigue, adding being too hot or too cold can really affect your productivity. The hackers that were taking 10 minute power naps in their sleeping bags had it good :)

60 second demo: should you focus on the concept or the product?
A 60 second demo is incredibly short. Should you focus on the concept, describing your idea and the problem it’s trying to solve at a high level, or should you instead dive into a demo of what you’ve implemented and let people infer its usefulness. You won’t have time to do both.

The answer is: it depends on your goals. If your goal is to get some exposure in order to get vc funding for your idea then opt for the well defined sales pitch. This approach will also maximize your chance of winning as there are so many presentations given one after the other that it’s much easier to pick out the ‘blackbox for your phone’ concept rather trying to extract a mental model from your feature based demo (remember the point above about how long it takes for someone to form a proper mental model about a product?).

However, I think you shouldn’t focus too much on the competition as coming out on top of a lightening round of 80 presentations of 60 seconds in a row is a bit of a role of the dice. If you’ve successfully implemented something, it’s more fun to go up on stage and say ‘hey look, we have a cool website, and a chrome extension, and an iphone app, all built in 24 hours and you can use it right now!’ than it is to go through a sales pitch about how digg and reddit have a ‘page’ as an atom while we believe that a ‘page snippet’ model will speed up a user’s ability to consume information. And fun is what hackathons are all about, so I suggest going the feature demo route and trying to come up with a quick metaphor that can be used to describe your idea in a few words.

Try to launch something
It takes time to polish a product enough for launch. Do you take the time to add error checking on the parameters you receive? Do you add real authentication or just fake it? A common rule when hacking a prototype is to get something up and running as quickly as possible, even if it will only work under a demo environment. Having an early prototype gives you invaluable feedback and allows for course correction. This was our approach until about 2am, when we changed gears and decided that our goal should be to successfully launch this product and have it available to everyone by the time the hackathon was over. This decision worked out well as it energized us and made programming really fun as we were working towards a goal that seemed both ambitious and worthwhile. The icing on the cake came when we were able to present our demo using the live version of www.upquote.com and have a user create an account and post a new quote on the site before we made it back to our seats :)

Exercise works just as well as caffeine for staying awake
A couple of us decided to do this hackathon without caffeine. Routinely getting up and taking walks, going outside, doing a few push-ups and taking quick jogs around the building were all great ways of staying energized.

Treat the sales pitch like a difficult part of your app
As mentioned before, the hard parts of your project should be done early since decisions get progressively more difficult to make as fatigue sets in. Treat the sales pitch as you would a moderately difficult technical problem as iterating over the wording of your pitch to find a concise way to describe key concepts of your application is difficult to do.

Have fun!
Hackathons are a great way to hang out with friends, meet new people and develop new skills. Take a minute to look around and enjoy yourself!

Marc Stogaitis

No comments:

Post a Comment