ProtoHack NYC
Winning a hackathon with planning and teamwork
Overview
I worked as part of a 3-person team alongside Bryan Sim and Anyi Sun, participating in ProtoHack NYC's "Evil Genius" hackathon. By planning our time carefully and collaborating closely at every stage, we developed a 90-second pitch which won us first place.
The event
ProtoHack is a design hackathon. Unlike other events which ask participants to code a final product, ProtoHack encourages teams to focus on prototyping and iterating their ideas. Awards are given to the most effectively validated and well-presented concept.
key takeaways
Plan time carefully and set strict deadlines
Collaborate with teammates on everything; avoid siloing
Allow plenty of time to practice the pitch
Use all the advice that's offered
Contents
01. Understanding the theme
The theme of ProtoHack NYC's April 1st competition was “Evil Genius”. The prompt was to design and prototype an evil idea, and deliver a 90-second pitch to a panel of judges consisting of industry thought leaders.
The unconventional brief raised immediate questions. What’s an evil genius? What constitutes an evil idea? What’s the scope — do the ideas need to be realistic? (One of the examples given was an app which hypnotizes people into doing your bidding.)
How might we use iterative prototyping to validate an evil idea?
It was an unusual prompt, but on reflection it made sense - as the host Amos Schorr explained, many hackathon participants get so obsessed with their idea that they forget the importance of the design process, and the value of teamwork. They start thinking months ahead about how they'll found a company on the strength of their winning idea.
With this theme, ProtoHack was encouraging us not to think too far ahead, and instead just focus on the design process.
Though the theme was light-hearted, the event was still rigorously judged. Our design was expected to be well-considered and validated to some extent.
It reminded me of a technique I'd learned in a creative ideation workshop with Jon Mysel from Cooper. He advised that when running a brainstorming session, before trying to produce good ideas the team should spend a few minutes deliberately producing the worst ideas they can think of. It helps break the ice, and removes the stigma around producing so-called "bad ideas". It builds psychological safety within the team, so that when they turn to producing good ideas, the team can be more creative.
Essentially, the ProtoHack event was a hackathon built around that exercise — an entire day of design and collaboration to produce ideas that would never see the light of day.
“I think that the whimsical theme helped us to start from a blank slate and focus solely on the creative process, rather than pre-conceived notions about a specific field or product.”
02. Deciding on a Design Process
I teamed up with Anyi Sun and Bryan Sim for this event. We found a quiet corner with a giant whiteboard to plan out our day.
Before we could start, we had to find a way to reduce the scope afforded by the brief. Without such restrictions, we would find it hard to even begin.
Like a jigsaw, we couldn’t make any progress until we found the edges.
To resolve this, we started with the only concrete, immutable requirement we had: the final idea had to win us the hackathon.
This requirement gave us enough traction to begin, because it allowed us to start defining other requirements. To win, we needed a 90-second pitch and a slide deck. We needed some kind of research, and we needed a prototype we could sketch, test and present. To make the most of the event, we needed an idea which had space to grow in unpredictable ways and, crucial for a lighthearted event like this, the idea had to be inherently entertaining.
With our presentation due in only 7 hours, speed was essential. It was important to establish an effective structure early so we could use our time efficiently.
We knew the day would be won or lost on the strength of our time management.
Taking inspiration from processes we’d used elsewhere, we sketched out a design process to ensure we would hit all of our marks and still finish on time. We broke the remaining hours of the day into chunks and allocated deadlines for each stage to keep us on track.
In the discover stage, we would explore the prompt fully, with the goal of settling on the strongest possible idea. In the validate stage we’d test that idea, pull it apart and figure out how to strengthen it. Then we would build it out and test it, looking for remaining problems to solve. Finally, in the ship stage we’d focus on delivering everything we had in the most persuasive way possible.
“Our process was highly iterative. At every design step, we looped back to examine and adjust our product features. ”
03. Discovery Phase
The discovery stage turned out to be the hardest. We started with a 5-minute brainstorming session, with the goal of producing 6 ideas each.
Then we took it in turns to pitch our ideas to the team. An escape-the-room service with no escape; a marketplace for social media influencers to sell their followers; a pied piper app that led children out of town with Pokemon Go-style augmented reality.
We had many ideas, but found it challenging to settle on one. We tried putting two checkmarks each on the ideas we wanted to work on, but we all voted for completely different ideas with no consensus.
We used deductive reasoning to approach the problem from a fresh perspective.
If we take as a premise that our users are classic Bond-villain-style evil geniuses, and that their organizations are large and complex, we can assume our users would face the same problems as modern entrepreneurs. How might one staff an evil organization? Or purchase evil real estate? How might one manage an empire — is there an app for that?
We briefly considered designing apps like “Trello for Dr. No”, but we couldn’t find a way to make these ideas entertaining beyond some dry jokes about the banality of evil.
We kept iterating on the question — what would be a useful service for a modern evil genius?
In this way, we arrived at a simple idea that had potential. Evil henchmen are typically thwarted quickly, but robotic cats could run surveillance, deliver secret messages and carry out assassinations. Nobody would see them coming, because they look like cats. These robots could be controlled via an app to replace ordinary henchmen.
This idea gave us a digital interface for us to prototype, some assumptions about human psychology we could validate, and plenty of opportunities for humor. Also, if we lost the event, at least we’d have spent some of our day Googling pictures of cats.
“When we felt stuck during our brainstorming stage, we took a step back and asked ourselves what job we want our product to do for the users. This product thinking mindset helped us focus on bringing value to our users. ”
04. Validation and Build Phases
Validating an idea based on fictional technology was always going to be a challenge, but there were elements of the plan which could be isolated and verified. For example, we could test whether we had the right choice of animal for a robot henchman.
To do this, we ran an Amazon Mechanical Turk survey. We asked 80 respondents to rate the “likeability” of various animals, and also quizzed them on how they might respond to seeing different animals in the street. Cats were beaten only by dogs for likeability, and since dogs draw more attention, cats were the ideal choice.
We also validated the concept of using an app to manage henchmen, by conducting in-person interviews with 10 other participants of the hackathon. We found that younger respondents were more likely to feel comfortable using an app, with older respondents more concerned about potential security.
We divided this work between us to take advantage of our strengths.
Bryan had experience with research, so he designed and ran the Amazon MTurk survey. Anyi had UX experience and was fluent with Sketch, so she designed the interface wireframes. I had sales experience, so I conducted the in-person interviews, built the slide deck and delivered the final presentation.
Although we departmentalized ourselves in this way, we cross-collaborated wherever possible, checking in with each other to bounce ideas or give suggestions.
This significantly improved the quality of our final product. When working alone, it's hard to resist throwing in new ideas that seem good in the moment. By filtering every new idea through the other two team members, we were able to throw out many ideas that could have held us back.
“I’ve taken part in six hackathons so far, and we definitely had one of the best team dynamics — nobody tried to hog the limelight or had some hidden agenda, we all simply worked together to develop the best idea. —”
05. Mentoring Sessions
At every ProtoHack event, teams receive mentoring sessions from two industry experts.
Our first session was with our design coach, Alana Mariano.
When we started, we were brimming with ideas for features: cats for assassination, for courier, for surveillance. By asking a series of probing questions, Alana helped us refine our idea and distill it to the basics.
Alana guided us towards finding the simplest implementation for our MVP — one single market (evil geniuses), in just one location (Istanbul, because it’s full of cats and therefore easy to blend in), and one primary use case (surveillance).
Alana left no stone unturned in challenging our assumptions. How would the cats get around? What would they do if they were caught? How would we market ourselves without attracting too much attention? Finding creative answers to Alana’s questions prepared us for the grilling we would receive in the Q&A session later on.
Our second session was with our presentation coach, Stacee Mandeville.
Stacee's advice changed the whole trajectory of our project. We discussed best practices for delivering a well-structured and persuasive pitch, but more importantly she convinced us of the power of theatricality.
She showed us that we could afford to be a little silly and melodramatic. The idea was absurd, so why not present in-character as evil scientists? Stacee showed us how, by adding a little showmanship, we could elevate our concept from a funny idea to one that everyone would remember.
06. Practice and Preparation
Because we had mapped out the design process with multiple deadlines, we’d allowed ourselves a whole hour at the end of the day just to practice the pitch.
We had started to understand the pitch as a kind of performance, so our decisions focused on how to maximize the impact of every line.
Following Stacee’s advice, I drew faces on a whiteboard wall so I could practice making eye contact with each of the judges in turn. We animated every element of each slide, so that I could synchronize their appearance with my delivery.
We recorded videos of my practice runs, and reviewed them as a team to identify places where we could cut a few seconds, or opportunities to tighten a punchline. We ran through the 90-second pitch again and again, until I was able to deliver it in 80 seconds (to allow time for problems or mistakes).
With each iteration, we looked for ways the pitch could be improved. In the end, we practiced the pitch so many times that all three of us could have recited it from memory.
“I definitely think we got the balance between being open and creative and being willing to hustle — our pitch, for example, ended up being drastically different from when we first started constructing it, but Jeremy went through that final version about 15 times.”
07. Presentation
You can see our final presentation–or at least hear the audience's reaction–in this video which was kindly provided to us by another event participant. We were delighted to be awarded first place.
08. Outcomes
Normally the winning team of a ProtoHack event is encouraged to pursue their idea, but our robotic cat assassin concept needed about thirty years of further development. Instead, we decided to stick together as a team to work on new projects.
My experiences at this event highlighted the importance of structured teamwork and rigorous planning. In part we won because our pitch was fun and engaging, but that pitch was only possible because of the careful scheduling we performed at the start.