How to hack a Hackathon: Pitch Perfect

(The main article and links to the other posts on Hackathon 101 and Industry are linked here)

I do not trust people who enter competitions just to participate and make up the numbers. Like, what’s the point? If you’re going to commit time, and in this case a weekend, to something then you might as well go full tilt and get something out of it. At the end of the day while no one really loses there are definitely winners and in this post I will share some of my approaches that have served me well.

Agrim, what do I build?

A large part of hackathon (and product) success is perhaps determined by what problem you decided to address and how you went about solving it. Let’s examine both these areas.

What problem should you solve?

This is admittedly a difficult question; there are plenty of people in this world who are asking themselves this question while attempting to build out their startups, wondering if what they’re working on is important and worth solving, if at all it is a problem.

Here’s how I do it — I was lucky to be in a university curriculum that emphasised the importance of design thinking. Simply put, design thinking leads a solutions-based approach to solving complex problems, especially those that are ill-defined or unknown. Now you could choose to scratch your own itch or pick a new domain to solve for but the following process will work just the same.

The Design Thinking Process

Empathise

Too often we are guilty of building a solution without giving much thought into things that come before it — why are we doing it, who are we doing it for, what will it really do, will it do what it intends to do and for the right audience. Much of this rests in the lack of empathy for the problem. We let our own assumptions dictate what the problem is, and that is wrong. I faced this first hand when I was trying to build a solution to help the visually-challenged navigate independently. I assumed that:

• Firstly, this is a problem because guide dogs are expensive and having a helper is troublesome,
• Secondly, obstacle avoidance is the biggest problem to solve,
• Lastly, a wearable like Google Glass could eventually get rid of the cane.

I was wrong on all three counts.

The first point on relieving the helper, while true, wasn’t a pressing concern that would require technological interference. The second point on obstacle avoidance wasn’t the biggest issue; detecting traffic lights was probably a bigger challenge given that the cane covered for most obstacles within range. The last point was severe because I assumed technological replacement is easy. You cannot dramatically switch a person’s way of life; the visually challenged are used to using their cane and tactile pavement markers so any new tech innovation must build on top of this, not entirely replace this.

How do we remedy this? Getting out and talking to people is the surest way of knowing more because you get direct insights into users and their needs. I was able to fix my product to help the visually challenged because I actually talked to someone who lives these challenges on a day to day basis.

But what if you can’t talk to the right audience during a hackathon? Time is short and maybe you’re not in the right place to meet these individuals. You have to improvise and pull up information that will help you objectively define a problem worth solving. Last weekend I was working on a hackathon that wanted us to “Solve for India”. This is a huge theme; India has no shortage of problems, each more important than the last, and to frame it effectively is a challenge in itself, let alone attempting to solve it. We decided on helping out folks employed in the Industrial sector and framed the problem to address fatigue. Why?

• India is the worst when it comes to industrial accidents,
• Indians have a strong dependence on industrial jobs to make a living and,
• There is significant proof available that fatigue and sleep deficits cause accidents/mishaps and even deaths in various lines of work like long-distance truck driving or operating heavy machinery — both risky lines of work with long shifts that make their employees prone to fatigue and losing attention.

Now, there is no way for me to personally verify any of this; I am dependent on whatever public data and facts are available to craft a narrative, but at least this information creates enough empathy to define a problem worth solving.

Define

No matter how much you’ve convinced yourself, you’re definitely going to rush through the Empathise phase. There’s just not enough time to double/triple validate claims. However, if you play your cards right you will have enough information to work with. Let’s work with our previous example on fatigue. We’ve established that a safer working environment is required (claim 1) and one of the ways to do this would be to address fatigue (claim 3). Our problem definition will build on this —

“We need a fatigue monitoring system to help create a safer and more productive working environment.”

Now, you could choose to examine any other problem within this domain and that is perfectly valid. Just ensure that your definition is based on claims you’ve established as part of your initial groundwork. Follow up with simple heuristics to set up the next phase of the process —

• Who are we doing this for? In this case primarily for the employees but also for the employers.
• How will we do this?
• What’s our measure of success?
• WHAT IS THE ONE KEY THING YOUR PRODUCT DEPENDS ON?

Ideate

Here’s when you start answering the “how”. That is, now that you have all your information, what are you going to build? For our case, should we build a monitoring system? Or an alarm for the employee? In each case, what’s our measure of success — waking up the driver? Logging data for employer? Most importantly, what does this all depend on?!

Hackathons are weirdly efficient at product validation and creation. There are only a finite amount of things you can prove and show in, say, 3 minutes so you must pick the most important one. In our example it is the fatigue monitoring system because every other aspect of the product — the logs, the alarm — depends on the fatigue detection working. Therefore, you must build it and ensure it works for your demo. If it fails, the rest of the product is not convincing anymore.

Too many times teams will either botch the one main feature that holds the product together or will build 17 different features (“feature bloat”) that confuses the judges because they lose the message that the team was driving towards. It’s a very simple thing — do one or two things and do them bloody well. It’s the hallmark of all great products. Hackathons are no different.

Prototype/Test

