By: Matthew Anthes-Washburn, Product Manager, Engagement
One of my favorite events at HealthSparq is our annual hackathon. This company-wide event challenges teams to design, build and demo an idea in just three days. It’s a great opportunity to step out of your day-to-day work to think in different ways, work with new people, practice different disciplines, and to tackle problems without the everyday constraints of limited time and competing demands. Done right, a hackathon can produce a wave of new energy and ideas and the ripples will continue to be felt for months to come. There isn’t a single trick to getting it right, but with these tips, you can set the stage so that no matter how your team places, you can together consider it a win.
Start with a problem…or don’t
As a product manager, I tend to start a project with a (hopefully) clear idea of the problem I’m trying to solve and who it is that I’m solving it for. This is a great place to start from in a hackathon, but it’s not the only way to go. In some of our most successful hackathon projects, we started from a technology we wanted to play around with and our team found ways to put it to use. In fact, the winning project started with an idea, “What if we added voice search to the search bar?” Later the team discovered unexpected benefits with search taxonomy (categorization of searches).
But, if you aren’t sure where to start, look for a problem to solve. It may be your own problem, or one you know people have. The more urgent and pervasive the problem is, the more people will thank (and pay) you for solving it. The judges might like it too!
Recruit a “heist” team
One of the opportunities of a hackathon is to build an interdisciplinary team, perhaps with people you don’t always work with. Try to build a “heist” team—think of the team in Ocean’s Eleven, where team members are recruited from all over the world because of the expertise they offer to the team. (Hat tip to @lauraklein.) Sometimes I’ve seen hackathon teams that are the same teams that work together every day. That’s fine (there isn’t one right way to do a hackathon), but I think the big opportunity is in forging new teams and building new relationships. It’s especially valuable to recruit team members from across disciplines or departments. Recently, I participated in a team with a couple designers, a product manager, an engineer, a content strategist, a marketer, and a UX researcher. Often it’s hard for us to work across groups and specialties, so the hackathon is a great time to try it.
This one is important. If you’re given permission to spend some time on this project, take it. Set an away message for your email and don’t check it. Cancel meetings. Claim a team workspace and camp out there. The hackathon is a great opportunity to drop off the radar for a bit and focus on only one thing. It’s a rare, immersive experience; enjoy it.
You’ve gathered your team and you’ve pulled the plug on daily interruptions. It may be tempting to just take an idea and start building. Try brainstorming as a team, first. Design Studio Workshop is a great technique for eliciting ideas from a group and iterating quickly. If your team has settled on an area or problem you want to focus on, have everybody take a single sheet and fold it into 8ths. Set a timer for 10 minutes and have everybody draw 8 versions of solutions they can imagine for the problem. Then have everybody share their ideas. Set a timer again and have everybody create new drawings and illustrations, this time encouraging them to “steal” from the best ideas and refine them.
After 2-3 iterations, you will see some convergence and you may be ready to put together a prototype of one or two of the most promising ideas. This can be as simple as a paper prototype you can test by showing it around to others. Using this design studio technique helps the team avoid the pitfall of starting with a solution in mind or one that seems “obvious” to one or more of your team. By allowing some alternative, interesting ideas to get air time, your team may end up with more innovative results.
Wear a new hat
I’m a product manager, and in my daily work, I don’t write a line of code. However, my nights and weekends are often filled with side projects, including creating iOS apps in Swift or learning new technologies with Treehouse. So in recent hackathons, I’ve put my novice software development skills to work building prototypes in iOS, and it’s been a lot of fun contributing to teams in different ways. Because of the time compression of a hackathon, you’ll find you have lots of things that need doing, and that team members will step up and offer talents you didn’t know they had. Enjoy it, and celebrate these discovered talents!
Evaluate and Iterate
You won’t have a lot of time in the hackathon, so you don’t want to build a sophisticated demo, only to find out that something about your solution doesn’t work for people. What’s the least expensive version of your idea that you can test? Can you draw a prototype on paper and show it around to a few folks in the hallway? Can you build a low-fidelity mock-up (even something as simple as a Keynote presentation) and have some folks tap or click their way through? Do you need to interview people? The quicker you get to a test, the sooner you will know what’s important and what can be changed. Then, change it and test it again!
You’re going to finish up this hackathon with a demo. This probably won’t be a fully-functioning, shippable product. There will be more things to do than you really have time for. So what do you need accomplish so that you can prove to the audience and judges that you’ve got a solution to an important problem? Which parts of the solution will you make, and which parts will you fake? Think about what you are doing that is different than what people have seen before. Make that your highest priority. What part of your project has the most “bang?” Do that first. The rudimentary stuff can be mocked up or even glossed over in your demo. Work with your team to identify the parts of your demo that pack the most punch and do those first. Identify a role on your team for a person who can identify distractions early and then gently (or forcefully) nudge team members away from those distractions.
Practice your demo. Know the happy path, so you don’t get caught demoing something that doesn’t work. Breathe. And then, share the excitement you have for your project. There will probably be judges or a scoring system of some kind. But whether you win or lose isn’t up to the judges.
If you are doing this right, you had some goals in this project that you’ve already achieved. Maybe you learned something new. Maybe you tested an idea that’s been bothering you for a while. You may even have a project that will live beyond the hackathon and see life in a real product. If any of these goals are met, you’ll win, regardless of how you score. Enjoy, and happy hacking!