Epic fail: How we killed our startup product

 

It began like a story you’d read about on TechCrunch. We had an idea: make a time-scheduling application for large hospitality businesses that need a better way of rostering their casual staff. We’d call it Roster Rooster, and it could alert you to when you needed to submit hours or show up for a shift. At Touchtech we periodically have Creativity Days where the team can work on the little ideas and projects they’ve been thinking about, and then we vote on which idea to take forward and develop. This was the idea that was chosen to most usefully solve a real business problem. We started working but couldn’t quite figure it out.

In the middle of the night our Director sat bolt upright in bed, struck by the realisation: We needed to pivot. There were other companies that could do hospitality rostering better than us. What we needed for our own business was a scheduling tool to future-proof us against project blowouts. If we needed it then other businesses would need it too. Without figuring out the details of the idea, we envisaged hoards of project managers knocking our door down to get at a product that could save them money and make their staff more accountable. The idea had spark, we had expertise, and we were energised.

 

The greatest thing about the idea was that it could easily add-on to Harvest, the software that we were already using to track our hours. The Directors handed it over to the junior developers to take forward on their own, so that they’d learn their own lessons about project design and implementation. We were excited. What if, we thought, we could extend the versatility of Harvest to not only record time from the past, but to utilise this data to estimate project hours into the future and enable better forecasting for project managers. If we built our capacity planning software as a Harvest add-on, they would have to notice it, and we may even become a takeover target: the ideal exit strategy. We knew we could build it extremely well, so Harvest would inevitably want this helpful tool as part of their add-on package. It was a good idea.

 

We were very enthusiastic, and spent the whole next Creativity Day building the basic frameworks and developing the groundwork for the idea. It was an exhausting amount of work, but a lot of fun. By the end of the day we had a tangible sense of what it was going to look like and how it might operate.

But the next day we went back to work. We had a range of projects we needed to complete for clients, and development of the Rooster naturally took a back seat to these priorities. Without allocating structured time to work on the project, we ended up fitting it in between other jobs at whim, and this meant that we failed to track our burn rate for how much we were spending and how many hours it was going to take. Without concentrated blocks of work, development time and decision making took longer and longer. Still, we were achieving good results, the product was starting to work intuitively and we were all very impressed with its sleek design and the range of functions it could perform for the user.  

 

Because we needed the product for ourselves, we figured in the back of our minds that at least we’d get a lot of use out of it, and if the public liked it, that’d be an added bonus. However as the development timeframe became extended we started sweating about recouping investment. Our marketing guru wanted to create a landing page to build a waiting list of guaranteed users that could virally advertise the product before its launch, but the developers couldn’t approve this idea as it gave them a timeframe they were unable to commit to. We wanted to build the fully functional system that we needed rather than release something sub-standard. This meant we were developing a product that suited our needs extremely well, and was suited to Harvest, but we weren’t building it to suit the market. It had the flexibility to fit other businesses of a similar size that worked on a project-based model and used Harvest, but beyond that there was limited scope to extend its reach, or make it attractive outside of Harvest.

For us, however, it became evident how much we needed this product, how much it helped us and how valuable it would be to our operations moving into the future. We treated this as undeniable proof of the validity of the idea, and we got very excited about releasing it to the public. 

 

5.  Fail to anticipate competition

When we’d first envisaged the idea we’d done a cursory competitor analysis and found that there was nothing similar to our idea on offer. There was an old add-on called “Gardener” that Harvest was building that had been released in Beta. It claimed to do what we wanted but in a very different and less effective way. It had been released years ago and hadn’t progressed so it appeared to have been abandoned. This was great news for us. But while we did look around for competition, we failed to complete a risk assessment for possible unexpected factors that could derail our idea.

We had just begun approving the final designs for the Rooster. We were talking about colour schemes, styling and font selection. We were pleased with the way it looked and felt, and we were feeling confident that other people would like it too.

Then Harvest released Forecast.

Harvest killed their Beta version and released Forecast, an innovative add-on that integrated with their time tracking, allowing you to plan your time in advance to future proof yourself against project blowouts. It was identical to our product, only the colour scheme differed. It was evident that this must have been in their pipeline for a long time, probably since their Beta idea, and was very sleek. It provided the same functionality that our Rooster did, and most importantly, Harvest had made it themselves, so there was absolutely no scope for us to compete.

 

There were possibilities to salvage it at this point. We could have built it independently of Harvest for all those companies that don’t use Harvest to track their time, or we could’ve provided plug-ins for a range of different time tracking clients, making it more versatile. We could’ve investigated their designs, found out where the weaknesses were, and developed a standalone product that vastly improved a company’s ability to plan time and manage project blow outs. We could’ve tried to become a necessity for all project-based businesses, rather than just a tool for us and others who wanted to extend Harvest. 

But by this point we’d already spent so much time and energy on it that we decided to bury it. We don’t even use it for ourselves any more because the little bit of work required to make it fully functional is too much for the developers to think about around their other projects. The passion and enthusiasm for the idea evaporated as the timeframe stretched on, and this allowed our prospective buy-out partner to become a competitor and jump in. Who knows what would’ve happened if we’d released our version 3 months earlier when we first started working on it. We would’ve offered a more established challenge to Harvest’s development and it might’ve saved them time and money to co-opt our idea. It certainly would’ve saved us.

 

We learned a lot about communicating with an API on this project, and about using AngularJS as the framework. We also learned a lot about simplifying the design in order to track projects more effectively. By starting from scratch with our own idea we got to work on the nuts and bolts of concept design that our junior developers hadn’t had experience with. But most importantly, we made a lot of mistakes, and we learned from them. We learned about finding the holes in a good idea, anticipating risk and planning for unexpected factors that might derail a project. We learned to build an independent, self-sustainable concept. We learned to concentrate development while enthusiasm was high, schedule it to enable prioritisation over other tasks, and track and plan all work on it so we can monitor our energy expenditure. We learned to lead our development based on the market’s needs, enhanced by our own experience but not driven by it. 

 

While Harvest’s release caused our idea to fail completely, it also validated what a good idea it was. If we’d been quicker and sharper we could’ve at least communicated our ideas to them sooner, or we could’ve anticipated needing a plan B version that didn’t rely on them. But we didn’t. We did a lot of things wrong. 

Failure is awkward. It’s difficult to write about, and it’s difficult to re-read. It means a lot of wasted time, energy and hope. A lot of bad ideas that, on reflection, make you look stupid. But, at the same time, everyone fails, repeatedly, and in the startup scene we’re excellent at failing more often than most. We need to get more comfortable about discussing our own failures if we’re to collectively improve. When you read these ideas on paper, which we’ve all done – product/market fit, duh! SWOT analysis, obviously! – it all sounds so straightforward. But when you’re in the mix, you can’t anticipate the external factors, the competing demands, the teamwork relations and the thunderstorm of emotions that will affect your decision making. 

This is the biggest lesson we took away – even if you think you know your stuff, you can’t control the process. So how do you anticipate, predict and future proof? Well, you could start by trying Harvest’s new Forecast add-on. The concept is really good.