The Hackathon Approach to Building Digital Products

I love hackathons. I usually don’t win anything, but the feeling of building a product, seeing people try it, and convincing yourself that this is huge and you’re going to work on this further is a great feeling.

Recently at a hackathon at my company, we got together a group of 9 people who’d mostly never worked together before and formed a team. I’m not going to talk about team dynamics, managing expectations or 21 ways to prepare yourself for a hackathon, but more about how the experience formed an approach to product building that I’m currently experimenting with.

We decided to build an app that lets you play music and listen to it with a friend real-time. Couple hours into the design and development, we had a working prototype that used the Spotify API and had chat. The experience of using it was phenomenal. After spending about 45 minutes playing music for a friend on the app, I realised what a huge impact prototyping the core experience of the app can have. I could never have anticipated how insanely FUN it would be to feel like a DJ for your friend.

I could have definitely created a bunch of screens, a marvel prototype, hypotheses on how great something like this could feel etc, but using this buggy, hard coded version that played real music was beautiful. It was validation of this idea beyond my own expectation.

The next question to me was – how do you simulate a hackathon environment? How do you artificially create constraints to trick your mind into letting it all out? Saying “I’m going to do this task over the next 48h” just doesn’t work, at least for me.

I’m proposing a prototyping process I call the Weekender (I literally came up with the name while writing this). The Weekender involves picking two days, preferably a weekend, and imposing a deadline that is REAL. One that you can’t take lightly.

For my first experiment, I decided to apply this to working further on our music app. I flew to Delhi the next weekend on a whim to meet part of the team that was based there (and wanted to work on this project beyond the hackathon) The imposed deadline was that I’d be flying back at the end of this weekend, and we had to achieve all the design work required for the next development cycle, work that needed a high level of collaboration and would be hard to achieve remotely.

72 hours, 3 sketch files, 45(?) artboards, 12 beers, few Principle and Marvel prototypes and numerous sketches later, it had worked out surprisingly well. We got a great deal of work done, and had good fun doing it. We finished the major flows of the app including onboarding, inviting friends, starting a conversation, notifications, chat/music room intricacies etc.

The development cycle for this sprint has started and we’re spending our free time this week going back to our work and fixing all the hurried and ‘obvious in hindsight’ mistakes we made. We’re also planning for our next development cycle and will try figuring out how to simulate the Weekender remotely (our current team is based in Delhi, Bombay and Singapore).

I’d love to hear what your thoughts are on hackathons for prototyping and validating ideas and whether you’d approach it differently.

–

The demo is up at LISN.xyz, check it out.

PS – in the heat of the moment at the hackathon, we named it DUCE. IntroDUCE music to friends and the tennis term deuce which implies a back and forth, which you do with music on this app. What a great freakin name! Unfortunately we did not look up urban dictionary or the connotations of the word in Italian. We’ve now settled with LISN. Tweet at me and let me know what you think of the name!

PPS – we’re accepting beta users. Send me a tweet and I’ll hook you up with an invite!

Published in #SWLH (Startups, Wanderlust, and Life Hacking)