Creating on a Blank Canvas
By: Sean Raftery
Tags: Android, iOS, Product Management, Technology, Ideation

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 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!