Tips, from the perspective of a mentor and judge, on how you should make the best use of your time during a hackathon

Hackathons are awesome. In the short span of 36-54 hours, you and your team work tirelessly to solve problems and create amazing solutions.

Occasionally, promising solutions even spin off into standalone companies, e.g., teams that win Startup Weekend Singapore. Heck, even my first startup was conceived during a hackathon many years ago.

Interestingly, companies have also started organising hackathons as a way to hire, e.g., Grab’s AI for SEA (powered by Padang & Co), DBS’s Hack2Hire (powered by HackerRank), and Shopee’s National Data Science Challenge (powered by Kaggle).

In short, hackathons are an exciting part of the startup ecosystem not just to spur innovation, but to open up opportunities for people who may not normally have access to.

Over the years, I have transitioned from being a participant to being on the other end of the pitching stage as a judge and a mentor.

After my observation (and a bit of free time), I was motivated to write this guide in hopes of helping participants enjoy their sleepless weekends hacking away.

Who knows, you might also stand a chance of being in the top three or even find a job in your next hackathon?

1. Understand the problem

Let’s start with the most obvious tip. What does it mean to understand the hackathon’s problem? For starters, you should know what the challenge statements in the hackathon are if the hackathon is themed.

The next step is homing in who exactly will benefit from your solution/product.

Typically it’s not enough to have a top-level description of who you’re helping – you gotta know their persona. Identifying personas is something UX designers are very good at.

I’ve seen UX designers winning competitions from solely explaining how their solution transforms user journeys with a high-fidelity mockup.

As such, it’s often important to talk to the stakeholders involved in the problem. If the hackathon is themed, the organisers will usually invite individuals or representatives who can share pain points in detail. They might even be a roaming mentor during the hackathon.

Maximise your time and ask mentors the right questions, focus on their pain points rather than running solutions by them.

The chances are that you might over-optimise and create biases when you pitch a solution before you have an opportunity to understand the problem truly.

If the hackathon requires you to define your solution, it’s also important to make sure that you understand the problem inside and out by talking to more people, e.g. target users.

In addition, from my experience, the best teams (or at least the designated business person) know the problem that they’re trying to solve inside out and weaker teams struggle with understanding and articulating the same problem.

2. Check your ego at the door

Even when a team understands what problem to solve, they may not necessarily arrive at the same idea to solve it. A very common reason why teams don’t make it to Day 2 is when the teams fail to focus on a single problem, fail to arrive at an agreed-upon solution to tackle the problem.

Also Read: [Discussion] Are hackathons a waste of time? Are there better alternatives?

More specifically, conflicts occur when there are two (or more) people in the team try to dominate the direction of the team and insist that their respective idea is the best. This results in endless discussion with neither side budging. I have seen teams taking more than half a day to debate.

There are three ways to solve this:

1. If you find yourself the one trying to convince your team that your idea is the best, keep your ego in check and come to a compromise with the team. Commit to taking 1-2h to research the problem and everyone present their ideas. Whoever sounds the most reasonable wins.

2. If you find that your teammate is giving the team a hard time, consider 1). Otherwise, kick the teammate out if he/she continues to be a source of indecision and annoyance. Better cut your losses early.

3. Find a mentor as a sounding board and let him/her decide whose idea is the best. One of the roles of a hackathon mentor is to ensure that teams work well, and they do not end up disbanding over conflicts. Also, agree on just one mentor. Don’t look for another mentor just because your idea lost.

If it doesn’t work out in the end, consider disbanding altogether and find other teammates. It’s better than sticking it out with a discordant team and having a bad time all weekend. Sometimes, you gotta let go, y’know?

3. Get validation

Now that you’ve understood the problem on a deeper level, what’s next? A solution is not exactly a solution if no one wants to use it.

For consumer solutions, you can always call up a friend or two (or your village) and run it by them to see if it’s something that works. For B2B-centric solutions, there’s absolutely nothing stopping you from picking up a phone and harassing/engaging/asking people on LinkedIn.

Not only do you get to unbiased feedback, but you might also end up getting validation from your would-be users/customers. The only challenge is that you’d have to message hard because it’s the weekend after all.

