I think it's a great point to reward developers who submit bugs and give feedback.
Though I do think hackathons can serve different purposes. The most important thing is to be clear on the objective and don't try to win on every front. e.g. If it's to publicise your API among developers, great, focus publicity, talks, challenges around that. If it's to get feedback, same thing.
And this mirrors how developers should approach hackathons, which is again to have one clear objective. It could be to build something amazing, it could be to learn an API, but you'll rarely achieve both.
Isn't this kind of the point of hackathons? It has nothing to do with gaining customers. Who even asked thought that it did? Hackathons, from my understanding, have always been about developers getting together to improve their skills. Also I'm not sure how much value a PM would get out or give to a hackathon.
It seems like hackathons and other hacker conferences and events have successfully capitalized on the popularization of start up culture. It makes this* seem like one big fad. The deeper purposes of sharing, freedom, coding and solving problems have been forgotten.
It sounds like the author is trying to tell companies what to do based upon his personal preference on why companies should run hackathons rather than based on any kind of evidence.
I know plenty of developers and founders who picked up an API (Twilio, Stripe, Paypal and Azure come to mind) at a hackday and then ended up using it commercially elsewhere. These companies aren't stupid, they're often investing 6-7 figures in marketing spend in running hackathons. They look at ROI.
It's fine if you prefer non-marketing focused hackdays, but that's totally different from saying they don't work.
It is based on a lot of experience running Hackathons. I chose not to elaborate much further on the reasoning in the article to keep it to the point. Ultimately the cost of running hackathons for the limited scale of developers that you reach at anyone time could be best spent in many many more ways.
The Hackathon rarely wins the customer, and it is not sustainable as a practice often due to cost and ROI is near impossible to determine.
Personally, I'd be interested in some data and reasoning to further understand your point of view. Without elaborating, the points you make come across a bit terse and declarative, whereas this comment makes me think you actually have a deep understanding of the subject and good reasons for stating the points you made.
As a standalone developer, I can think of several companies that I feel have built great "developer brand" and goodwill through hackathons, whether running their own, or sponsoring others (e.g. TC Disrupt, Startup Weekend). Twilio is the first one that comes to mind. But whether that translates into actual revenues is where my anecdotal evidence clearly falls short.
Remember that in a lot of cases you're not comparing against the cost of online advertising, you're comparing against the cost of an external salesforce.
Many businesses are perfectly happy to spend 10k to acquire a customer who'll pay them 50k over the next three years.
Assuming you're not running hugely expensive hackathons a low conversion rate can still give a decent ROI.
Even if you CAC is relatively low you can still make hackathon commercially viable. A lot of smaller vendors will partner together to split the cost of hackathons between them or will become external sponsors to third-party hackathons in order to reduce the costs involved.
Honestly, Hackathons are more about what the developers get out of it.
I went to a couple to try and build a wider network among my local devs and to try and win cool stuff.
Some went to hone existing projects using the APIs presented (to know if they actually wanted to use it)
Some went for the prizes
Some went to try and score jobs
To say any of those options are wrong really isn't right. But to tell a company why they should be there they should ask what the developers are hoping to achieve and decide if there place belongs there or not.
I will agree completely on the comment about company reps being present however. A lot of people were turned off from various companies because they were difficult to work with through different online channels and elected to not use their API simply because the cost to get it working with flawed documentation or sparse contact was too risky if they were gunning for a prize. Often the companies didn't return for the next hackathon for what I assume was because of bad reception the first time around...
The only worthwhile hackathons I've ever seen or participated in were related to the release of a new API, one that none of the participants had any access to before release. This arrangement benefits both the hackathon attendees and the sponsor: attendees know that they're starting from a level playing field, that if there is a competitive angle to the hackathon, then everyone will be judged on how well they use the new API in their software and not on what they wrote before they showed up. For the sponsors, it is a trial by fire, testing their API architecture, backend, documentation, and usefulness.
I completely agree that the optimal result for an engineering-driven hackathon is a long list of bugs and a couple of surprisingly awesome demos. But I would add a room full of excited-about-pioneering developers, and a battle-tested developer support team.
12 comments
[ 4.3 ms ] story [ 216 ms ] threadThough I do think hackathons can serve different purposes. The most important thing is to be clear on the objective and don't try to win on every front. e.g. If it's to publicise your API among developers, great, focus publicity, talks, challenges around that. If it's to get feedback, same thing.
And this mirrors how developers should approach hackathons, which is again to have one clear objective. It could be to build something amazing, it could be to learn an API, but you'll rarely achieve both.
I know plenty of developers and founders who picked up an API (Twilio, Stripe, Paypal and Azure come to mind) at a hackday and then ended up using it commercially elsewhere. These companies aren't stupid, they're often investing 6-7 figures in marketing spend in running hackathons. They look at ROI.
It's fine if you prefer non-marketing focused hackdays, but that's totally different from saying they don't work.
The Hackathon rarely wins the customer, and it is not sustainable as a practice often due to cost and ROI is near impossible to determine.
As a standalone developer, I can think of several companies that I feel have built great "developer brand" and goodwill through hackathons, whether running their own, or sponsoring others (e.g. TC Disrupt, Startup Weekend). Twilio is the first one that comes to mind. But whether that translates into actual revenues is where my anecdotal evidence clearly falls short.
Many businesses are perfectly happy to spend 10k to acquire a customer who'll pay them 50k over the next three years.
Assuming you're not running hugely expensive hackathons a low conversion rate can still give a decent ROI.
Even if you CAC is relatively low you can still make hackathon commercially viable. A lot of smaller vendors will partner together to split the cost of hackathons between them or will become external sponsors to third-party hackathons in order to reduce the costs involved.
I went to a couple to try and build a wider network among my local devs and to try and win cool stuff.
Some went to hone existing projects using the APIs presented (to know if they actually wanted to use it)
Some went for the prizes
Some went to try and score jobs
To say any of those options are wrong really isn't right. But to tell a company why they should be there they should ask what the developers are hoping to achieve and decide if there place belongs there or not.
I will agree completely on the comment about company reps being present however. A lot of people were turned off from various companies because they were difficult to work with through different online channels and elected to not use their API simply because the cost to get it working with flawed documentation or sparse contact was too risky if they were gunning for a prize. Often the companies didn't return for the next hackathon for what I assume was because of bad reception the first time around...
I completely agree that the optimal result for an engineering-driven hackathon is a long list of bugs and a couple of surprisingly awesome demos. But I would add a room full of excited-about-pioneering developers, and a battle-tested developer support team.