Now is the time to build. Pick your tools for the trade — in our case we went with OpenCV and dlib for keypoint detection — and start building. You might find yourself drawing out sketches/paper prototypes first before the actual product and that is OK. Use them to bounce between your ideation/definition/empathy stages and, if possible, leverage the help of mentors and experts at the event to give you more insights. Your solution will develop and “clean up”, following which you can get to business. I combined the Prototype and Test phases because hackathon pitches end with a prototype but if you ever feel like extending the project’s shelf life beyond 24 hours then you’ll have to explicitly test with your audience of choice.

How do you solve a problem at a hackathon?

We’ve learned how to pick a problem worth solving and how it works at a hackathon. But now to specifics — what will win you a hackathon? In an ideal world an e-service, a portal or a low-tech solution could provide benefits to millions of people but it would never win at a hackathon. Why? Because there’s no technical rigour to it. There’s definitely work that goes into it, no doubt, but it will never get you the plaudits for elegance of solution or the attention that you need to generate at big hackathons. I learned this the hard way.

You always build for the demo. Always.

At HackingEDU we decided to build this lovely portal where all the user saw was a natural language form stating “I want to learn about X and I have Y minutes available.” Very clear problem addressed about people having no time to learn things and multiplicity of information on the internet. Our solution would score and pick out the best links worth your time. Everything worked and looked pretty.

Except that there were 140 teams in the room and it was an exhibition style layout. Judges and teams were clamouring at tables that had big exhibits or multiple monitors or gadgets like VR headsets while our table had a sad MacBook with a browser window open. There was no shock value to our hack. So even when I tried to sell the product to whoever came visiting I knew I was working against the tide; the visitor attention span was barely a few seconds and it wasn’t a product that, at least on limited glance, made them go “Holy F*ck.”

Naturally, we didn’t win. Could we have made a scene out of it? Surely. Ever since that event I’ve been clearer on the final phase of a hackathon — the execution. You don’t just build “a” product. You remind yourself that it is, after all, a show and tell. People must be wow-ed, regardless of whether you pitch it right or not. Whether it is an API mashup or a legitimately world-shaping solution, its shock value is the only thing that can make an immediate impression even before you’ve had a chance to explain it. Take this to heart.

Using your time wisely at a hackathon

Time is a finite commodity at a hackathon. You think you’ll be ready to go once your packages are done installing and boom — half the hackathon is over. You’re falling asleep, food’s not going to be served for another two hours, someone’s nicked the event supply of Red Bull and now you’re sleepy, miserable and have done no work.

Please don’t let this be your story.

At a 24–48 hour hackathon you will never need all the time provided. Unless you’re on a quest to publish a production-ready application with proper code, ready to hit the market the moment the hackathon ends then, sure, go ahead. But building a proof of concept should not kill you off.

Here are a few things you should do —

1. Own your responsibility. If you’re coming in solo as a dev/designer, have all your tools installed and ready to go. Starter kits, software, whatever you think you might need. Yes, it is a non-exhaustive list but I, for my life, never want to see another person downloading and compiling software as big as OpenCV on the day of the event. It is painful to watch. Do it at home, resolve your errors and be ready to work. If you’re coming as a team, decide what tools/hardware you plan to work on and prepare those ahead of time.
2. Take the design thinking process seriously. It will help you easily squeeze out the right questions to answer and, subsequently, effectively split tasks amongst your team members.
3. Task allocation and accountability is prime. Know before you jump in who is going to do what. If someone needs to work as a PM to hold the team together, do that. I usually take charge of that role for a few reasons —

• It keeps us on message if I can control what we’re building and why we’re doing so,
• It allows us to keep track of how far in we are at any given point of time and adjust goals accordingly,
• It allows us to collectively be clear on what are priority features and what are stretch features (throwaways that look good/add spark but are non-essential to the demo.)

I like running a tight ship for my hackathon crew or being on one. Setting time markers for goals allows everyone plenty of time to rest and recover.

Nailing success every time — a counter-intuitive approach

Having spent enough time in the game a lot of this is second nature; I usually have a stable team I compete with and we are clear on what we need to do in terms of ideation and execution. However, it is possible that it still might not get you a win. Some counter-intuitive approaches —

1. Build with new tech. Everyone is building mobile apps/web apps at hackathons. There’s no way to actively distinguish yourself from the others. Yes I am being dismissive, especially given the things you can now do with mobile and web but 70–80% of the hacks are not utilising this. We’ve resorted to actively using new tech like Computer Vision or demonstrable machine learning (not enough to claim machine learning :) ) in all our new projects, or hardware if the hackathon demands it. Not many people can replicate it and we are almost always memorable at the end of the event.
2. Craft your final product and pitch to hit the judging markers. If a hackathon grades Technical Rigour at 40% and Idea at 10% you know that you could build anything crazy as long as it was novel and creative, regardless of impact. If the focus is reversed i.e. Idea is 40%, Technical is 10% then you know that harping about how your neural networks are great won’t get you a win. Talking about the problem, the context, why it matters, how you solve it and how you do it better than status quo will be the clincher.

Conclusion

Wow, another long post in the same night. I should’ve done this much sooner.

I’ve shared with you what I know about hackathons. How I decide what to build, how we manage time, how we ensure that we’ll at least win something. I sincerely wish whoever reads this will find this useful and win hackathons utilising something that I might have written here.

Feedback/comments welcome! I’m available on Twitter and Facebook.