Built to Fail: What Google, Ideo, and 37signals have in common

The standout there is Apple. Apple builds great products, doesn't do focus groups. They probably do multiple iterations but without large betas, the audience of those iterations is probably very limited.<p>Their releases are not cheap - once you announce a new iPhone, you cannot change the hardware before release so you really need to get it right. The soonest you can update it is a year or so.<p>Most of all,Apple is the canonical example of the 'great man theory'. Apple has several of them - Jobs, Ive and several others whose names generally don't get publicity.<p>Now, this is not to say the original posts points aren't valid - most people don't have the talent or expertise that Apple do. But I just couldn't resist throwing in the obvious counter-example.

There is a difference between planning to fail and failure-tolerant.<p>People and companies still need to have long term vision of what to do "in case" your product is actually good, your startup actually gets funded, and of success in general. This turns you into a proactive player.<p>If all one does is have a system in place that reacts when something goes wrong, then this is really being reactive.<p>I believe Andrew is missing the bigger picture.

The unanswered questions at the end are interesting.<p>"This area of thinking started out with the hiring process, and the idea that maybe interviews don’t work at all – there’s a bunch of academic research that implies that, actually. So if how would you build a failure-tolerant system around the hiring process, if you assume that good interview candidates actually have no correlation to successful employees?"<p>I have been partial to contract to hire. You still have to do interviews, but you have a fallback position.

This reads like a text book architecture astronaut...

Where all these companies just put there for their names? Article just doesn't make sense. There is the talk by Jason from 37signals, where he specifically talks how he does not get this obsession with failing: <a href="http://www.37signals.com/svn/posts/1798-jasons-talk-at-big-omaha-2009" rel="nofollow">http://www.37signals.com/svn/posts/1798-jasons-talk-at-big-o...</a>

Speaking of failure, my mantra on a personal entrepreneurial level has always been "build to fail" seriously. 0 risk = 0 reward. Don't have the guts to fail, and fail terribly... stick to a 9-5.<p>Be ruthless, and whatever you do, make sure it passes the deer-stuck-in-the-headlights-of-an-oncoming-car test. If it doesn't stir emotions to spread life, stick it out until you get that polished diamond in the ruff.<p>iPhone wasn't an overnight success, there's no such thing. Plan accordingly.<p>---<p>And there's one thing missing from that comic strip. "I see... well laugh as you may. Eventually I'll be laughing all the way to the bank."

But these are three companies that are doing well enough that they can afford to take on failures. So something doesn't work at Google; the company's got enough revenue that they can absorb the failure without a huge problem. If you're running a small startup and it doesn't work, taking a hit is a lot more costly.

I think the author is confused with three different concepts: fault tolerant system, idea generation and agile development.<p>A system being fault tolerant, like googke, just means that it can rollforward/rollback when an error occurs. It is nothing more than a technical concept.<p>People in design industry often use brainstorming to generate and screen ideas. IDEO is just one of them. Brainstorming is not an explaination of either how they succeed or why they succeed.<p>And the framework Ruby on Rails characterizing convention over configuration and don't repeat yourself even has nothing to do with "failure-tolerance", thought it emphasizes fast iteration in development.<p>The over generalization in the article make its conclusion very unconvincing.

"Of course, every web project requires lots of lines of code which can easily break at any moment" wtf?