A hackathon is to coding what a marathon is to running. Hackathons bring together coders and designers to work on a problem, or challenge, and produce some result, usually presented in a pitch slam at the end of the event. I have completed three different hackathons with three different teams and won a total of four prizes with them. This post is about how my teams did it.
How do you win? You need to define the “why”. You have to make it clear why what you are going to build matters. Why the hackathon jury should vote for you, why the hackathon participants should listen to your pitch at the end of the event. Technology is fascinating, but building amazing technology that has no reason to exist is useless. To find a strong “why” you need to find a problem, a real problem and then check that it is a big problem. A big problem either causes a little pain to a lot of people, a lot of pain to few people, or a lot of pain to a lot of people.
With a problem you have a villain to defeat and with a villain you have a story to tell. Humans like to hear stories. A good story can overcome the design and technical shortcomings of your prototype as well as a lousy pitch by your tired team. A good story helps the hackathon jury remember and if they remember your story more than the others you have a better chance of winning.
Below you have the stories of each of the hackathons that my teams won.
1. Area31 Hackathon at IE Business School
The topic was video games and the team consisted of three MBA students (one of them was me) and three programmers from the Madrid ßetabeers group. For about 12 hours the MBAs worked on the why and the programmers built a game related solution.
In 2012 you could already tell that, given its over 20% year-over-year growth rate, mobile gaming would be a big category. The casual game iOS market was about 500 million USD, already in 2012. In 2017 mobile gaming is expected to be about 40% of the global games market, which is over $100B in size. In fact, games are such an important category that Apple recently redesigned the App Store app to have its very own games tab.
At the time, the Apple App Store had over 700,000apps, with games being one of the main app categories. The sheer number of apps means one thing: a customer will not go through all the apps to find the ones they like. App discoverability is a problem (we just defined the “why”, “why what you are going to build matters”). From the game developer side it means that you have to invest in marketing to have a critical mass of gamers try your game.
Our solution to this two-sided problem was a platform that allowed gamers to try six games in 3 minutes and developers to publish their game on this platform and pay for gamers that actually tried their game and liked it enough to want to find out more.
Having a reasonable “why”, a solution that had the potential of overcoming a real problem, and a good demo from the ßetabeers guys, we won the jury and received the first place.
2. Deutsche Bahn’s first hackathon
In March 2015, Deutsche Bahn handed out some of its data to a bunch of strangers in its first hackathon. In the 500MB zip drive was customer complaint data. What a better place to find problems than customer complaints?
After a couple of hours of data analysis, there were three areas that customers complained about: punctuality, service, and comfort. Punctuality is pretty obvious, no one wants their train to be late, especially if it makes you miss a connection. Service consisted of complaints related to interactions with staff. Comfort included complaints related to wagons having air temperature that was too high or too low and overcrowding.
Most people, if any, don’t like to complain about a service. Complaining takes time and energy. So if someone takes the time to complaint, something went really wrong. Being a train commuter myself I have had to wait hours for a train, I have been stuck inside a train, and have traveled in a train with poor performing air conditioning. But these are not train specific problems, they are transportation specific problems. I’ve had similar experiences taking the bus, an airplane, and even driving my own car.
Consider commuting with a car to work. In most major cities you know that if you drive to work at peak times it may take you three or four times longer to reach the same destination as in non-peak times. However, a lot of people decide to drive home during peak times. If you are stuck in traffic and are not happy about it you know that it is your decision.
In contrast, when you buy a train ticket and you arrive late to your destination it feels differently. You paid for a train that was going to arrive at a very specific time and that part of the deal was not met. You got less value for your money. It was not your decision to be late.
Humans feel happy when reality meets their expectations. Can we transfer the elements of the “car commuter” to the “train” experience? Would you feel differently about a train delay if it was your decision to take a train that is late 2 out of 10 times? I certainly would feel different and the team thought more people would as well.
Our solution focused on expectation management (this was our “why”, management of expectations). We built a formula to calculate a “quality of service” metric based on punctuality, service, and comfort, and a beautiful user interface to demonstrate a train selection experience that would better inform customers about their travel selection. To see some screens about the solution visit the candylabs blog.
The design of our prototype was top notch, but we definitely did not have the best working prototype. In fact, one of Deutsche Bahn’s own developers built a browser plugin that worked and displayed the probability that your train would be late. It was impressive and he received the “audience” award. Nevertheless, the Deutsche Bahn jury decided to give our team their vote.
3. Future Mobility Days 2017
The topic of this hackathon was, as its name states, the future of mobility. Some companies sponsoring the event brought datasets to analyze (ADAC) and others made their APIs available for free (Graphhopper).
For this hackathon I had the pleasure to team up with the developer that received the audience award in the 2015 Deutsche Bahn hackathon, Alexey Valikov. We both stumbled on a use case that caused a little bit of pain to a lot of people: checking if your train, tram, or bus will arrive on-time, or be delayed (this is our “why”).
There are 60 million commuters in Germany, a good portion of them commute with public transportation. The main train stations of Germany alone have a daily foot traffic of 3 million people. The Deutsche Bahn has an application to check train schedules and so do the regional public transportation providers. So why is this a pain?
Let’s back up for a second. If you are a train commuter you learn the train schedules by heart for the stations you visit five of the seven days of the week. If you are a public transportation commuter you probably have a monthly ticket because it is a cheaper and more convenient way to use public transportation. This means that over time you learn what trains, trams, and buses take you to and from home. Because you take public transportation frequently you know it is not always on time. What you want to avoid as a commuter is spending your precious time waiting for a train, tram, or bus.
So how long does it take to find out if your train, tram or bus will be late? It can vary from 10 to 60 seconds, perhaps more, depending on how fast you figure out which stop is close to you and which app you have to use to get the schedule. Then you might have to enter the “from” station and the “to” station plus the time of departure. If you saved the route as a favorite it could take less, but I didn’t know this feature even existed until recently. My favorite method for finding out if my train was late was texting my wife, who got on the train 4 stops and 7 minutes before I did.
Our solution was to answer the question “will my train be late” in one tap. We combined GPS technology with a database of live timetables from public transportation providers to do this. Based on your location we would show you the timetable of the closest station. The product is called Stop.Direct (https://stop.direct) and is also available for iOS as Bahnhof.Direct (https://bahnhof.direct). The pitch slide deck is available on SlideShare.
By the end of the hackathon we had a working web app and a working iOS app (iPad and iPhone). Stop.Direct received two awards, data usage and the audience award.
One more thing is interesting about this use case: it is the perfect use case to offer alternative means of transportation when a significant delay occurs. I’ve waited four hours for a train, sometimes I’ve even had to be picked up by car at another train station because service was not possible to my destination. The future of mobility is one where the fundamental service is getting you to your destination, irrespective of the transport vehicle which can be Uber, a train, a bus, a bicycle, a car share, a ride share… and more to come. However, we didn’t have the time to squeeze this into our solution because of the time constraint and the complexity it would have added to the pitch.