How to Organize a Project in a Hackathon

Intro:

This post addresses the following two questions:

How might we improve workflow for a hackathon team, and effectively build a successful MVP in a hackathon?

What are the strategies that winning teams use to execute and deliver a winning app without running into organizational roadblocks?

Overview

There are the following seven simple steps to successfully planning a project during a hackathon:

1. Pre-hackathon preparation
2. Forming a team
3. Finding a problem
4. Creating the design statement
5. Prototyping with storyboards
6. Timeboxing tasks
7. Checking in at relevant intervals

Narrow the team’s focus and have the team wholeheartedly agree to all of the above steps. The more coordinate the team, the more efficient the team.

Pre-hackathon

Deciding to join a Hackathon

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

Do at least some research on what is involved. Then show up and go for the win.

Preparing for the Hackathon:

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 fully participating in the hackathon.

Expert tip: Read relevant materials beforehand.

Forming a team

Form a team based on the following:

1. Strengths
2. Interests in ideas

3. Group dynamics.

Some questions to consider when forming a team:

1. Does any of the team member have the domain experience to help find a real-world problem relevant to the event?
2. Does any of the team members have the technical skills to develop a solution in the domain using the tools permitted in the hackathon?
3. Do the team members share an interest in a domain that aligns with the purpose of the hackathon?
4. What domain experience does the team have?
5. Is the team interested in that domain?
6. Can the team combine that domain experience with the theme of the hackathon?

Finding a problem

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

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

1. Is the problem a real-world issue?
2. Are you focusing on a real User?
3. Can we offer a real solution to this problem within the time constraints of the hackathon in a very barebones MVP form that meets the objectives and theme of the hackathon?

If the above are true, then your problem might be a great candidate for a problem!

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

Design Statement

Great! The team has done the following:

1. Understood the domain
2. Agreed on a problem within that domain
3. Deeply understood the problem after some discussion
4. 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 concret:

1. What problem are we solving?

2. Who is the user that is suffering real pain from the problem?

3. What will the situation look like for the user when the user’s 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 _(problem in the domain)______ for _(user)___ , so that _(user-focused outcome)______?

Expert Tip: Use this template!

Why are design statements important?

Design statements are a north star to:

1. keep the team focused during the entire hackathon
2. keep the team focused during the entire hackathon
3. keep the team focused during the entire hackathon

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 markers to quickly stretch all the screens that the user will see in order.

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.

Timeboxing

Any sticky notes, aka features, that do not add value to the user by address the problem is a big waste. The clock is ticking, 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.

1. Most critical group
2. Stretch goals group
3. Not include group

Use the question; Does this align with the design statement?

If the features are not aligned then put in the “not include” group. Do not include this feature.

Next, use the question: 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 a critical part and must be done first.

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

Check-in

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

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

That’s about it!

Good luck with the hacking!