Crash Course: How to Organize a Hackathon team

🗺️ Hello, World!

This post will talk about how to organize a hackathon team that can create a clear value proposition, decide on feature sets, and complete a project.

I have used the methods described in this article to win four major hackathons in the blockchain space, including one where our team competed against 18,000 participants. Many of these ideas can be found in the field of design thinking.

Intro:

This post addresses the following three questions:

1. What is a hackathon?
2. How might we improve workflow for a hackathon team, and effectively build a successful MVP in a hackathon?
3. What are the strategies that winning teams use to execute and deliver a winning app without running into organizational roadblocks?

What are hackathons?
Hackathons are events where teams compete under a deadline to create a minimum viable product that solves a real-world issue. They are usually hosted on weekends and last around 48 hours. During COVID-19, most were hosted online and lasted one to four weeks.

Hackathons are a great place to:

1. Learn new skills by trying new things in a focused manner within a bounded time environment.
2. Meet new people, network, and bond with like-minded individuals; almost like a guild.
3. Create projects in a team environment to showcase on your resume.

Hackathons offer:

1. Training in the newest tools for a competitive edge and education.
2. Rewards, both social and financial.
3. Networking and job opportunities with companies in target industries.
4. “Swag” aka company-branded items like coveted t-shirts or stickers.
5. Lots of food and refreshments.
6. Community.

What’s in it for the organizations that sponsor hackathons?
Organizations sponsor hackathons to encourage developers to build on their platforms and explore new applications for their technology. They are a form of marketing, ecosystem evangelism, and possible recruiting all rolled up into one. Many companies and notable services were started as minimum viable products (MVP) in hackathons.

Overview

Pitfall: Not finishing or even starting a project because of poor organization.

The biggest challenges for teams in hackathons are:

1. Finding a team.
2. Finding and agreeing upon a compelling problem to solve as a team.
3. Finishing the project on time.

If a team agrees upon an organized system to tackle the event, they will increase their chances to complete the project, and possibly win.

The following twelve steps will aid your team in successfully planning a project during a hackathon:

• Pre-hackathon preparation
• Forming a team
• Reading this article as a team
• Breaking down the hackathon schedule
• Finding a problem
• Creating the design statement
• Prototyping with a storyboard and dividing the storyboard features into tasks
• Sorting tasks into priorities
• Timeboxing the tasks
• Checking in at relevant intervals
• Crafting and practicing your pitch and demo
• Create and revise your project’s documentation

The two keys to a successful hackathon team are to:

1. narrow the team’s focus and
2. have the team wholeheartedly agree to all of the above steps

The more coordinated the team, the more efficient they can be with their time.

Pre-hackathon

You must commit to your decision to join the hackathon and build some cool stuff. Do not get caught up with “impostor syndrome” and feel like your technical skills are not good enough to participate.

Pitfall: Suffering from imposter syndrome.

What is imposter syndrome?
Imposter syndrome is when a person feels like they are not adequate to participate in an activity or organization.

Even if you don’t know how to program, there are things you can do to contribute to your team. You can quickly learn markdown and help create documentation. Clear documentation is often a judging criterion, as well as useful in crafting a winning pitch. If you have experience in a particular problem of interest to the team, you can serve as a domain expert and help create the requirements for the MVP. More on domain expertise later.

The great thing about hackathons is that the participants won’t judge you for being a novice. Participants are more likely to encourage you and point you in the right direction than to make any sneering comments.

In tech, everyone is a beginner at something.

Pro-tip: Use hackathons as a safe space to take bounded risks, learn something new and grow.

Hackathons move fast. The more you research the tools you’ll use beforehand, the better you will do, even if you are not an expert.

The key things are:

1. Don’t suffer from imposter syndrome
2. Do some research on the hackathon, like its purpose, the tools used, companies sponsoring, etc.
3. Show up and go for the win.

