TechCrunch hosted a hackathon before the 2012 TechCrunch Disrupt in SF this weekend. Part one of this post deals with Hackathon logistics and presentations; Part 2 will be some quick thoughts on some of the ideas presented. Here are some of the overall impressions followed by tweet-length reactions to the 60-second presentations. You can see all the demos here and the top winners with videos and pics are available here. Continue reading
Tag Archives: TCDisrupt
TechCrunch hosted a hackathon before the 2012 TechCrunch Disrupt in SF this weekend. Wanted to push out some quick impressions for both the companies that demo at Hackathons as those looking to host/participate in future hacks. Part one of this post deals with Hackathon logistics and presentations; Part 2 will be some quick thoughts on some of the ideas presented.
Some basic rules/tactics to cover off at a minimum:
- If you have 60-seconds on stage do ALL the boring stuff before you get on stage—that means set up monitor for mirroring. Clear cache, have everything demo-ready
- Limit to 2-people per hack to minimize congestion; and really for 60-seconds you should only have one presenter unless you’ve got a role for each of the other folks on stage
- Make an impression–Display stickers so #is visible in video/pics w/Name for judging b/c sometimes names get confused, presentations jump out of order & stuff happens
- Make a lasting impression–don’t hack until you get on stage; leave at least an hour to run through and refine your main talking points, places for humor or impact and repetition of your name/solution/problem you’re solving
- Demo your app first
- List apis/technologies used quickly at the beginning or in the end w/credits to thank the amazing resources that helped you get there, but don’t sell them as a differentiator or key feature. It shouldn’t be last thing people hear/remember, but please give credit where credit’s due; plus you’re more likely to win API-specific prizes if you give the shout-out
- Have your presentation flow tightly choreographed between screens, server-calls, etc. Know which ones take longest and which will cut out if WiFi isn’t working (which is likely b/c everyone’s on it or blocking good signals w/their mifi networks). Consider cut/paste options and other shortcuts if involved input is required.
- Don’t trust the tech–we’re still in a “can you hear me now” world even at the best-prepared/run events
- Don’t get lost in the features and forget to share the idea (tough b/c you’ve just spent 24 sleepless hours in feature analysis/focus land)
- If fast pitching, consider having 2-3 podiums vs 1 table. Understand it means you need more Elmos, etc. to make that work. Would allow pitch bug delays to be minimized and feature the work
- Focus on pitch, not on the screen—distractions lead to disjointed delivery
- It’s a marathon & you win by getting it past the finish line–many of the presenters acted like just being on stage was the finish line; it’s not. You need to close FTW
- Keep going until they kick you off
- Sponsor apps get more time to present/fail
- Native language presenters aren’t necessarily the best presenters—go with the most entertaining b/c even if the demo sucks they’ll still remember you—but if you can have both, it’s better b/c you’re usually trying to convey some complex thoughts into a simple story
- If you’re on a team, don’t lean over and tell the presenter they only have 20-seconds left—distracting & it’s conf organizer’s job to manage anyway—like a coach; your job is done when they go on the field.
And, if you’d like to see a well-run Hackathon recap, enjoy the Big Brand Hackathon we hosted earlier this year with Kraft Foods and The Home Depot: