To hackathon, or not to hackathon? We have the answer

A post by Gareth Stephens, Head of New Proposition Development at GBG.

Hackathons are all the rage right now, and I’ve read a lot around why they are great, and why they are an overhyped fad which whilst fun, usually ends up with disappointing, or non-compelling results. Having just completed a hackathon, I thought I would share my thoughts on how we made ours a success.

I think one of the big misconceptions with hackathons is having a consistent definition for what we are actually talking about. In the example I’m about to share, we had done around nine months’ work researching and planning what the new proposition was going to be. We have various processes inside GBG around innovation and market analysis, so we had already used those to rigorously test that our idea was unique and had a sizeable market which we had proof we could exploit. Other definitions of hackathons involve walking into a room and not only delivering a product, but also dreaming up the idea too. We were concentrating purely on delivery.

Delivering the golden idea

Now that we had a golden idea, the issue was how to deliver it quickly and without disrupting the existing product roadmaps which were full to the brim as we approached the holidays. The new proposition we had come up with was likely going to be a huge new market, but take 12-18 months to become profitable which is always a tough one to prioritise for any product manager. Do we take the short term, but smaller gain today, or play the long game for larger returns? As a publically traded company GBG is regularly announcing financial information and hence each quarter is essential - so there is only ever so much room for projects that take years to pay off.

That’s where a hackathon can serve the need brilliantly as we can minimise upfront investment and disruption to roadmaps, yet still test the market and see if all our research proves to be correct. We scheduled the event for a weekend and promised the usual snacks, refreshments, and even stocking filler presents for top performers, and decided we would build our MVP (minimal viable product) in a single weekend. We’d already confirmed with a few customers what our MVP was, and they were happy to trial it and test the market with us, so all we had to do was actually deliver two days.

Can 24 ever equal 80? It can in a hackathon

As a product guy, I’m not allowed to size technical work, and for good reason as I’m far too optimistic. So I’d been working with two developers for a number of months specifying the MVP and doing a lot of the ground work which always needs doing. We’d then settled on a number of tasks/stories in Jira that when sized were roughly two months’ worth of work, for two full time developers. I didn’t have two months, nor did I have two full time developers for the project. Some basic maths of two people x two months = eighty working days. So I needed to get eighty days done in a weekend.

An email went out for an A Team of people from Product, Marketing, Development, QA, and Professional Services to not just build the technical side of the proposition, but have the documentation, branding, pre-sales etc. all done as well. We quickly got a full team of twelve which were pointed in the direction of our pre-planning work before the event.

For that weekend we then worked tirelessly on delivering an eighty day project within our twelve person team, which we knew fell well short of what we estimated we needed. We figured the gap in time would be fuelled by high caffeine drinks and our drive to succeed, and at the end of the two days we were proven to be right. During those two days we completed our MVP and bar some final environment tweaks to make it live, we had done it. A fully viable MVP that had been developed, QA’d and even had supporting collateral. There were many issues on the day but none that weren’t overcome quickly due to having a diverse team of people and expertise on hand to help out.

It’s not just about delivering a product

We hadn’t ‘just’ delivered the end goal either, which was the minimal viable product. We had also assembled a group of twelve people from across a company with 500+ staff members who had never worked together before, and delivered together. The cross-pollination of skills and ongoing relationships that are built from such events are impossible to measure, but you can feel the benefits of them for years to come.

So our experience of hackathons is extremely positive, but defining the goal, having a very clear vision of what you want to achieve and then bringing a varied but motivated team together are all crucial to maximising their value. If you’re missing any of these components, then its likely you’ll be sat in a room with a group of sugar-coma induced people all working in different directions resulting in half-baked ideas that have a demo that is only marginally better than ‘Hello World’.

For those of you intrigued to know what we built, it was a single Digital Identity which uses blockchain technology and enables users to finally replace passwords with something more convenient and secure. Contact me if you’d like to know more about the proposition and/or hackathons in general at

.red { fill: #b0013a; }