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, as it forces you to focus.
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. Day one, EMPATHISE, starts the week off with the team spending time in the business to deeply understand some of the challenges teams might be facing. These do problems not have to be data related; anything goes at this initial stage. This prevents opportunities for improvement from being discounted because they are not considered analytical.
Day two, DEFINE, involves articulating the problems you identified on the Monday 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.
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 as you 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 one.
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 or 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, at least, if the response from the business is positive.
Day five, TEST, is what everyone has been working towards, and is usually the highlight of the week. Whoever the business stakeholders are you empathised with on day one, now is your opportunity 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, as it not only builds trust but will often yield rich feedback that you can use how to take this solution forward.
While no tool or framework will solve all your problems, using Design Thinking in a time-bound manner has proven to be one of the most impactful ways of demonstrating the power of data. The potent combination of collaboration and innovation can at times be weakened by a lack of concrete deliverables that 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.