Hackathons are one of the most unique and rewarding parts of working in creative technology. At their most rewarding, hackathons can be an experience that sees teams go from a completely blank page to a minimally viable business in less than 48 hours. My team at SwiftKick Mobile recently stepped up to the plate in response to COVID-19 and attempted to do the impossible; come up with four viable businesses in two days to help people with their changing lifestyles in the aftermath of the virus. How we managed to start with a blank page on a Miro board and end with four businesses is a magic trick, and it wouldn’t be possible without total commitment to how we think about creativity and product development at SwiftKick. With the problems our society is facing seemingly mounting by the day, I wanted to share our framework for that process, in the hopes that it helps you and your team contribute to the side of history that finds solutions to our problems in a rapidly changing world.
Step 1: Creative Briefs
It’s common wisdom in Silicon Valley that ideas are cheap, but execution is everything. Why are ideas so cheap? Because they are nearly infinite. We, as humans are constantly producing thoughts, some estimate a new one pops into our heads every three seconds, the average span of what we can perceive as the “present moment”. That’s a lot of thoughts! With such a massive supply of thoughts, how does one begin to direct the flow of thoughts towards opportunities to become ideas that generate demand?
When constructing an agenda for hackathons, I like to view the creative process as a funnel that seeks to direct thought towards opportunities that become ideas and then converge on solutions. For this hackathon, the team at SwiftKick wanted to cast a wide net at the top of the funnel. COVID-19 had disrupted so many parts of our society, we could find opportunities to help people with mobile technology just about anywhere. We also didn’t know for certain heading into the hackathon where our team’s interest level or expertise would be. So instead of focusing on one problem, we created six briefs to focus on problems we saw in six different verticals; School & University, Entertainment, Mental & Physical Health.
The goal of the briefs was to begin to narrow the funnel of infinite ideas down, beginning with six specific focus areas. We sent these briefs out before the first day of the hackathon to give individuals time to start their internal creative process, spark conversations with others, and indicate to us, the organizers, where their existing interests and expertise lied before the formation of teams. Doing this enabled teams to be self-organized around existing interests and initial ideas from the team.
The briefs themselves relied on a tool to spark creativity known as “how might we” questions. The purpose of “how might we” questions is, as defined by Stanford’s dschool, to “create questions that provoke meaningful and relevant ideas … by keeping the questions insightful and nuanced.” We have found “how might we” questions essential in starting ideation discussion. You can find out more about the methodology and construction of “how might we” questions here.
Step 2. Discovery (Divergent Thinking)
Entering the morning of the first day of our hackathon, the SwiftKick hackers have already begun individually collecting their thoughts and forming teams around shared interests, but they haven’t yet begun the process of sharing their ideas and further narrowing each of their individual ideas, interests, and assumptions down to one product that they will be spending the weekend hacking on. Before a group can narrow ideas, they need to get every individual idea out of the table through a process commonly called “divergent thinking” in a group ideation session to officially begin the hackathon weekend.
In my experience, this step is the most important and the most challenging. On many teams not used to regularly creating on an empty canvas, group ideations can be bogged down in deliberation. If this sounds like your typical ideation process, you are likely pitching ideas to your team members more than you are collaborating and ideating with your team members. In ideations that feel more like pitch meetings, existing office dynamics can unfairly influence this process. Team leaders like CEOs, tech leads, and product managers are accustomed to having top-down influence in daily operations. Other team contributors also contribute to that dynamic because used to deferring to that influence. In hackathons, this is unproductive, because if a team spends too much time on one person’s perspective, and that perspective turns out to be misguided, teams will have no chance to pivot to another idea in the short amount of time the hackathon is designed for.
So, in a hackathon group ideation, I am looking to accomplish something more meritocratic and collaborative. The solution we used for our hackathon teams were divergent thinking exercises. Divergent thinking is a spontaneous, free-flowing, non-linear form of group ideation. For this particular hackathon, SwiftKick hackers utilized an exercise called “Crazy 8s” for this step. The purpose of Crazy 8s is to get each team member to produce eight idea sketches in eight minutes. These ideas could pull from what our hackers researched or prepared before the hackathon began, or it could be a completely new idea thought of within the exercise as well. After the eight minutes, teams share the ideas with each other and vote on which pose the most valuable or intriguing answers to the posed “how might we” question in the brief. As individuals share their initial ideas with their teams on the first day of the hackathon, their teammates should be seeking to accept and add to the ideas, like the “yes, and…” rule in improv comedy, and build as large and as varied a list of potential ideas as possible before starting to draw connections and conclusions towards one solution to the chosen “how might we?” question. The ultimate goal is to get as many of the existing ideas before the group ideation exercise as possible out on the table for teams to evaluate meritocratically and begin the process of narrowing those ideas down towards a singular solution to the “how might we” question.
Step 3. Product Development (Convergent Thinking)
Now that each team has a variety of ideas sketched out, it’s time to pull them together and make a product that solves the “how might we”. The common term for this process “convergent thinking” as we are looking to converge on one product after first getting as many ideas out as possible from divergent thinking.
The tool the SwiftKick hackers used to begin converging from the web of divergent ideas is a MoSCoW, or “Must Have, Could Have, Should Have, and Won’t Have (Right Now)”. Each team creates a two by two grid, each quadrant labeled with one MoSCoW category, and works with each other to organize the highest vote-getting ideas generated in Crazy 8s into what the first version of the product must have, what it should have, what it could have, and what may have to wait for a future version. Organizing in this way keeps a history of every idea while whittling the sketches down to the most valuable for the Minimum Viable Product, or the most barebone version of the product that we could build in a weekend and that communicates the value and utility of the app to the user.
Up until this point, our teams have been looking to be unconditional and supportive of other people’s ideas to get as much out on the table. But it is important in this step to have a good sense of what ideas would be a valuable solution to the “How Might We?” question and be extremely discerning with what should go in the Must Have square especially. This will mean that some members’ ideas will be rejected. But that isn’t a bad thing. In one of SwiftKick’s favorite books on creativity “How To Fly a Horse”, Kevin Ashton writes “Rejection is not persecution. Drain it of its poison and what remains may be useful”. This is the ultimate purpose of a MoSCoW, reject anything that doesn’t fully solve the problems posed by a “How Might We?” question so that only the most valuable ideas remain.
Teams should now have a very good handle on how each team member’s ideas could fit into a Minimum Viable Product to pitch at the end of the hackathon. From there, it’s a matter of dividing, conquering, and managing time. Our teams took the results of their respective MoSCoW exercises and spent the rest of the weekend coding, designing, and crafting a pitch deck for their product to present to the rest of the company. Once the teams submitted their final deliverables, we held a small pitch competition, picked a winner, and unwound with some beers!
And with the pitch competition, the magic trick is over. Our hackers arrived at the end of our 48-hour marathon with four amazing product ideas. The secret is that the work does not end there. In a lot of ways, hackathons are just the beginning. At SwiftKick, we are currently exploring all of the ideas we generated that weekend, either by finding the best ways we can bring them to market ourselves, or connecting them with people outside our offices who may be better equipped to do so. After all, “Ideas are cheap, execution is everything”.
In a lot of ways, I view the lifecycle of developing a product is a continuing cycle of convergent and divergent thinking as market conditions shift and new opportunities emerge. Once the first version of a product is shipped, new problems will present themselves, and the team will once again diverge together to find the patterns between each team member’s sea of infinite ideas, then converge to find a solution. With enough divergent and convergent cycles, you and your team may just have a valuable product and a solution to one of the many problems in our changing social and economic landscape.
Marc Andreessen, prolific venture capitalist of Netscape fame, wrote in April shortly after nationwide lockdown began, that it’s “time for full-throated, unapologetic, uncompromised political support … for aggressive investment in new products, in new industries, in new factories, in new science, in big leaps forward.” I couldn’t agree more with his assessment of our times, and I, along with my teammates at SwiftKick, took it upon ourselves to invest our time and explore what we could do to contribute. I hope this blog acts as a toolkit for you to do the same.
It’s time to build!