There’s been some prominent blog posts recently questioning the usefulness of hackathon events. Some focus on the cultural issues associated with many hackathons–that by default they appeal to a very homogenous subset of tech workers (aka young white male coders who enjoy subsisting on beer and pizza). This can be mitigated by thoughtful event organizers–advertising your event in places where a diverse crowd will see it, explicitly inviting beginning developers and non-developers (designers, product managers, community members), having a code of conduct, providing child care, serving real food, etc. I attended LinkedIn’s DevelopHer hackathon last weekend, which was 100% female; they got these and many other things right, and I had a fantastic time!
A deeper criticism of hackathons is that, although they may be fun, since nearly all hackathon projects are abandoned after the event is over they’re no good for creating startups, real useful products, or social change. All they might be good for is networking. Thus, these events are oversold. I think there is a point here, but I don’t think you can conclude from it that hackathons aren’t worthwhile to run or attend. Rather, attendees and observers should modify their expectations.
First, a pet peeve. During the presentations at hackathons I’ve been to, I often see groups presenting their work as if they’re pitching a real live product in front of investors or potential users. It’s hard to pinpoint what exactly bothers me about this convention–the overly-polished marketing speak, the inauthenticity of talking about a userbase that doesn’t [yet] exist… But the overall effect is that what the presenter is saying oversells what they actually built, so by the time you get to the demo it’s usually at least a little disappointing. I get that pitching is a valuable skill, and perhaps pretending that your hackathon project is real is how people practice this. Depending on the hackathon, the judges may participate in that illusion. But they usually don’t as much as you like, and I as an audience member don’t at all.
Your hackathon project is not a product, so don’t talk about it as if it is. People don’t build products at hackathons. You can’t build a product when you’re shut in a room for 24 (or 48) hours, no matter how many “10X” (ugh) coders are on your team. Why? It’s not a product until after you get it in front of users, or at least stakeholders, and at a hackathon there just isn’t time for that.
Most hackathon participants understand this, partially. Good teams know that starting small, and building from there, is the way to go; inexperienced teams often fail to let go of their grand vision in the face of the time limit. Most teams have heard of the concept of “minimum viable product”, and as they make plans at the start of the hackathon they (hopefully!) brainstorm, prioritize, and cut features down to the minimum they see necessary for a product.
But remember what I said: you can’t make a freaking product–even a “minimum viable” one–in 24 hours!
The “minimum viable product” verbiage comes from the book The Lean Startup, which is very clueful in its advice (though it bears balancing with this article). I wish the book had popularized a more precise term for this concept, though. At a hackathon, you’re not building a “minimum viable product”, because it’s not a product (yet). You’re building a minimum viable prototype.
A concept that is at the root of any hackathon idea–besides projects that are purely for practice in some tech stack–is an assumption: that the world would be better if X existed, or that some population of people want to know Y or to be able to do Z. Even projects that scratch one’s own itch progress forth under the assumption that what you intend to build will, in fact, solve your problem. Eric Ries would call the implicit assumption within the “why” of your project idea a “hypothesis”, which after being tested becomes “validated learning”–and argues that every organization that wants to grow and innovate ought to be testing new hypotheses all the time. Peter Thiel calls these assumptions, if they turn out to be correct, “secrets”–and spoke at length about how startups are a institution for discovering secrets and that every successful startup has at least one secret behind it.
What a hackathon is good for is to distill the core “why” of your idea–the hypothesis, or hypotheses, that make you believe your idea is useful–and build a prototype that will best tell you if your hypotheses are true. Science!
What that means: you probably don’t need social network integration–or any user accounts at all–unless your hypothesis specifically requires potential users to view information based on their own profile or network. You might not need a real database–just some sample fake data that refreshes itself every so often, or even on every reload. Email notifications? Edit or delete buttons? Logout functionality? Cross-browser compatibility? Search? “Like this on Facebook”? Unless there’s a good reason why it’s needed to test your hypothesis, cut it.
(If you get to hour 16 and you’ve got your core prototype nice and polished, then’s the time to start adding things like delete buttons and actual user auth. But you should start from a place where that which can be faked, should be!)
Then, when you present your work, it will be easy to focus on demoing what’s cool about your app and the reasons why you built what you built. Instead of pretending you’re a Real Startup pitching to VCs, you can be honest about your motivations and what you did and didn’t build; your insight, and the quality of what you built to test that insight, should be impressive enough. You can also avoid getting bogged down in extraneous “look how many different auth systems we support!”-type features or the details of your tech stack. You’ve only got a minute or two and the audience mostly doesn’t care about that stuff unless you used something really unusual (“we wrote the frontend using C++ and asm.js, because we’re insane!”).
The other common hackathon pitfall I see is how teams answer the judges’ perennial question, “What are the next steps for your project?” Nearly every team I see answers with a list of technical features that they didn’t get to during the hackathon. This is not only probably-dishonest (odds are, you’re never gonna touch this code again), it’s generally the wrong answer. The right answer will have something to do with putting your thing in front of people–publicizing your project and seeing if people sign up for the mailing list, posting the code with some sort of free software license and seeing if people write patches or feature requests, sitting down users in front of your prototype and watching what they do with it and listening to what they say. No battle plan survives contact with the enemy, and whatever the heck you scrawled on a whiteboard 24 sleep-deprived hours ago will most likely only bear slight resemblance to what actual user feedback tells you your project needs.
You built this prototype*: time to use it to test your hypothesis! Some of that test is your presentation itself–if the judges and audience respond well (and if they’re representative of your target audience) that might be a sign you’re on the right track. If your hackathon project is something you care about, you’ll also put it in front of people in other venues to learn enough to know whether or not it’s an idea worth moving forward with.
That’s what hackathons are good for–besides meeting tech people, practicing skills, consuming inordinate amounts of caffeine, or “generating buzz” (whatever), hackathons are pretty good for generating prototypes. Think in those terms, and you are likely to be more satisfied with your results!
