Created on 2015-07-01 06:29

Published on 2015-07-01 06:38

It’s raining hackathons in Bangalore. Last weekend was Jugaadathon, next week is IOT hackathon and this week, the mother of all hackathons, wait for it….kumbathon! Yes, hacking kumbh mela.

So,  in the spirit of helping hackers,  here is my cheat sheet for hacking the jury process.  Having served on numerous one hackathon juries, please don’t take my expert advice on this. By the way, on my views on startup experts please read my earlier post- “Shoot me if I every say these things to a startup team.”

Any case,  here it goes.

Manage your time for the pitch.

Pitch 1 slide per min.

If you have five mins, put five slides,  three minutes,  three slides. It’s tough. But doable. Many great pitches end when the buzzer goes off and the pitch is not complete. Avoid it. Practice with one slide per minute till you get it right.

Start with positive emotions

Most hackathons start with problem statement pitching and particularly with health hackathons – very depressing stats on number of children dying or hospitals not functioning. Good relevant stats, but not to begin the pitch with.

Start positive. Begin your pitch with an upbeat statement. Or a promising solution.

Eg. Our solution will eliminate malnutrition, or we will make hospitals 100x more effective or our tools will eliminate world hunger.

Flow of the pitch

My recommended sequence is dil, jigar aur phir dimag (Heart, Gut and then Brains)

First go for the heart. Positive pitch which shows this is a solution I will love. It is cute, simple, creative or unique. Get the dil on your side.

Next show why this is a compelling solution, ie so doable,  if supported. Go for the jigar. We are not talking about problem,  but your solution. It should look so simple (might be complex in the background).  But a compelling case to be made that the jury should be – aha, yes this is doable. Very complex solutions usually don’t get the jigar.

Then go for the dimag. Show research which supports your solution or pieces of the solution is feasible. Go into details of the solution, not specs but solution specifics and how it will work, not how it is compiled or the platform etc it is built.

Get a business-y person on the team
While assembling your team, find one good business person even if this person is zero tech. Or someone who is comfortable on stage,  is good at pitching. Tech guys rarely are comfortable.

Find the folks who are mingling during the hackathon and asking questions. Not the ones suggesting solutions.

People who smile and have warm handshakes. These folks should present.

Last slide while doing the Q&A with the jury
The slide which shows up when the jury is asking questions  is the least used asset. Don’t put thank you and contact details on it. They know how to find you.  Put all your specs on this slide without crowding it. Or a prototype image with work flows. Or the circuit diagram or the development pipeline. You can always turn around and refer to it if there is a jury questions.

And put the team details on this slide. Names, background and superpower.

Images, not text on your slides
Again, people can read text faster than you can read them out off the slide. Avoid text. Find images that convey whatever you want to convey. In the backdrop of the image say what you have to say. Maybe the text can be in your notes that you can read from.

Ideal number of words on your pitch deck? Zero.  Worst case,  maybe seven to ten words per slide

Don’t worry about explaining the problem statement

Most hackathons have the problem statements either up front or before the jury process.  So don’t dwell on it. Noone needs to be educated on it.

Focus on your unique hack to the problem.

Get in the first five to present
The order in which  you present matters. Get in the first five, but not the first one. Just that the jury is fresh and most likely more generous in the initial few pitches. Also avoids someone pitching similar hack as yours and stealing your thunder. The first one unfortunately has no idea on what the questions will be like. So avoid that.

Don’t let others steal your thunder

First criteria the most important
If you are going to be judged on multiple parameters,  know the order. Of those, if first one in the list is creativity, go for coming up with the most creative option and dazzle the jury. Or if it’s team, put together a stellar team and show it upfront. Research shows that once you rate someone higher on the first criteria, you will tend to rank them higher on other criteria, relative to if the first was low ranked.

So whatever you do, ace the first criteria of evaluation.

*potential jury members –  to avoid this bias, read Daniel Kahneman’s Thinking Fast and Slow*

Projections ‘pe lagaam’ do please
In 48 hours or a week,  it’s tough to figure out the business model. If you got the solution right, maybe with a few iterations, you might find the projected market etc.

So for now. Easy on the billion dollar number which magically appears on excel.

And go to market in 2 months. And definitely, no profitable in six months.

For more insights on this, read Barry Gibbons’ – If You Want to Make God Really Laugh, Show Him Your Business Plan

Assembling your hack team
Have as big a team as possible, but not too many experts. Maybe it makes it look like wow,  look at how many people are excited about this problem. It’s harder to give lower points. If you and your friend are the only one.. Hmm.. Maybe this is not going to work. Or can these guys pull together a team of complementary skills? Avoid too many experts. Nothing will get done. Refer to the preface.

Get a couple of design/designer folks on the team.

This way, the slides will look better, and also the prototype will seem more sensible. And doable. Will get the dil and jigar quickly.

Pitching to the jury
One person pitches, and random people in the team do not jump in. Don’t let the focus shift from the person who is presenting. One person does the entire pitch and answers questions. The merry go round presentation is for “the suits”.

Don’t waste your time on passing microphones.

Don’t pull a fast one.

Feel comfortable to say “I don’t know. Yet. We will look that up”

No one expects all answers from a hackathon. It’s a beginning, and you will figure things out. So say this is work in progress if there are gaps.

And finally
Smile. Have fun. And most importantly, don’t argue with the experts on the jury.