Pitfall: Avoid being the person who comes unprepared and not knowing what is going on. It will slow down the team and prevent you from getting the most out of the event.

Forming a team

Form a team based on the following:

• Strengths and skills
• Common interests in ideas
• Group dynamics
• Whether you all aim to have a completed project or not

Here are some questions everyone on the team should ask themselves before joining a team:

• Do you aim to present a finished MVP by the end of the hackathon?
• Are you more interested in socializing or completing the project?
• Do you have domain experience to help find a real-world problem relevant to the event?
• Do you think the team is interested in the said domain?
• Do you have the technical skills to develop a solution in the domain using the tools permitted or encouraged in the hackathon?
• Do the team members share an interest in a domain that aligns with the purpose of the hackathon?
• Can you get along with your teammates for the length of the event?

What is a domain?
A domain is a market or specified sphere of activity or knowledge. Domains can be supply chain management, healthcare, beauty parlors, online game streaming, developer tools, football card trading, etc. If other people are doing it and there is an activity and community around it, it is a domain which may have problems that can be solved.

Pro tip:
The more specific the domain, the better. One could pick healthcare or choose a more specific and focused domain like obstetrics patients within the first trimester of a normal term. This will help focus your search and make it easier to find a problem, target users and solution.

Pitfall: Make sure the team agrees upon the domain for which they wish to seek a problem before proceeding. Not agreeing on this will create tension, confusion and arguments within the team later on.

Breaking down the schedule

Once you pick the team, divide the hours into phases of planning. Portion a rough time estimate to bound the discussion time for the following:

1. Discussing the team aim: completion or socializing
2. Decide what prizes you’d like to compete for if available
3. Reviewing this article together as a team
4. Discussing the strengths and skills of each teammate
5. Discussing any domain experience and problems
6. Creating the design statement
7. Whiteboarding and prototyping
8. Deciding what features to keep
9. Code!
10. Craft the pitch using the design statement.

Pitfall: Many teams spend the entire hackathon arguing about the first six parts, so they don’t get much done.

ProTip:
The first six steps are critical to agree upon quickly. Try to bound these to about 1–3 hours MAX. If you can get these done, then whiteboarding, feature decisions, coding and pitching will become clearer and more straightforward.

Finding a problem

Great! Now you have a team, and you all agree on the specific domain to search for a problem. Start by looking for real-world pain points.

Here are some questions to consider when looking to find a problem to address:

• Is the problem a real-world issue?
• Are you focusing on a real user?
• Can we offer a real solution to this problem within the time constraints of the hackathon with a barebones MVP that meets the objectives and theme of the event?

If all of the above are true, then your team has its problem.

What is a real problem?
A real problem is an issue that affects some group of people in the world where an MVP can roughly address it. A good indicator that the problem is real is if the domain expert has experienced this issue and can recall it in great detail. This will aid in the design of features later on.

Pitfall:
Make sure the team agrees upon the problem they wish to address before proceeding. Again, not agreeing on this will create tension in the group later.

Design Statement

Great! The team has done the following:

• Understood the domain
• Agreed on a problem within that domain
• Deeply understand the problem after discussion
• The team agrees that it is a real problem worth addressing

Now it is time for a design statement. A design statement is a more narrow definition of the problem by making the following concrete:

1. What problem are we solving?
2. Who is the user that is suffering from the problem?
3. What will the situation look like for the user when their problem is addressed?

The design statement explicitly bounds the problem. Notice that there is NO talk of HOW the technical implementations will be undertaken — just the bounding of the problem.

The design statement template is the following:

How might we improve (a problem in the domain)_____ for (user)__, so that (user-focused outcome)_____?

ProTip: Use this template!

Pitfall: Avoid speaking about technical implementations during this step. Your goal is to clearly define the problem, not force a specific technology to a problem

Why are design statements important?

Design statements are a north star to:

• keep the team focused during the entire hackathon
• keep the team focused during the entire hackathon
• keep the team focused during the entire hackathon

