The Hacker's Guide to Perfecting the Pitch

At every hackathon, you will have to pitch your idea. Stop stumbling your way through the short time allotment, and start engaging your audience.

Transcript

1. Most hackathons require you to present or demo your work. Some hackathons, especially those at schools, will often run little workshops around user experience, or some technology, but few ever teach anyone how to pitch their idea. Most people leave the pitch until the end, and stumble their way through it, spending the little amount of time they have on the wrong things. A pitch is the opportunity to sell through your idea – many a hackathon has been won by the team that pitched the best, not the team that wrote the most code. 1
3. The pitch needs to be planned well before you code. You need to start thinking about your idea and how you communicate it to others so that they clearly understand its intent and purpose. 3
4. Why should you start with a pitch, when during a hackathon, you have such little time? When you start, you often have many ideas and finding focus can be difficult. 4
5. Often settling on a single idea can be difficult, but the more you inspect and develop that idea, scope creep can settle in and suddenly the project starts to suffer from muffin-top. By staring with the pitch, you know have the opportunity to define the overall goal and intent and can how validate new ideas / features by measuring it against that goal. If the feature doesn’t contribute or align with the goal, then it can be shelved. 5
6. Being able to come up with a pitch, means that you can go and practice on potential users and get feedback, which can help validate the idea or identify areas of opportunity previously unconsidered. It is important to consider the user, designing with them in mind , and interviewing users will help tighten the overall concept and approach you might be taking. Other points of view or perspective will help keep your concept in alignment with the user’s desires and needs, and not your own. Take the feedback and iterate on your pitch: try to answer questions, eradicate confusion, and keep it engaging. 6
7. Starting with your pitch, and getting that in good shape will help you prioritize deliverables for the demo. When you know what you want to say, and how you want to say, what you need to show will become apparent. Prioritize development for demo. This might mean hardcoding ( slap me now). This might mean faking data ( taking a response from an api and using it but never really using the api). 7
8. Now that you got the whys down for why you should start with your pitch, and not start immediately coding, we can address the how to pitch. Doing a presentation isn’t always about a beautifully designed powerpoint or keynote presentation. It is about how you present the idea, how you communicate the idea and how you engage others. 8
10. Yes. Practice your pitch. Practice it many times. Start with your pitch and keep practicing it every couple of hours. Take time to refine your pitch based on feedback. You will quickly learn to edit by instinct : some things might feel unnecessary, some areas might feel like they need to be expanded upon. Pitch to whoever will listen – remember your audience will be varied, so the more variety you can get to practice, the better. Pitch and then ask “ do you have any questions? Is this something you would use? ” to help solicit feedback while practicing. 10
11. You will have a certain amount of time to pitch your idea. You will want to practice your pitch enough to understand the limitations of that time and keep your presentation within it. 11
12. Practice keeping within the time limit. This means, at the beginning, you may have to fake demo’ing. Always allot more time than expected for demo’ing - moving from the abstract ( the idea ) to the implementation ( demo ) can take a bit of transition time. 12
13. Many people will be presenting, and you will need to find a way to make yourself unique and memorable. 13
14. Right from the start, you will need to engage the audience. Don’t waste time on individual introductions. Clearly state your team name ( if needed ) and move right into your hook. Perhaps members of your team act out the problem/scenario to help set up the context. Perhaps you say something that is culturally relevant or reference a hot topic. 14
15. Embrace your inner storyteller. Weave a tale that everyone wants to listen to. 15
16. Every idea or concept has a story behind that can be told. Find ways to connect to your audience through this story. Share moments that allow the audience to relate to you or your experience. 16
17. At some point, you can certainly highlight the insight or problem for the audience. 17
18. Both would likely entail a realization about behavior: ”managing multiple credit cards can cause frustration and anxiety”. Identifying an insight or problem will help introduce the proper context for your solution and will allow that opportunity for the audience to relate. 18
19. At this point, you can demo your solution. 19
20. Keep it short and make sure what you are demo’ing is extremely polished ( not buggy, attention paid to design ). You don’t always need to demo on the platform you might be targeting – for example an app that you might want to build for iOS, you could prototype and demo in html5/js. Demo the parts that sell through the overall concept, you don’t have to demo everything. Quality over quantity is important. People would rather see a few views/screens that are exceptionally executed than an entire app that lacks visual appeal and is buggy as shit. 20
21. Play out the future. You will need to address where you can go from here. 21
22. Suggest things like: • what future features and iterations might be. • platforms or touchpoints for the application – is it Windows only or will it be rolled out onto other platforms like Android, iOS etc. • ways for it to make money: how can you partner or monetize and grow the idea. 22
24. @bitchwhocodes Twitter.com/bitchwhocodes Medium.com/bitchwhocodes http://thebitchwhocodes.com 24