Perttu Lähteenlahti

    Designing a winning hackathon concept

    Using a service design mindset to win hackathons

    The nature of hackathons has changed during the past years and hackathons are no longer pure 24h+ coding sprints. Of course, coding still plays a large role in hackathons, and nicely coded things are still highly regarded. But nowadays the service concept behind the hackathon project, design of the service, and business model also play a key role. Service designed solutions in hackathons are now more common than ever. But what is service design and how do you design service in a hackathon?

    I decided to put together a small guide on how to do successful service design in a hackathon and create a good concept (service idea). My method focuses heavily on the problem-solving aspect of it all because all good services and products always solve a customer’s problem. The following process is based on how I’ve done things in hackathons, and it has proved to be very successful in a variety of hackathons. By using these methods I won most over 40+ hackathons.

    Choose whose problems you are solving

    “We want to make things easier for elderly people

    Before rushing into the problem, it is best to choose whose problems your service is going to solve, the targeted customer group of the service. This helps in narrowing down problem and makes it easier to develop the service concept for the problem. It’s best to settle on a target group even if have already come up with a problem you are going to solve.

    The multiple ways of finding a suitable target group, and they could easily warrant for a separate article. One easy way to pick a target group is to pick up target group you yourself are part of, e.g. student, elderly person, etc, and develop that into a persona. Using yourself as model of a potential customer is heavily biasing, and can lead to false assumptions for example in the customer’s capabilities. In the context of hackathons, this is however not that critical. If you want to avoid this and do the things in a bit harder way, you can focus on a group of people you are not familiar with and do research on them. Pick for example city planners and interview them in order to understand their problems (this is what we did in one hackathon).

    Find a problem to solve

    “We plan to make commuting easier for elderly people”

    After you have settled on the target group it’s time to find out their biggest problem by either observing their behavior in a context or interviewing them. If you’re using yourself, think about the problems you’re facing daily. What problems do you face daily? Is there perhaps something you that takes considerably large amounts of your time, money, or other resources? In what context does this usually happen? The context in this case could be for example commuting.

    The best option is to pick one concrete and recognizable problem, that is solvable in hackathon’s time frame. If your target group is, for example, the aforesaid elderly people, and their context is commuting, the problem you’re trying to solve could be for example how commuting could be made easier for elderly people. When formatted as a problem statement: “How to make commuting easier for elderly people”.

    How does your service solve the problem?

    “We plan to make a crowdsourced helpline for elderly people, that makes their commuting easier”

    After finding and understanding the problem, it’s time to come up with a solution to it. Now I can’t give any specific tools for coming up with solutions, but I’ve personally felt that brainstorming is a good method to start with. The most important thing in coming up with the solution is to make it simple and doable in a hackathon. The solution should also be quick and easy to comprehend. In hackathons, you have to pitch your idea, and usually under three minutes. During this three minutes, you have to be able to describe the problem, who it affects, how you have solved the problem and how does your solution work. Therefore a simple service solution is oftentimes better than a complicated one in a hackathon.

    You should try to fit your service solution into one sentence, which should describe the problem, your target group, and your solution to it. To give an example we can use the elderly people again. One way to solve their problems in commuting could be for example a crowdsourced helpline, where the elderly can call and receive instructions on commuting. When put in one sentence: “We plan to make a crowdsourced mobile helpline for elderly people, that makes their commuting easier”.

    How does your solution work?

    Customers, customers’ problem, solution to the problem → the service built around these that works like this.

    Service is always a combination of multiple different pieces, where the problem and the solution are forces tying everything together. In hackathons, you rarely have time to think about the whole service structure but you do have enough time to make a light customer journey. The customer journey, in this case, means a description of how the customer finds the service, how the service solves the problem the customer is facing, what is the role of the service after this, and how is the service different from other for example.

    Creating a customer journey is a rather broad task which brings out the benefits of a multidisciplinary team. Creating a simple but easily understandable customer journey is a lot easier with a versatile team.

    In addition, it might also be beneficial to come up with a business plan for the hackathon concept, as that is also usually used as a way to evaluate the team’s idea.

    Conclusion

    With these instructions, it is possible to create a winning hackathon service concept. It should, however, be noted, that concept by itself is rarely enough and should be accompanied by a demo that demonstrates key elements of the service. Creating the service concept and technical demo of it has to be one in parallel, which makes hackathon concepts with both a good service concept and cool demo, a rare sight. These are however often the solutions that end up winning.


    Perttu Lähteenlahti

    Personal blog of Perttu Lähteenlahti. For more developer oriented posts checkout perttu.dev