Pitfall: Not having a clearly defined and articulated domain, problem, and user will create roadblocks when deciding to develop features.

Without a clear definition of the problem and of which type of user has it, teams can fall into the trap of talking past each other when it comes time to pick MVP features. Problems can affect multiple users.

Choosing which user in the problem to address makes the feature set and user journey much clearer. This will reduce the amount of tension and possible arguments that can blow up your team. A clear goal saves A LOT of time.

Pro Tip: Do not proceed until your team can, in one sentence, define your design statement.

Pro Tip: Use the design statement in your documentation and to start your pitch.

Prototyping with storyboards

Here we make our solution more “real” by breaking it down to a set of screens. We also want to create a list of TODO’s, aka your project’s backlog.

Prototyping Step One:
Focus on the UX/UI with a storyboard first. Use this to map out the user’s journey through the application. Use markers to quickly sketch all the screens that the user will see in order. Mark which functions each user interaction prompt (button, slider, etc.) will perform.

Prototyping Step two:
Now write down all the most critical features needed to make the screens happen. Make sure every feature added to the list complies with the design statement.

Use sticky notes to come up with a list of tasks and features derived from the storyboard.

Timeboxing

Any sticky notes, aka features, that do not add value to the user by addressing the core problem, are a big waste. The clock is ticking, so use the design statement to bound the problem and its MVP solution.

Now that the team has a list of features bounded by the design statement, the team can divide them into the following three groups.

• Most critical group
• Stretch goals group
• Not included group

As a team, review each feature and ask: Does this feature align with the design statement?

If the features are not aligned to the design statement, put in it the “not include” group. Do not include this feature.

If the feature passes, ask: Will the application not work as a rough MVP without this?

If the application does not work without this, then put in the most critical group, it’s an essential part and must be done first.

Everything else will be added to the stretch goals group, which are nice to have if time permits.

ProTip: During hackathons, people will try to add tech just because it’s cool. Make sure you can accomplish your goals first and finish the MVP, before trying to add “nice to have” features.

Check-in

Make sure to check-in at regular intervals to gauge the progress of your team. Make sure you take breaks to assess who is blocked with a task and needs help.

If it’s a weekend hackathon, hourly check-ins are useful. If it’s a monthly hackathon, daily check-ins make more sense.

Focus on getting things working first, then make things pretty later.

Crafting the pitch

First, look at what criteria are being used to judge your project. Make sure that you meet all of them.

Now, use a design statement to craft your pitch. Start your pitch with the design statement, since it clearly frames the problem, user and solution. Next, describe why this is an important and real-world issue within the context of the hackathon. If you are appealing to sponsors, make sure this part appeals to them. After that, provide deeper yet succinct descriptions of the problem, the user and the solution.

Make sure to leave enough time to walk through your application. This section should take the bulk of your time. Walk through your application demo and describe the user journey from the perspective of the target user.

Close out the talk by describing the implementation you used, specifically mentioning the technologies the judges sponsor and what you liked about them.

Pitches are limited to a strict time limit. Make sure to practice your pitch several times before presenting to the judges. This will help you catch any kinks in your code which you should address.

Documentation

Excellent documentation helps judges evaluate your project. It also makes for a great marketing tool for future job prospects. You can use your pitch as your documentation.

Start with a short one-sentence description of your app. Aim for something simple like “Win NFT episodes from your favourite Podcasts” or “Collect, own and trade football cards to build fantasy teams that earns money from weekly competitions.” Then add your design statement and explain your project, similar to your pitch.

Make a small investment of the team’s time and include a video demo of your app. Use it as a walkthrough to show your app from the user’s perspective.

Lastly, include a system diagram of how the different modules interact with each other. Give a brief description of the purpose of each important module. Make sure to include any setup information.

If you have digital mock-ups of the front end, add those.

That’s All Folks:

Good luck with the hacking! BUIDL ON!