Ultimate 8 Step Guide to Winning Hackathons
What I learned after 55 Hackathons
Jason Calacanis wrote a post on How to Win a Hackathon — which is a thoughtful read on the topic. After being involved in over 40 hackathons as participant, I thought sharing my experience would be valuable.
I attended my first hackathon in 2012, I considered myself an “ideas guy” at the time, which is someone who has a lot of ideas but can’t implement them. But after the first one, I was hooked. I loved the thrill of having only 24 hours to develop something and the ability to work with great teams of people.
In going to hackathons, I learned a lot, fast. And along the way changed from being an ideas guy to a real programmer, someone who was capable of building my dreams. I ended up participating in a lot of hackathons, over 40 of them (listed here) and won at over 20 of them. The strategies and tactics I learned are below:
I. Getting Started: Find Your Hackathon Mojo
II. Employ These Strategies to Be Part of the Best Team
III. Understanding the Judges Panel is Key
IV. Decide Your Approach: Backend vs. API vs. Design
V. It’s only 24 Hours! Utilize these 5 Design Shortcuts
VI. Learn How to Effectively Validate Your Idea
VII. How Not to Screw up the Presentation
VIII. Winning: Where To Go From Here?
Money20/20 Hackathon: Our team traveled from NYC to Las Vegas and competed against 100+ teams and over 450 developers.
I. Find Your Hackathon Mojo
ENTREPRENEURIAL SPIRIT:
It’s obvious, but you can’t win if you don’t start hacking. Yes its important to go to a hackathon and learn, and socialize with new people. But you should always go into a hackathon with the mindset to win, it’s a competition after all.
From what I observed I found that the best profile of hackers are people who:
- are highly competitive with a hunger to win
- are bored by “just talking about it” and have the passion to see real results
- get energized by pressure deadlines
- fueled by finding like-minded people to ideate and work with
If you’re reading this far, then this probably describes you.
II. Learn How To Be a Part of the Best Team
FORMING TEAM:
Team chemistry and makeup is one of the most important factors not only in winning, but also in making sure that you don’t burn out. To ensure that you have a chance, here are some tips:
- Pitch your idea during the initial pitching session and get folks to buy-in on sharing your vision.
- Join a team that already has a front-end engineer. This is a key role that I’ll describe in further detail below.
- Have a team of friends or previous hackers to participate with. Knowing each member’s strengths and weaknesses beforehand gives you an advantage in preparation and execution.
Caution: In general, don’t join a team solely because of the idea. Ideas pivot extremely fast. But really take the time in the beginning to get to know the team members and talk to other participants. There will be a lot of give and take once the hacking begin.
‘Getting the right people and the right chemistry is more important than getting the right idea.’ — Ed Catmull, previously CEO of Pixar, author of Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration
ROLES:
You should also optimize for the correct roles in the team. Within a team, you should look for:
- Front-End Engineer — Outside of rare exceptions, an obvious position is at least one Front-End Engineer. They are very valuable because front-end engineers carry the design from idea to conception and you need to execute a beautiful UI and UX in only 24 hours. Your team only has one attempt (or a rare second attempt). It cannot be too experimental because it would be difficult to code. It cannot have too many features because there is not enough time to showcase it all during presentation. Just optimize for 1 to 2 primary features to maximize the judges WOW factor.
- Business Development Person — Despite Jason’s viewpoint that business people “have nothing to do at these events, and wind up bothering folks,” a great BizDev person can take your concept to a whole different level. They become the enthusiastic speaker when presenting to the judges, explaining the problem, market size, and user validation.
Our Winning Example — “The Role of a Great BD Person”
In 3 separate hackathons (Smallbizdev Hackathon, ERA Venture Hackathon, and Money20/20) I teamed up with a BD person, Harry, who made the difference between winning and losing. Harry ran a startup on small business lending and wanted to see what hackathons were all about. We brainstormed different ideas, but it wasn’t the idea that I pitched that convinced Harry to team up. It was through our mutual understanding that the mentality and expectation we set for ourselves was to “go big or go home.” His will to win matched mine and he had skills that engineers usually lack. Coupled with a drive to win, Harry was extremely skilled in the following:
- very keen on crafting our business message
- exceptional presentation skills
- adamant about conducting user interviews
- being the voice of reason in many engineering disputes.
We took home $5000 checks from 2 of the hackathons, mainly due to Harry’s contribution.
III. Understanding the Judges Panel is Key (and there are 4 main types of judges)
Know your Audience:
What are the backgrounds of your judges? Are they investors? Are they business development folks? Are they CTOs or do they have an Engineering background? Are they API Evangelists representing their company?
Choose your idea and tailor your presentation based on your makeup of the judging panel. Here are the 4 main types that I’ve identified, and the tactics to consider for each.
- API Judges — Integrate their API in the most unique way. Optimize for the “unused” or “unpopular” functions of their API. They love this because the hackers used a lot of creativity in making a non-core function to be extremely interesting — literally “gamifying” those functions.
Our Losing API Hack Approach — “Just Sticking it On Doesn’t Work”
At the Hack’n Jill Build’n Play Hackathon, one of the judges on the panel was the the StackOverflow API Evangelist. We chose a basic integration at the last minute. The StackOverflow evangelist ended up giving the prize to a different team that used the API more creatively.
Our Winning Hack Example — “Using What you Know”
At The Next Web Hack Battle 2013, the Sendgrid evangelist introduced me to their new Events Webhook. The API functionality triggers when the recipient opens the email. In conjunction with an hosted image, when reopening the email for the second time, the image will be deleted — much like Snapchat for emails.
Based on our knowledge of industry news, e.g. Gary Vaynerchuk talked about being extremely bullish on Snapchat. He predicted that marketers would enable disappearing coupons to demand immediate action from users. By combining disappearing coupon emails with market knowledge proved to be a winning hack. (Shout out to Sendgrid!)
- CTO Judges — You really have to build out the app. Show some good code. Get ready for some Backend / Database / Algorithm questions. Typically they want to know how scalable the tech or the product can be, where the edge cases are, and where it can break. Technical judges think technically, logically, and in depth. They value Conventional Economics over Behavioral Economics. Play to those points — usually having a simple app with tons of customer validation, and/or market analysis will not impress.
- Investor Judges — These guys are driven by business fundamentals. They want to know the market size. They want to know the opportunity for your hack to integrate with their investment portfolio’s ecosystem. Extra points if some other company has done your business model + integration + hack + community combination before. Cite those examples! Historical data in this case measures potential $$$ opportunity.
Our Losing Hack Approach — “Unsuccessful Precedents”
The Mobile Payments Hackathon, the judges were investors in the card reader startup Cardflight which and they were very focused on new applications of their card readers.
We used a concept which combined facial recognition technology to perform three-factor authentication. Because of lack of precedents in this field and we did not have validations, the winner was rewarded on more familiar (or less experimental) business models.
- Business Development Judges — They want to know your app can help with their daily lives, and they can picture themselves as the user. If their family, friends, and coworkers have a problem your app can solve, talk about that! Business Development people are experts in sales and marketing so show them a roadmap of how you expect to acquire customers: whether it’s building a community or a marketplace, scraping a database, or through achieving some viral coefficient.
Also, for these judges, there are some business models that should be avoided, e.g.:
- “Big Company” partnership concepts (generally too farfetched)
- Selling to small businesses (can be very difficult to find the budget)
- Free (not a business model)
Hackathon Examples with Business Development Judges
The following hackathons had mostly Business Development Judges: Hack’n Jill’s Hacksgiving, nytechresponds Sandy Hackathon & Benefit, and Disruptor Cup 2013. Also, because they were close together and all just following Hurricane Sandy, we were able to use the same hack for all of them, improving on it as we went (also a great strategy.)
Our Winning Hack
Previously, volunteers inefficiently went door-to-door to write the needs of the residents of affected residents in Brooklyn. We built a surveying app for volunteers to record the information of people who needed help. Despite winning these hackathons, the judges all voiced concerns about free (“optimistically altruistic?”) model Remember, with business development judges, your project is judged at the level of a more mature business and you need to have a revenue plan.
IV. Decide Your Approach: Backend vs. API vs. Design
Back- End Approach:
Usually this approach doesn’t work. In the short time of a hackathon, you don’t have time to setup a backend. Utilize front-end and Javascript! Everything can be done in HTML/CSS/JS.
Our Losing Hack Approach — “Prioritizing Backend”
At the Spotify Music Education hackathon, one of my teammates decided to build the backend using Node.js, not sleeping for 24 hours to build the infrastructure, and we focused on supporting him. However, because we were focused on the back-end, we neglected to create a fully functional front-end product experience. While it was still a good overall hackathon, no judges questioned us on how we loaded data into our app. They only looked at the front-end user experience, which we didn’t leave time to work on.
API Approach:
If you and your team have plenty of time, go see the API Evangelist. Start a friendship with them and have them teach you about their API.
A sit down session with the Evangelist confirms your app can now be tagged with that API which is an additional validation during judging. However, avoid talking in too much detail with the Evangelists. They prefer to be WOWed during the presentation.
If the API is only available via backend languages, figure out an approach where you can display the data on your app, and you can update the data from your app to the backend.
Design Approach:
Though a front-end developer approach is ideal, If you have no front-end developers in your team, you and your team might want to switch strategy and focus solely on design.
First impression is everything— great UI and UX makes the audiences feel good, and can sometimes lead to “audience favorites” prizes. So if you find yourself on a team like this, focus on the business use case and your presentation.
V. It’s only 24 Hours! Utilize these 5 Design Shortcuts
1. NAMING:
Don’t waste time coming up with the app name. It’s a time waster and it’s difficult to get consensus. Just go with a codename and sudden inspiration will come actually through working on it. You might even fall in love with the codename instead.
2. COMBINE DESIGN:
Use templates and utilize the color schemes that past designers have already perfected. Copy from the great product developers and fuse your own hack concept. Use resources such as:
· http://tympanus.net/codrops/
3. CONTENT:
Skip the sign-in screen. It’s not necessary; it’s a waste of time designing it, and it’s another page layout to have in mind. Start by landing right on the content.
4. TRANSITIONS:
Add a loading gif. It lets the judges know that something algorithmic or data fetching is being processed. It also gives you a few seconds to recover on your presentation notes.
5. PROTOTYPE ONLY:
Use a design prototyping strategy, particularly if your concept is more about a new User Experience rather than backend functionality. Design prototyping strategy provides a great way for creative people who cannot code:
- Cut and paste together designs from Pttrns.com onto Adobe Illustrator.
- Combine features and design layouts together.
- Make 4–5 page layouts.
- Use Invision.com or Flinto.com to wrap it.
Don’t believe me? Check out this webcast from Apple WWDC 2014: Prototyping: Fake It Till You Make It
Our Winning Hack Example— “Prototype User Experience”
At the Financial Literacy Fincapdev hackathon, my partner and I built an Immigrant Benefits and Assistances Reminder application.
We realized that with the judging panel, they would focus on the storytelling and that a good concept combined with some solid design prototyping would likely be sufficient. Both being children of immigrants coming to the US, we told our personal story to convey the importance for immigrants to engage with free courses (ex: English, Computer, Health, or Personal Finance) or services (Food Drive, Free Concerts and Museums) within the community via calendar, list, and reminder features. We spent a lot less time than other teams on our actually hack, but our approach paid off.
Hackathons are not always about tech — and there have been plenty where its not about coding and programming. It’s the hacking and conception of ideas.
VI. Validation
Always, always, validate! Validate the concept before and validate the concept after!
Before Hacking:
This is where business development person is crucial. Unlike engineers, they know the product does not speak for itself. BizDev people know they need to convince people to use it. Assign them the task to get some tallies on the idea and speak with the customers. Type up these notes for the presentation, as it is one of the secret ingredients to your storytelling.
After Hacking:
If the hackathon is a 2-day event, I highly recommend spending the second-day getting out of the building and talking with potential customers again. This time have the BizDev person interview the customer. You can even take pictures of the customer and your team member together. Having at least 2 of these artifacts shows the judge that you:
- Dared to take the next step on customer validation
- Used the Lean Startup methodology in some fashion
- Used a data-driven strategy
- Customer approval and ready for trial
Our Winning Hack Examples — “Talk to Real Customers ASAP”
At the SmallBizDev hackathon, our goal was to build applications to allow business owners to reach out to their Yelp reviewers who may be a domain expert in a particular problem set. In return for a 1 hour consulting session, the customer would receive some sort of discount. Our concept was to bring a modern bartering culture for businesses and their customers.
Our team pitched 6 businesses before we started to code anything. The results came back with local restaurant having problems with their website, a jewelry store needing help with social media, and confirmation that barbershop already exchange haircuts for favors. Our tech was just 2 simple HTML pages; the first page asks for the business name, and what you need help with. The second page fetches Yelp customers that match your needs.
After the presentation, the CTO judges scored us low for lacking in tech innovativeness. However the one Business Development judge convinced the entire group that our research and customer validation really verified why our app was highly resourceful for struggling business owners. It was a low cost way to get consulting, while achieving customer satisfaction and repeatable business without being too technically difficult to use.
VII. Time to Shine: Hacking the Demo
YOU:
Just like a startup, it’s important to distinguish why you chose to pursue this hack. Highlight your experience. Let the judges know about your work and industry experience. (No need to waste precious few seconds saying your names though; your name is on your nametag.)
Stand out from the crowd and dress to impress, or at least to be noticed! If the hackathon consists of mostly techies, I would wear a button-down shirt and a tie. Other people dress really flamboyantly or in a super unique fashion. It helps to be memorable.
Building the Presentation:
For the actual presentation, here are my recommendations/tips:
- Perform a skit to demonstrate where a person might encounter the pain point.
- Do an interactive demo. Involve the audience if your product allows. For example: Text into this Twilio number to find out the answer.
- Ask the audience questions for another level of validation. Or at least be remembered for Audience-Choice award. E.g. “Raise your hands, how many people hate the post office?”
A simple format that has worked well for me is:
· Problem
· Solution
· Market (Who’s the customer, Acquisition Strategy)
· Validation (Pictures with Customer)
· Demo
· Business Model
· Future Rollout
· Team
It’s important to be passionate and practice. What you made in these 24 hours is your baby. Showcase it, be confident and tell everyone about it. Be loud and clear. And never say you did not have enough time. Everyone has the same amount of time.
Despite only working on it for only 24 hours, your hackathon project is often judged on the level of a more mature startup. Be ready for questions like:
- What’s the business model?
- How do you compare to XYZ?
- How do you plan to acquire users?
- How sustainable can it be?
- Is it a scalable project?
- Unspoken question, most judges are also looking for: Can I deem you guys as winners so you and your team have the confidence to continue building this app?
Order Matters:
If you are the 1st team to present, prepare for a lot of different questions because all the judges are awake. After 10 presentations, there will be no more questions. If there is no question, quickly speak up. Continue to create selling points and talk about your user feedbacks. Show artifacts and evidence that you went out to test it. Talk about the results and what you learned speaking with those customers. The time is yours to lose — so maximize it.
For example, when 1 judge asks the question, and 1 of your teammate answers, have another teammate show your PowerPoint slides on Market and Business Model in the background if you haven’t already. It’s your extra time to show the rest of the business validation. Or continue to show the rest of the app feature you have not been presented. Optimize for those time, otherwise the judges are just staring into space.
VIII. Winning: Where do you go from here?
SUCCESS:
My biggest takeaway I have after participating in more 40 hackathons is: it’s the people you worked with that matter the most. It’s the opportunity to test out team chemistry, interaction style, and handle pressure together as a team. The jokes and bantering you guys tell each other during the hackathon, the time spent while eating, or the late night emailing back and forth — are mirrors of what’s its like starting a startup, its just that at a startup, you are now doing that every single day.
After you win with a team, you’ll get to ask yourself, do I really want to do this everyday and turn this into a startup? How can I graduate from Hacker-Market Fit to Founder-Market Fit? How I can turn this hackathon project into a startup?
I’ll plan to talk about that in my next post.
‘Winning isn’t everything–but wanting to win is.’ — Vince Lombardi
Gary-Yau Chan is co-founder and Product Lead of Oz, a content marketing technology company that enables the world’s thought leaders to unlock impactful story ideas at scale. You can also message him on Twitter @garyyauchan.
Gary currently lives in Brooklyn NY. Now he enters hackathons either as a mentor or as a participant upon challenge request.
Originally published at ozcontent.com on February 9, 2015.
