4 ms·

Based on my humble experience (I won at Disrupt SF last year), I'll add this: - as the OP said, when presenting, start with the problem. But really insist on i

Based on my humble experience (I won at Disrupt SF last year), I'll add this: - as the OP said, when presenting, start with the problem. But really insist on it so that it becomes painful for the judges. Show the problem you're trying to solve on existing sites/apps. Then show your solution on how you solved it. (See this post by Dave McClure for reinforcement of the idea: http://500hats.typepad.com/500blogs/2009/08/your-solution-is-not-my-problem.html http://500hats.typepad.com/500blogs/2009/08/your-solution-is...) - don't try to do too much: e.g. you don't need a web app + a mobile app to show you've solved the problem. "And we have a mobile version of it" doesn't help you in convincing the jury that there was a problem and that you solved it. Everyone knows that a website that solves a problem can exist in the form of a mobile app. You're wasting your time just mentioning it. - don't discuss the technical problems you've had. For you it's interesting that you finally managed to get around that hurdle and it's tempting to quickly brag about it, but jurys don't care. - while focusing on an API can work, I'd say to also try to incorporate some APIs if that makes sense and you have time. My hack was about showing movie schedules à la Hipmunk (a slow, uglier-than-it-was-then version is still up: http://flickmunk.com/ http://flickmunk.com/), but I managed to find the time to add some Twilio pieces to it (I was familiar with the API already) and that was enough to win their prize too (a MacBook Air no less) while other hacks were fully focused on Twilio and didn't. E.g. if you need to store files of some kind, use Box or Dropbox if they're there. Don't push it too far though. Pick one or two that make sense. Your hack is not a NASCAR car. - while your presentation should be as polished as possible, I was never convinced by people who made videos, flash animations or beautiful slides. I think some judges want to see a minimum viable product/PoC, not a PowerPoint. - as far as polish go, I'm sure a nice design does help, but amongst the winners at Disrupt, it wasn't the most polished that won. (mine clearly wasn't) It was the ones who solved a problem and worked. Too much polish might make it look like you had been working on it for some time before. Nowadays, with Bootstrap, you get something decent-looking enough to get started. (though beware: everyone uses it too) - finally, and that's important: be persistent. My old MacBook couldn't be connected to the projector at demo time so they told me I couldn't present. I was pissed! But I stayed around, asked for a second chance at the end if there was time, just for at least present. I almost gave up but I'm glad I didn't. Of course, all this comes with "YMMV", or "your jury may vary". I think most judges look at demos and want to see something authentic, something that was really built during the hackathon and will excuse roughness around the edges. Some jurys can probably be swayed by a nice design and presentation.

caseysoftware 14y ago
Twilio evangelist here.. I think Timothee hits most of the points very well. Nice job but I'd like to add a few things: - To add to the "don't try to do too much" point, I'd say the vast majority of judges would like to see a few things done really well as opposed to a flock of things sort-of-done. When I mentor a group, I tell them to close their presentation with "Going forward, we'd like to also do A, B, and C. Any questions?" - Avoid video if at all possible. Videos take 5-10s to switch into and another 5-10s to get out of. And that's assuming you have the audio set up properly. I saw a group recently spend ~10s switching, started playing the 30s video, had to stop it to adjust the audio, restarted it, and then ~10s to switch. It threw off the pace and ate a minute of their 5 minute presentation. - Practice out loud as many times as possible. The demo will be smoother and just feel easier. My 0.02..
- jasonlotito 14y ago
  > "don't try to do too much" Yes. This has served me well. I got into a hackathon with the assumption that I'll be the only developer there. With that in mind, I focus on what I can accomplish in a weekend. I plan for additional things, but I keep focus on what I need to do. I also try to plan for additional people. For example, if I get another developer, what will they work on? A lot of it is back and forth, but having a plan at least gives you a place to start. Planning is important, and lets you spend the weekend having fun instead of worrying about whether you will get done or how to manage a larger team.

caseysoftware 14y ago

Twilio evangelist here.. I think Timothee hits most of the points very well. Nice job but I'd like to add a few things: - To add to the "don't try to do too much" point, I'd say the vast majority of judges would like to see a few things done really well as opposed to a flock of things sort-of-done. When I mentor a group, I tell them to close their presentation with "Going forward, we'd like to also do A, B, and C. Any questions?" - Avoid video if at all possible. Videos take 5-10s to switch into and another 5-10s to get out of. And that's assuming you have the audio set up properly. I saw a group recently spend ~10s switching, started playing the 30s video, had to stop it to adjust the audio, restarted it, and then ~10s to switch. It threw off the pace and ate a minute of their 5 minute presentation. - Practice out loud as many times as possible. The demo will be smoother and just feel easier. My 0.02..

jasonlotito 14y ago
> "don't try to do too much" Yes. This has served me well. I got into a hackathon with the assumption that I'll be the only developer there. With that in mind, I focus on what I can accomplish in a weekend. I plan for additional things, but I keep focus on what I need to do. I also try to plan for additional people. For example, if I get another developer, what will they work on? A lot of it is back and forth, but having a plan at least gives you a place to start. Planning is important, and lets you spend the weekend having fun instead of worrying about whether you will get done or how to manage a larger team.