^^ Fear of failure is, of course, not limited to developers and these thoughts apply right across organisations. The most effective individuals in startups are those who experiment heavily and when they fail make sure they do so quickly and inexpensively. ^^

You're absolutely right about the need for speedy experimentation (and failure) across the *whole* organization. Only its seems that, all too often a businesses processes are structured to manage the greatest perceived risk… missing first customer ship! Will the product be ready in time for the big marketing push!?!

Look at all the different development methodologies… and the whole ecosystem of project management software, books, conferences, etc thats built to address the challenges of shipping bug free software on time. Even agile methodologies are about reducing the risk of being late.

This focus on first customer ship is understandable because its measurable. Until the product ships, about the only thing thats measured is the development progress. After all, there is no product to sell or marketing activity. So everyone zooms in on the product development process.

As a result, the developers and the managers optimize around the fear of missing first customer ship by sticking to 'best practice', padding estimates, and all those activities that slow teams down.

Whereas, the real risk is whether anyone really wants the product. The biggest mistake a start up can make is spending six months building something no-one wants. No matter how bug free, how many months of crunch time the team endured, or how perfect the code might be.

So, going back to your comment, the whole company need to be focused on solving the product market fit problem as quickly as possible. Sales can't sell something people don't want. So the whole company needs to figure out what people will spend money on as quickly as possible.

What the IMVU team seemed to do so well was understand that product market fit is all that matters. And the only want to know what people want is to build and test – and the quicker they get the feedback the more tests they get to run.

Its a tight feedback loop involving the whole organization.

So what I think its interesting that there is far more literature dedicated to the problem of development methodology, and managing the schedule risks of software development, than the product market fit risk of software development.

The one book I encourage everyone to read at my company is the Four Steps to the Epiphany (Steve Blank). Its my most dog eared book… and the only book I've found that addresses how to build a Customer Development Process. Steve describes a process for the whole business to focus on learning who the initial customers will be and what market they're in. Check out his blog, hes only recently started but very good.

One last though about the article. Its not always about fear of failure. Sometimes its just being bad at part of the process.

For several years we worked to a typical agile sprint of 1 month. Every month we pushed a release to staging. And every month something went wrong and the deployment process took 2 days.

To make things worse, we were always behind schedule at the end of the month so we rushed to get features in. Cramming features and a 2 day release process ate up a lot of QA time. As a consequence every release was buggy, and the first week of the next sprint was spent fixing bugs from the last month!

The problem with bug fixing is that the longer it takes to find the bug the more expensive it is to fix. If I find a bug within an hour of writing the code I can fix it within 5 minutes. If I find a bug 3 weeks later its going to take me a couple of hours to track down.

We figured that we would get better at deploying, better at estimating, and these problems would go away. Which in theory is true. The problem with month long sprints is we only deployed once a month… thats 12 practices a year.

So, we took the view that we're not going to get better at deploying if we only do it 12 times a year!

Now we have a rule, anything we're bad at, we do it more often!

Sounds like a bad idea at first… but now we deploy several times a week, find bugs quickly, and save lots of time.

So its not that we were afraid, its that we didn't so the hard things often enough!

Matt