How We Launched BandWagon and Realised We’d Built Too Much

In 2011 we designed and built our first large-scale startup website, BandWagon. It’s a platform aimed to bridge the gap between up and coming bands and gig promoters. The project was a big learning curve for us but a fun one. We were also exposed to an exciting world where we could create cool tools that serve a unique purpose for a passionate user base.

At the time we chatted with the founders who showed us their deep knowledge of the industry and their ideas for the product. We loved the idea and all got along like a house on fire. On top of that we could totally see the need for what they wanted to build.

So, we built it.

We’ll be the first to admit that, back then, we were a little green. Our general approach was: nice idea, let’s get stuck in and build something. Since then our way of working with startups has changed massively and a lot of that is due to mistakes made early on.

Not that BandWagon was a mistake. Far from it. The site launched and proved hugely popular with exactly the type of users who it was aimed at. They created accounts, logged in and started booking gigs all around the country just as they were supposed to. Result.

There were problems, though. A product is never perfect when it goes live, if it is then you’ve waited too long to launch. However, upon launch there were a few things on BandWagon that weren’t met with exactly the response we were looking for. Luckily, none of these were business critical but they taught us a lot about assuming what users want.

Our vision for what people wanted was correct, our mistake was in assuming the exact details

An example

We designed a comprehensive, and we thought essential, user flow to help manage the scheduling and booking of gigs. Bookings had various phases: pencilled in, offered, accepted, confirmed. These allowed a detailed overview of exactly where the status of each slot was. It had a fancy drag and drop interface and met our spec exactly, everyone on the project team loved it. There was much celebration and back-patting.

However, this phased user flow was way more complicated than any customer wanted or needed. All the promoters wanted to know was whether a band was going to turn up and play. What we’d built was complicating something that didn’t need to be complicated. Because of this the users were bypassing the system to confirm bookings, leaving this feature untouched, for the most part.

Building this feature was something that we’d devoted a fair amount of time to and was not simple. This was precious time that could have been used on other things. The complexity we’d introduced to the software increased the future cost of change. Worst of all we now had a feature in the system that users didn’t love, had we damaged how they thought of us?

Putting something out that that you’ve sweated over to find that no one quite gets it is a pretty frustrating experience. Having made this mistake we soon realised a we had to change our approach. All assumptions for what users wanted needed to be tested before we built features.

What we learned

A research-led approach will uncover what your customers’ problems are before you’ve even touched a computer. Talk to your users as early as possible to work out their wants and needs and you’ll learn a huge amount. Find out what their issues with their current solution are, from that you can work out what you’ll need to build to improve on them.

For many problems prototyping gives you a quick and easy way to put something tangible in front of a user. From this they’ll be able to give you instant, meaningful feedback. You’ve still not written a single line of code but already will have amassed enough knowledge to steer you on to the right path.

The rule of thumb should be if you are unsure about a feature, then leave it out. It’s much easier to add later than to take away. The cost and damage of a bad feature is not worth the risk.

In this case it wasn’t a disaster, BandWagon did great after we realised we’d been a bit too presumptuous. The booking process was simplified and met with a much better reception from the users.

Solving the wrong problem is the most common cause of startup failure and implementing the wrong or unnecessary features can be poisonous. Make your features work hard to get included and if in doubt, leave it out!