Hackathons are great for many scenarios, but how do we maximise the opportunity of hitting the bottom line, a.k.a. the revenue before committing the spend on a hackathon? The following explores key elements and general framework to maximise success.
This guide applies best to Focused Hackathons together with Customer (i.e. where the hackathon challenges/problem statements are mapped to real business problems and are defined according to S.M.A.R.T = Specific; Measurable; Attainable; Realistic; Time-boxed manner), but might also be beneficial for Experimental hackathons.
Where to start?
Start post-pitching when all of the teams pitch decks and demos are available.
Note: assuming the pitch decks are structured in a consistent and value-driven way, i.e.:
- Address a clear problem: who has it, what’s the impact, how is it solved now?
- Propose clear value proposition: what does the solution enable, what would be the benefits?
- Explain how it works: how is the problem addressed, a proof of concept?
- Next steps in making it real: what steps, dependencies, experts needed, what time frame?
Phase 0: Race Enablement
Hackathons are well known for rapid, mini proof of concepts, interesting ideas and for lots of hard work. But what are the aspects that make this happen? How can you replicate some of those aspects, which ones should you aim to replicate? The following is likely to have had a tremendous impact on team’s ability to deliver during the event, think about:
- Direct access to subject matter experts (hackathon mentors)
- Distraction-free, blocked out time slot to focus on a single problem
- Multi-disciplinary team, being able to tackle most challenges within
- Being co-located
- Being in an energised, competitive environment (how might you replicate this with caution of not depleting team’s emotional/physical capacity to deliver)
- Necessity to constantly feedback to mentors on their progress and be challenged on assumptions, solutions, approach
Before discussing the concepts in more detail with hackathon teams, outline the questions for soft-enablement so that you can bring up the discussion points. Think about:
- Success Factors: What were the factors that enabled the hackathon team to deliver their concept on a tight timeframe?
- Mitigation: How might these factors be replicated?
- Who will deliver: Would the hackathon team be the one to advance the concept into MVP?
- Handover: If not the team, then how to ensure a smooth knowledge and vision transfer from the hack team to the MVP delivery team?
Phase 1: Warm Up Tyres
Goal: Summarise hackathon outcomes.
Start by establishing a consistent format for capturing the pitched solutions. This can be as simple as just following the structure of the pitch deck and elaborating/standardising if necessary.
- Which problem statement / hackathon’s track the idea related to?
- Any particular aspect of the problem addressed?
- Outline the solution in few words. Think of this in terms of the old Twitter tweet format – could you explain in 140 characters?
- How it works – brief overview in few words
- Key feature / differentiator – how is it better than current solution?
- Business value – be specific, include numbers
- Drawbacks – what are the potential pitfalls?
- Complexity to implement – focus on complexity, not time required
- Relationship to other ideas from the hackathon – can this be improved if merged with other ideas
Next, choose a medium that allows you to easily compare concepts and their value side-by-side, re-shuffle and edit the content. Depending on your environment – physical/digital, you might want to explore doing this on simple sticky notes or perhaps transfer to a digital whiteboard.
Phase 2: Test Lap
Goal: Qualify and revise outcomes and next steps with hackathon teams
Schedule individual, 15-30 min sessions with hackathon teams to co-revise your standardised material. Plot their idea on the Idea Evaluation Matrix so that later you can start to compare Value vs. Feasibility.
Bear in mind, the hackathon is not supposed to create refined outcomes, it’s very likely the developed concepts are very rough. Before a proper Proof of Concept can be developed, you are likely required to embark on a clarification and requirement gathering workshop to define the dependencies. This can be anything from – access to SMEs, environments, data, etc.
Ask the hackathon teams to evaluate the maturity of their solution and what they believe are the next steps required before this can be taken into the Proof of Concept development stage.
Draw a basic roadmap of how you might advance the team’s idea if it was picked by the customer for further exploration.
Phase 3: Qualifier Lap
Goal: Revise, prioritise and agree roadmap with main stakeholders.
Now, that you have all of the team’s solutions elaborated and understood their potential value and next steps, schedule facilitated, deep-dive 60 minute sessions for each team together with the customer to explore how and if there’s value of taking ideas forward.
Good practice is to have a pre-alignment session with the customer to pick which teams they are interested in seeing and discuss whether something extra on top of your comparison pack should be prepared. Identify what other experts should be present in the room.
Hope you found this useful. What are your experiences in ensuring continuation after hackathons? Please share – reach out to firstname.lastname@example.org or join our Hackathons and Virtual Bootcamps space on Circuit!