Observations from our recent hackathons…it’s all about the journey
When picturing a hackathon, you may often think of engineers coding away for 48 hours in a dimly lit room, stocked with pizza and beer and not emerging until they have some sort of presentable solution. In fact, hackathons are about more than just coding, they build collaborative culture and encourage teams across the business to be involved in a shortened version of the full product discovery, design and development lifecycle. This blog post shares some of the observations and lessons learnt from our recent internal hackathons.
Great for team building
Hackathons are great when it comes to getting people from various teams, whether that be iOS, Android, Backend, Design, Product, QA or Marketing together and working on a business problem within a condensed period of time. It exposes people to working with others they might not usually work with, and enables them to gain a better insight into the way others think and rationalise ideas. More importantly, it gives everyone in the team a voice, and a chance to shape a new idea. We of course try to build this autonomy into our product process, but the pressure to deliver new releases quickly often means many people in the business get left out of the discovery and problem solving part of the product process.
Additionally, at Monese we have product and engineering teams distributed in two locations — London and Tallinn. Often, teams are only collaborating via Slack channels and Skype conversations. Having a hackathon where team members are able to come together for a couple of days, and work on solving a problem together in the same physical location, is incredibly important for building bonds and team morale, particularly if your business is geographically distributed as ours is.
The process and journey of discovery is king
Don’t put pressure on the teams coming up with a transformative business idea or incentivising the winning team with a reward. Hackathons are ultimately about going through the process with your colleagues, enjoying the journey and having exposure to the wider product development and engineering process outside of your typical role. We try to create a safe environment where the emphasis is on providing rationale for why your chosen idea solves a customer pain point as opposed to having a shiny prototype that does not solve any real problem.
We still make the hackathon competitive, with teams ranking the other groups ideas using a typical product prioritization framework (ICE), which scores the business impact, confidence of success and overall effort to develop from 1–10. But again, rather than selecting a ‘winner’ (although teams do enjoy the bragging rights), the emphasis is on critically evaluating each idea based on the overall impact on the business and accounting for the risk/confidence factor as well as the time the idea will take to deliver.
The hope is that product managers emerge from the process with a better insight into the thought process of designers and developers and likewise, designers or developers have a better understanding of the product life cycle and a better understanding for why some features or customer problems are prioritised over others. The entire product development process is an interconnected process and exposing all team members to the full lifecycle is beneficial for both the company, personal development and empathy for other team members.
Getting the size of the problem space correct
The first hackathon we ran was limited in scope. We focused teams on a specific customer pain point — making it easier to make payments through the Monese app. Whilst our first hackathon was great for going through the process together and learning what worked and what we needed to change, the problem space was too narrow and led to a limited range of ideas and most of the groups ended up with similar solutions. Equally, you don’t want to set too broad a problem space, otherwise you can end up with something that ultimately lacks focus and does not solve a real customer problem.
Based on the learnings from our first hack day, we decided to widen the scope for our second hackathon. This time we took two key business KPIs, and gave teams the option to focus on one of the two KPIs. This gave the teams a broad enough scope that they all came up with different and unique ideas, but kept it narrow enough that the ideas still delivered against a key business metric that we needed to move. What’s great about broadening the problem space is that teams can come up with ideas that can potentially 3x or 10x your growth, as opposed to a narrow problem space where you’re working with single digit percentage point optimisations.
Focusing on the why as opposed to the finished output
As mentioned above, sometimes the output of a hackathon is a range of solutions that ultimately don’t make it into production or onto the roadmap. If that happens, that’s absolutely fine and not a waste of company time. Getting teams to assess the problem space and put emphasis on the reason for selecting their chosen idea is fundamentally more important than having a slick prototype or demo.
We borrowed a technique made popular by Amazon in our recent hackathon, encouraging teams to write a press release based on their chosen idea imagining the success of the product being shipped and why it would be important for customers and ultimately marketable. We also asked teams to imagine the product or feature failing, and working backwards to try and understand why it might have failed. Teams in any line of business often have a resulting bias where we only imagine the future as absolute success or absolute failure, but we’re actually always dealing with percentages of success. Getting teams to think about the upside and downside of their idea, and coming to the realisation that the future is unlikely to be either 100% success or failure is an important part of the decision making process. Annie Duke’s recent book, Thinking in Bets explains this in great detail.
Beer, food and space are important
Finally, beer and pizza from the opening paragraph are definitely important! My role on the hack day is typically to outline the problem space and ensure team members are fed and watered. It’s also important to head down to the pub and celebrate the highs and lows of the hackathon at the end of the process.
I can’t stress enough that it’s important to keep roadmap decision makers out of the process. Teams need to have a safe space, free of influence to come up with their own ideas. Having team members who normally decide on roadmap decisions heavily involved in the process is counter productive, and they normally end up shaping the ideas of the group that they’re in. The purpose of the hackathon is to create autonomous decision makers across the organisation, who are able to critique product decisions and feel safe and confident to do so.
If you’ve had any experiences running hackathons and you’d like to share them with us, please comment below.
This post was written by Tom Barbour, Head of Product at Monese. This is post is part of a regular recurring series from the Product and Engineering teams at Monese.
