Lessons from a Hackathon

This past week several colleagues and myself traveled from Purdue University in West Lafayette, Indiana to Long Island, New York to participate in a hackathon hosted by Altice and Infosys. While we didn’t get to see much of the city, the experience was still incredibly rewarding. Not to mention, we took home two giant checks.

The team I was a part of was named the Bo-zos after my friend’s cat, Bo, pictured below. Our goofy, self-deprecating name made the win so much sweeter.

So, how did our teams pull ahead in group of skilled competitors? The key was simply communication and focus. Every team there was capable of making something. Many of them out-shined us in technical prowess. But that is not what the event was about. It was about ideas and convincing the judges of their merit. When giving a five minute shark-tank pitch, bombarding judges with the technical details of your idea only serves to alienate judges not well-versed in your field and to burn through your allotted time. Additionally, you should focus on developing only one idea. Trying to tackle multiple will lead to underdeveloped ideas and leave you scrambling to talk about all of them during the final pitch to the judges.

The Hosts’ Goals

When competing in a hack event it is imperative to be aware of what the hosts and judges hope to gain from the event. In this case we were given a whole packet of information on technologies they were interested in leveraging, as well as the design and brainstorming practices they wanted us to use.

They emphasized that our idea should address three areas: desirability, viability, and feasibility. We used this to our advantage. It provided the scaffolding for our final presentation and guided our brainstorming toward meeting the hosts’ goals.

Desirability was defined as the emotional response to a product or service which drives consumers to buy or subscribe to it.

Viability was defined as the profitability of a product or service. No matter how game-changing an idea is, nobody will be able to sustain it if it is constantly hemorrhaging resources.

Feasibility was defined as the technical details that make an idea either possible or impossible.

While all three of these concepts have to be there for a product to be successful, in the hack setting, my team identified that some were more important to focus our efforts on than others. We realized that we were pitching an idea to a company with armies of engineers, so feasibility could take a back seat during our pitch. They could figure it out and implement it far more elegantly than we could. This also played to our strengths, as none of us really knew how to implement our full idea, but we could “fake” a prototype to give the feel of the product. This was done in the spirit of the paper prototypes of the Palm Pilot OS the hosts showed in the opening presentation. By freeing up some development cycles we were able to build an argument for why our idea is something they should look into. We were able to show why consumers would want it and how the hosts could profit off of it.

It is also good to understand what the host companies do and if they are planning on moving into new markets. Making your pitch relevant to them by either building on their current services or providing incite or novel ideas about an area they plan to expand into is a great way to establish value for your idea. The hosts at this hack provided several subject matter experts for us to talk to. Taking advantage of these conversations helped us focus on the interests of the companies.

Design Thinking

In the packet of info for the event, we were given a document on Design Thinking. This was the encouraged methodology of the hack. It is an iterative user-centered design strategy focused of finding a problem to solve. In order the steps are: empathize, define, ideate, prototype, test. Though these steps are ordered, the iterative nature of the process requires frequent returns to earlier steps. Many teams came in with preformed ideas. So they skipped to ideate or prototype. This meant they skipped the most important step to winning: Empathize.

Empathizing means that you search for pain points of end users. In the case of the hackathon, it also meant searching for pain points of the host companies. If a team skips this step they skip desirability and risk missing key arguments of viability. In order to solve a problem, you must define the problem. In order to define a problem you must understand the user or client.

In the quality management course I took this past summer it was constantly stressed that quality is not the goodness or cost of a product, but the degree to which it meets customer expectations and requirements. Therefore, in order to make a quality product, you must know those expectations. In a word, empathize.

Why, How, What

Another common mistake the other teams made was in their problem statement. Many jumped right into what they were doing. While this sort of presentation has its place, it is a poor salesmanship tactic. In order to get the judges to buy into an idea, it is much better to appeal to their beliefs about innovation than simply placing a feature list at their feet. Simon Sinek, creator of “The Golden Circle” presents this idea quite elegantly in his Ted Talk. In order to convince a panel of judges to buy into your idea, it is important to start with why you are doing it. This makes it much easier for them to understand your goals and align themselves with it.