For most of the hackathons I judge in, validation gives you extra points. I recall watching a pitch where a team reached out to large institutions, identified decisionmakers, and got a letter of interest. They won.

It’s really how hard you hustle for that “yes that’s something I want to use”.

4. Tell a story, not the product features

I see this happening very often with teams which are solution/product-centric. During the pitch, I often encountered teams that spent most of their time describing their solution and product features rather than how the solution solves a particular problem.

Take a pitch for the Grab app, for example. You can do it two ways during a hypothetical pitch:

1. Problem centric: “The Grab app helps users save time hailing a ride and ensures that they reach their location in time. This is in contrast to waiting by the roadside to hail a taxi without any certainty, or spending a long time queuing at the taxi stand.”

2.Product centric: “The Grab app lets you input your current location and your intended location and then contacts the nearest available vehicle to come to you. You can keep track of the car using the phone’s GPS. When it arrives, you get on!”

These two pitchers have almost the same number of words (45 vs 41), but one pitch is more meaningful. Teams often fall prey to the shininess of their product. Don’t let that team be yours.

But wait a minute. Does it mean that there’s no point in creating a product? Yes and no.

Sometimes, if the judging rubric does not involve a completely functioning prototype, it may be better to consider a high-fidelity mockup that shows the judges what you’re solving, rather than what you’re telling.

Also Read: Go-Jek launches a new hackathon to solve everyday problems in the lives of Indonesians

This evens the ground for non-technical teams. I have seen high-fidelity mockups beating fully functioning websites, by the sheer power of telling a good story and explaining how their solution tackles the problem.

5. Do your homework

During the pitching session, as a judge, I often ask teams whether they’ve seen any solutions out there doing what they proposed, i.e. competitors, and how and why their solution is better.

If they didn’t do their homework, they’d stammer a no. Good teams often do extensive research on the problem and can compare themselves to existing solutions.

It’s also prudent to anticipate questions from judges and prepare additional slides to answer those questions.

Show judges that you know your shit.

6. Practice, practice, practice

As a judge, it is very easy to tell whether a team is prepared or otherwise. Even when they’re tired, you can see the gleam in their eyes and confidence.

Pitching can be daunting since you’re essentially compressing 36-54 hours of work into a 5-minute pitch. Despite that, most of the time, I see teams practising their pitch on the last day, sometimes only a few hours before their pitching session.

Doing last-minute pitch preparation is a bad idea for a few reasons. Firstly, the chances are that you’re exhausted from working on your solution for the past 36+ hours. This means that it’ll be much harder to organise your thoughts in this tired state of mind.

Secondly, when you organise your pitch, you’ll start discovering holes in your idea which may not have been apparent at first. If you’re lucky, you can fix those holes.

If you’re not, these holes surface during the pitch and Q&A. If you don’t fix those holes, it will result in a subpar pitch which doesn’t do anyone in the team and the idea any justice.

Lastly, it’s very easy to develop nerves if you don’t practise enough. This is even truer if there’s no reliable pitcher in the team. Avoid pitching as a team and designate a single person to pitch; the time you spend moving from one person to another should be spent on presenting instead.

The solution to this?

Start early. Your pitch should be developed alongside your hackathon solution, the moment your team agrees on what to solve. This can (and should) happen on Day 1.

Also Read: Smart floating dome, zombie detector emerge winners at Sci-Fi Hardware Hackathon 2016

It’s never too early to start designing your pitch deck. This way, you’re continuously iterating your pitch as the idea is developed into a product. Another plus side is that the pitcher (usually the business person) is hustling along with the developer, which spurs greater team harmony and dynamics.

Good luck, and don’t fu-, mess it up

That’s all folks; this is my take on how participants can experience the spirit of a hackathon.

–

Editor’s note: e27 publishes relevant guest contributions from the community. Share your honest opinions and expert knowledge by submitting your content here.

Join our e27 Telegram group here, or our e27 contributor Facebook page here.

Image Credit: Annie Spratt

The post How to do well in a hackathon: a mentor and judge’s perspective appeared first on e27.