There are numerous activities that an organisation or corporation can engage in to push aside traditional thinking, and try to ingrain a culture of continuous innovation.
Hackathons are a popular choice at the moment, and contrary to popular belief, they don’t just have to be about technology.
Hackathons are about solving high value problems through collaboration. And, it’s encouraged that the ‘skills pool’ or human capital in attendance is as diverse as possible.
This type of event typically runs for a set period of time and my suggestion is to start with a full day and work your way up to longer events down the track.
The format is entirely up to you but here’s a quick example:
9:00 – 9:15am
Begin with a high-level overview of the event, the structure, the objectives and the prizes (yes you should give prizes out at the end of the day, but more on that later). The purpose is to set the context for what you’re all there trying to achieve. It’s important to highlight the highest value problems; these should have been identified earlier, and you must believe they can be, or can be well along their way to being, solved by the end of the day. It’s also important to highlight the importance of diversity within a team and the value all participants bring.
9:15 – 9:45am
Give at least half an hour for participants to pitch their ideas and potential solutions to garner interest among other participants and help them form diverse teams capable of delivering something tangible within the next 6-7 hours. Allow participants to gravitate to the problems and groups, they prefer or believe is worth solving the most.
9:45 – 10:00am
After all the ideas have been pitched, it’s time to give everyone a few moments to officially form their teams. Again, the importance of diversity can’t be overstated here. Ideally teams will be built with the capability to assess the problem, incubate the idea, build a solution and take it to market. You’re effectively building a mini-startup team in fifteen minutes. One way to encourage diversity could be to suggest colleagues to separate.
10:00am – 4:00pm
Time to hack! Although this is a relatively short exercise, the expectation is that teams can build a high-fidelity MVP (minimum viable product) within this time frame. If the solution the team is building is customer facing, ideally they’ll speak to a few prospective customers. If it’s an internal solution, expect the teams to speak to some internal stakeholders quickly, get their thoughts on what they’re doing and use those thoughts to help them keep moving forward. If there are internal stakeholders in the team working on the issue, this can be of assistance.
4:00 – 5:00pm
It’s time for the teams to get in front of the crowd and demonstrate what they’ve done. The team will talk about the problem, the steps they took to solve it, the prototype they’ve managed to build and any customer or internal stakeholder validation they’ve managed to achieve.
Typically, there is a vote to decide the winners of the day’s festivities. However, going against the grain, my suggestion is that a more formal assessment is completed on the day’s work to decide the winners.
This is not a popularity contest; it’s about identifying high-value problems and proving a potential solutions validity.
In order to do that, you’re going to need to assess what the team achieved during the day, outside of just the prototype they built. Their prototype should address the problem.
My suggestion is that each team is given a number of Business Model Canvases. At the start of the day, the team will plot their starting hypotheses, and throughout the day it’s the team’s job (this is why you need diversity and not just engineers and developers) to prove or disprove the validity of as many of those business model assumptions as they can.
This is seriously hard work, but it will get the teams in startup mode.
Again, whether the solution is customer facing or internal, certain team members will need to speak face to face with potential customers or internal stakeholders to try and prove or disprove their business model assumptions.
Then, during their demonstration, the team is given the opportunity to discuss the evolution of their business model canvas. They’ll talk about the tests they conducted to validate their hypothesis and the end result or their experiments. The conversations with customers or internal stakeholders will also align with the development of the prototype or MVP.
This means that the winner of the day will be the team who has progressed their business model canvas the furthest and added the most potential value to the organisation.
Here’s where it get’s really interesting. Once the winner is selected, don’t give them wine or a holiday. Give them the opportunity to pursue that solution, and the business model that surrounds it for a set period of time. And, track their progress on a daily, weekly and monthly basis by following the same format.
This is what’s now known as evidence-based entrepreneurship and this process is equally effective internally for a corporation as it is within an external startup.
So, if you want to become an organisation or corporation where continuous innovation is not only valued but also truly ingrained in your culture and your people, run some Hackathons with a similar format to the example given above.