The participants in the hackathon are on a limited time frame. They often work in teams that are new to themselves and are afraid to “fail” the task. As a result, a disproportionate amount of time is spent on secondary things. Here are a number of recommendations on how to notice the problem in time and prevent such a situation.
Step 1: Formulate Long-Term Goals
All hackathon participants come with one goal for the next few hours - to win. But what if it doesn't work out? Is participation in the competition meaningless without the first place?
I always advise you to formulate long-term goals for the team and for yourself, in addition to winning. Learn to work quickly for a result, improve hard / soft competencies, gain experience in a new team, communicate with experts, and receive a job offer. So the motivation of each participant will be higher, and the team's performance will become more effective!
Problem marker: you believe that without a victory after the hackathon, your life will remain the same.
Step 2: get to know the team and try to work in it
It can take a long time to establish communication within the team. Especially if you met just before the hackathon. Therefore, I recommend getting ready in advance and chatting. Define the technology stack, distribute the roles in the team, try to analyze together a couple of tasks from past hackathons - they can usually be found in open sources. The optimal team composition is five specialists with the following distribution of roles: leader, analyst, designer, front developer, back developer.
It can take a long time to establish communication within the team. Especially if you met just before the hackathon. Therefore, I recommend getting ready in advance and chatting. Define the technology stack, distribute the roles in the team, try to analyze together a couple of tasks from past hackathons - they can usually be found in open sources. The optimal team structure is five specialists with the following distribution of roles: leader, analyst, designer, front developer, back developer.
Problem marker: you have never seen your team members face to face, you do not know anything about them, you have no contacts with each other.
Step 3: develop a theme / track strategy
Most likely, an overly simple and detailed task will attract many teams and the competition will be higher than in more complex cases. This is worth considering.
In addition, a detailed description of a problem often contains a prerequisite for a solution. Chances are good that everyone will end up doing the same thing. Better to choose a case that has more freedom. So you and your team will be able to creatively solve the problem, prove yourself and increase your competence.
Problem marker: after reading the problem, you already know what to do, right down to the database architecture.
Step 4: add a working flavor to your solution
You need to find something that will distinguish your team's decision from the rest. It is always surprising when authors talk a lot about the login form, data collection and little about the principle of operation. A hackathon is not a competition to develop simple basic forms. Often, task authors don't need them - they already have an ecosystem of products and tools for collecting personal data. It is better to skip this part or do it at the last moment - unless otherwise indicated in the task, it is not a priority. Take this time to get the basic idea of the solution to work!
Problem marker: The team began to code the solution straight away without discussing its value.
Step 5: work with experts all the time
Several industry experts are always present at the hackathon. I recommend that you learn as much as possible about them in advance and use their knowledge and experience to the maximum - they are here for that. Prepare questions with the team. Ask an expert to evaluate ideas, suggest something from yourself. If you finished the consultation ahead of schedule, then the team did not prepare well for the meeting.
Problem marker: before meeting with experts you have no questions for them, or after 5 minutes of conversation you have nothing to ask.
Step 6: throw in a million ideas at the first checkpoint
CustDev is your everything! If at the first checkpoint a team presents one (!) Ready-made idea of a solution, then most likely you are too narrowly perceiving the problem, and this solution may be very similar to the others. In this case, it will be difficult to separate the solution from the crowd and evaluate it. Do not hurry.
Throw in a lot of ideas first, and experts will help you choose 2-3 most interesting ones. The main question that you need to ask yourself is - for whom is this solution?
Problem marker: you do not know your user or you showed part of a working solution at the first checkpoint.
Step 7: at the second checkpoint, a presentation prototype should already be presented
At the second checkpoint, the teams present the solution and discuss its implementation. But it is often overlooked that a draft presentation needs to be ready so that experts can check it and later evaluate the final result.
Problem marker: The team did not start making the presentation and does not know who will be speaking.
Step 8: at the third checkpoint, you must already present your product as it will be in front of the jury, for a while
. Only a few minutes are given to perform in front of the jury. You need to practice to be able to say the most important thing about your product. Therefore, at the third checkpoint, as an expert, I always ask the teams to perform for a while. It helps a lot!
Problem marker: Presentation or presentation video is not ready.
Step 9: you must be clear about the evaluation criteria
At the very beginning of the hackathon, carefully read and discuss the criteria for evaluating decisions with experts. For each of them, there should be a clear answer in your presentation for the jury to evaluate. Understand, if the work was done, but you did not tell the jury about it, then they will not be able to guess about your success themselves.
Don't waste time describing the problem of the problem - the jury already knows it. There is no point in presenting the team members for a long time and describing your competencies. The main thing in the presentation is the story about your decision, taking into account the evaluation criteria.
Problem marker: you don't know the hackathon evaluation criteria.
Step 10: take judgments and criticism firmly
Of course, experts and juries try to be impartial. But, nevertheless, all assessments are to one degree or another subjective and depend on the presentation of the project and the opinions of a particular jury member. When summing up the results on the tracks, where many teams have entered, 1-2 points from one decision-maker are often determined. Therefore, your team needs to initially achieve a greater lead from the rest. To do this, you need to take into account all the previous tips.
I believe that after reading this article, you will be able to properly organize your work at the hackathon. Good luck!