Using Hackathons to go from zero to business impact in a week
We’ve shared before the lessons that can be learnt from Design Thinking and the potential benefit of Hackathons.
Although previously reserved to tech companies or the most technology literate businesses, I am seeing more and more clients use this approach. When hearing about placements from Data Science graduates, I even heard of a hackathon with no coding at all.
So, I thought it time for us to explore this phenomenon, to see if it could help leaders like you. As a trusted guide, I am delighted to welcome Ryan den Rooijen as a new guest blogger. Ryan is Global Director of Data Services for Dyson. You may also recall that he was a very engaging interviewee on this audio post.
Over to Ryan to talk us through how Hackathons are working for his team…
Hackathons – helping you get past concerns about hype
Analytics teams who want to prove themselves – “It’s not just hype, promise!” – face a number of hurdles. Whether it is identifying the right problem to solve, finding the best way to work with the business, or simply knowing whether an idea is any good, these obstacles can sideline data initiatives before they have even started. Paradoxically, in this situation, time pressure combined with a good structure can help. It forces you to focus on what matters.
Paul previously shared his experience of what gives “biggest bang for your buck” when applying analytics. At Dyson, we’ve seen the impact of using Hackathons.
Our hackathons tend to run for a week and follow the Stanford d.school’s Design Thinking process. Usual they involve a cross-functional team of analysts, data scientists, and stakeholders from the business.
Hackathons Day One = Empathise
Day one, EMPATHISE, starts the week off with the team spending time in the business. Time to deeply understand some of the challenges teams might be facing.
These problems do not have to be data related; anything goes at this initial stage. This avoids opportunities for improvement being discounted, just because they are not considered sufficiently analytical.
Hackathons Day Two = Define
Day two, DEFINE, involves articulating the problems you identified on Monday. Stating them as clearly as possible, so there is no room for misunderstandings. After all, what could be worse than presenting something on Friday and realising that it is not what the business wanted!
For clarity, we tend to use a simple GET/TO/BY statement, e.g. using our solution, we can GET employees in our marketing team TO share content that is relevant to our customers BY giving them an easy way to understand the topics our customers are passionate about.
Hackathons Day Three = Ideate
Day three, IDEATE, is where you might be tempted to begin. But it is much easier to come up with solutions when you not only have a well-defined problem to focus on, but you have a good understanding of the context.
At this stage, any idea goes. As long as it presents a workable solution to your problem statement. This is where having a diverse team will pay off. They will likely be able to identify a number of approaches that have not been considered before. At the end of the day, you should pick just one.
Hackathons Day Four = Prototype
Day four, PROTOTYPE, means you can get your hands dirty at last. Whether you are writing code, analysing data, or designing user interfaces, the goal is to try and build a working version of the solution you thought of the day before.
This does not necessarily need to be very technical. Nor polished, as long as it can demonstrate that your solution solves the problem. Following the week you can always decide how best to productionise your prototype. As long as the response from the business is positive.
Hackathons Day Five = Test
Day five, TEST, is what everyone has been working towards. It is usually the highlight of the week. Whoever the business stakeholders are you, whom you empathised with on day one, now is your opportunity to show them. To demonstrate that you not only understood their problem but that you have been able to find a working solution.
This is why it is important to get your stakeholders hands-on with the prototype. It not only builds trust but will often yield rich feedback that you can use how to take this solution forward.
Not a silver bullet, but they can help
No tool or framework will solve all your problems. But, using Design Thinking in a time-bound manner has proven to be one of the most impactful ways of demonstrating the power of data.
A potent combination of collaboration and innovation can at times be weakened by a lack of concrete deliverables. When that happens analytics leaders erode trust – “a solution looking for a problem”. Through a radical focus on empathy and testing, you can ensure that you are not just trying to make a difference, but that you actually do so.
Many thanks for Ryan for sharing his experience and that usefully practical model. Have you used hackathons in your business? If so, please let me know your lessons learnt. If not, why not start this year?