Sketching with Code

Fail in Parallel

If you think about a startup, there’s usually one big idea that the founders have set upon and are absolutely committed to.

They’ve told their friends and their families that this one’s going to be the big thing, that they’re fully committed on the idea and that nothing’s going to stop them succeeding.

The trouble is, that startups, no matter the idea have a high failure rate. Sometimes, it just doesn’t work. Over time you can work out ways to minimise that failure rate, but because web and mobile tech startups are so cheap to launch, you see a large number of ideas beginning, and not many turning into viable businesses.

That’s okay. As long as you set things up so that that’s okay.

When I did my first company, 3form, I told everyone it was going to be a big deal. I staked my reputation on it. I promised everyone and myself that this was the thing I would be doing for years to come. About 12 years later, I gave up. It was painful. I wish I’d done it years earlier.

I often look back and think “oh gosh, I wasted my twenties on something that didn’t work!” but I always catch myself, because I learnt loads, and whilst I ended up totally broke I didn’t damage my health.

The app that I shut 3form to work on, Odadeo, the social network for fathers was my next thing. I repeated the mistake. This was going to be the next big thing! It was totally going to work!

It didn’t.

So I moved on to something else.

What I’ve realised recently that this pattern, you could call “failing in serial”.

If we were reading a software project management book in the nineties, this would look remarkably like a “Waterfall” project. The classic PRINCE2-style project where such and such happens, then something else happens in sequence, and x resource is required against y requirement. Gantt charts. Resource planning. All the stuff that only seems to happen in big companies.

But how wasteful! If you’re planning on doing a startup, why commit to a single, unevaluated idea? Surely it would be much smarter, given the low cost of, say, building a landing page for each of several ideas, running some adwords, and working out which of your ideas looks like a goer?

So that’s “failing in parallel”. How about trying out several, low-cost, tiny ideas. Doing experiments to see which of the things you’ve got an inkling about are really things that people will pay for, or use.

Then, try them out all at once, or in an overlapping way, and eject very early from the things that just don’t seem to hit the mark.

Through this approach, the approach we’re taking at Makeshift by doing several things at once, I think that we might have a more sensible way of hitting on something that people actually want.

I’ve given this pitch to a few good people that I respect. I often get back “what about the passion? Isn’t the reason that a startup succeeds because of the founder really caring about their idea?”

Sure. That’s great. But look at my history - I always care about everything I do. You’ll find me at midnight, 4am, weekends, having an idea, doing something to a product, pitching something to someone - that’s the way we (Nick, Paul, me and the rest of the team) are. There’s no danger of lack of passion. The danger is in wasting time building the wrong thing.

So, we’re failing in parallel. Do several things at once. Kill the stuff that doesn’t stick. Focus on the stuff that does. And through that process, there’s none of the emotional downside of having told your entire family and friends network that just one of your ideas is the Next Big Thing. It’s liberating, and when the time comes to focus, that’ll come naturally.