Last Wednesday we finally had an opportunity to run our very first internal hackathon that helped us learn more about the platform and how we work together. Not only we ended up with 4 amazing demos but we got to work with people from other teams and we had a lot of fun!
What is a Hackathon anyway?
Let's not get lost in formal definitions. We understand a "Hackathon" as a dogfooding session where you provide extra freedom to foster creativity and passion. Methodologies and processes can vary a lot but in general they all attempt to break the monotony of the routine by providing extra motivation to see what people can accomplish given the opportunity.
We kicked off with breakfast in the office and a short presentation on the exciting activities that awaited us.
To make sure everyone was on the same page, we provided some basic ideas but tried hard not to be too restrictive or influence the outcome. This is very important. Telling people to implement your "fantastic" idea is how a normal workday looks for most developers and designers. You don't want to repeat that
The teams had until 6pm to create and showcase a working demo. Each team had to present so if it didn’t work, the team members had to improvise.
Scope down but keep the ideas flowing
It's hard to develop on an alpha software. The same goes for planning a hackathon on a platform with multiple moving parts. At the beginning our plan was to recreate a real life scenario and include all the subsystems to make it as realistic as possible. We wanted our teams to deal with the current challenges on user onboarding, publishing and data-handling. Unfortunately, that didn’t work as planned.
If you are working on a hackathon yourself, let the ideas flow freely but try to stay as focused as possible on the tech behind it. We realised that while being realistic was a good goal in itself, it created too much overhead for a single-day hackathon. Therefore, we removed all "boring parts" (i.e, user onboard flow/device pairing) and focused on the functionality. If you wait for your product to “be ready”, you might end up waiting forever.
Empathize with your user
One of the nicest things about the hackathon, was being able to identify bugs and platform hiccups that are annoying but not critical. As we all know when the annoying bug is not part of your daily workflow, it is easy to argue that it isn’t important. When you have a long backlog, your sense of prioritization is not aligned with real users but rather what is important at the moment. For example, if you are working on code optimization, you might prefer to fix the slowest things, not the slow things that might annoy the user.
After the demos, awards and some margaritas later, everybody had an idea what are the platform annoyances and mishaps. It isn’t that they got smarter. They became the user for a day, and by sharing this experience they understood the pain points.
An internal hackathon, just like any user test, helps to reveal issues with the project you are building. It is fun as long as you empower that participants to use the product without any restrictions. As usual, “perfection is enemy of good” so try to scope it to the systems that make the most sense to you. At the end of the day, getting your company to think more like its users is totally worthy!
Interested in Geeny?