Are you afraid of hackathons?
A hackathon is a great opportunity for the team to switch gears, take a break from the routine, and do something innovative or something that they don’t usually get around to.
We held our first hackathon at YouScan in 2016, which has become a tradition. Now, we hold hackathons almost every year, and during this time, we have had both technical hackathons and hackathons dedicated to GPT — and whatnot :)
As the Head of Product, I had the task of organizing our latest hackathon. One thing I’ve learned is that a hackathon’s success relies on good planning. Below, I’ll share the insights, tips, and challenges we faced along the way. I hope this will inspire you to host your own hackathon — and help you keep your sanity intact while doing so 🙃
Why do you need a hackathon?
This is a key question to think about in advance: do we want to do something innovative, do we want to improve some part of the product, or is it important for us to quickly learn a new technology? This determines the topic of the hackathon and the evaluation criteria.
For example, last year, we wanted to start using GPT models, so we organized a thematic hackathon. Participants tried different ways to use GPT in YouScan, and we chose the most promising idea. Now, we have a smart assistant.
This year, we wanted to take a break from the flow of important tasks, so we decided to let the team work on any customer or business problems that would be interesting to solve.
Who can participate?
At YouScan, hackathons are voluntary, but we do our best to get more people from different teams to join because it’s more fun. Our hackathons are attended not only by developers, designers, and product managers but also by CS, Sales, and anyone else who is interested. That’s great because this diversity helps us look at problems and solutions from different angles and perspectives.
We still have the majority of participants from the development team, but we’re working on it, and we already know some hacks to attract more people. For example, for teams that work with clients, it’s very important to know the dates as early as possible to plan a minimum of meetings and calls for those days.
In my experience, what puts people off the most is their lack of understanding of how they can contribute to the hackathon if they don’t code or design interfaces. Therefore, my advice is to tell them how else they can help their team win the hackathon: test prototypes with customers, do analytics, define use cases, develop a market entry strategy, etc.
Organizer’s checklist
- Choose dates, set a timeline, and announce it all in advance. The sooner, the better; before anyone plans a vacation.
- Decide on the topic and evaluation criteria. We have a time-tested set of criteria that we further adapt to each hackathon:
1. Business value 1–5 points
2. Readiness and feasibility of implementation 1–5 points
3. Quality of the prototype 1–5 points - Select a jury that will be able to evaluate the teams according to the selected criteria.
- Indicate restrictions on the size and composition of the teams. Such restrictions are especially relevant for small teams so that you don’t end up with two giant teams competing. Pay attention to bottlenecks. For example, if you have few backend developers, limit the number of backenders on one team.
- Create a space where you can start sketching out ideas for the hackathon in advance. We use a table in Notion.
- Choose prizes.
- Create a channel where you will post news about the hackathon and where participants can collaborate and exchange ideas.
Timeline
Kickoff
On the first day, we gather the entire team for an introduction. We encourage even those who are still unsure or just want to observe the process.
💡 I strongly advise holding a light brainstorming session during the intro in any format convenient for you. For example, ask everyone to sketch as many ideas for your hackathon topic as possible on a whiteboard. This will help people get involved in the hackathon and guarantee that more people will participate.
In the afternoon, we hold a pitching session where everyone can share their idea and get their colleagues interested in joining the team. We collect a list of ideas for pitching in the Notion table.
Then, we give people time to think and communicate, and on the morning of the second day, we form teams. Organizing such events in distributed teams is a painful question for many people. We don’t regulate this point, but I’ve noticed that those who go to the office and those who work remotely often join different teams. It seems more convenient for everyone, and we don’t mind.
💡 Ask the teams to choose catchy names. It’s more fun and easier to cast votes later.
Working on projects
We allocate 2.5 days to work on projects.
💡 Encourage teams to seek advice from experts within the company. For example, jury members can tell you about gaps according to some evaluation criteria.
The final of the hackathon
We hold project presentations and voting on the last day, around noon. Voting usually consists of two parts: the jury and the audience vote.
To determine the winner, we use a system similar to the Eurovision Song Contest: we convert the scores of the audience and the jury to a scale from 0 to 12 points based on a ranking, where the highest score is 12 points, the second place is 10 points, the third place is 8 points, etc. The final scores of the audience and the jury are summed up to determine the winner. The process is a bit complicated but fair, so if you come up with a better way, please contact me 👋
Is there a life after a hackathon?
It’s very difficult to make something ready to launch within 2–3 days of a hackathon. That’s why we used to face the fact that very hot ideas after the hackathon either didn’t appear in the product at all or appeared years later. After all, everyone returned to their current tasks after the hackathon.
The last time, as an experiment, we set aside an extra week to finish everything we could and launch it to our customers, and we liked it.
To be honest, we certainly haven’t finished much in a week; most projects took 2 weeks to complete, and some had to be postponed. But we have already added 5 out of 7 improvements to the product.
There are also disadvantages to this approach. Usually, we work on something we have thought about in advance and discussed several times. After several iterations, we have come up with the best option and considered the nuances. At a hackathon, the process is more chaotic, and time is limited, so we had a rough time finalizing our projects. At first glance, it seemed easy to release, but many curious and controversial things came up in the process.
Next time, I plan to take a break for a couple of days after the hackathon to discuss the projects with the teams, plan the scopes and detailed work plans, consider the impact on other functionalities, and so on.
Final words
For us, hackathons are a great combination of interesting and productive experiences. I’d be happy if our ideas were useful to someone! And we are already preparing for the next hackathon, so stay tuned for new hacks.
