Failing Fast

Lately, I’ve been telling all our companies to fail.  Fast.

It’s not that I’ve decided to throw in the towel. Quite the contrary. After doing startups for a dozen years, I’ve come to believe that the best way to maximize the chance of a big success is to fail often and fail fast.

Thomas Edison was one of history’s most successful failures. He failed more than a thousand times before inventing the incandescent light bulb. When Edison finally figured it out, he famously said: “I didn’t fail a thousand times. The light bulb was an invention with a thousand steps.”

The idea of taking a thousand steps is core to our investment philosophy here at Altos.  We’ve come to understand that every company goes through a series learning processes – about new markets, products, distribution strategies, etc. My partner Brendon wrote a great post on the fact that there is just no substitute for time when going through these learning cycles. Sometimes, the outcome of learning means tweaking the product to meet unforeseen customer needs; other times it means completely scrapping the business model and starting fresh. In fact some of our most successful companies started with one business and ended up with something entirely different. Put a smart, tenacious team against a big market opportunity with enough operating runway, and you have a decent formula for success.

Failing fast is even more imperative in the world of Web-based software and services. Back when I was a rookie product manager, I’d spend months perfecting product requirements documents (PRDs) that would disappear into an engineering organization only to emerge months or years later as a finished software product. Nowadays, that one-shot, monolithic approach is just not a competitive option.

Failing fast requires companies to think about perfecting their products differently. To quote LinkedIn founder Reid Hoffman, “If you are not embarrassed by the first version of your product, you’ve probably launched too late.” Perfecting a product the first time out is impossible, but getting it out and iterating a thousand times just might get you close.

Some of our best development teams cull user feedback into new priorities to build/test/release on a weekly cycle. It doesn’t really matter whether they are using newer lightweight tools like Ruby on Rails and Adobe Flex or “heavier” Microsoft-centric stacks. The key is to obsessively listen to and incorporate feedback from Web users who aren’t afraid to tell you if their release sucks (or not). Keep what sticks, toss what stinks.

Of course, just failing a lot is no guarantee for success. There are plenty of teams that just fail all the way to a big fat zero. These teams either spend too much time and money failing or don’t fail in the right ways. Let me elaborate:

One corollary to failing fast is failing cheaper. Josh Kopelman has a good post (and investment model) on this, so I’ll let that him tell you all about it.

A second corollary to failing fast is failing well. Systems that fail well compartmentalize and minimize a failure so that it does not impact the whole system – for instance, a sealed chamber in the hold of a cargo ship that allows a single area to absorb damage without flooding the entire hold. Failing well is a lesson most of us learned in high school chemistry lab: isolating experimental variables by using a scientific control. Similarly, start-up teams that fail well run multiple experiments to get small, controlled failures. These teams understand that failure is a desirable and necessary byproduct of the learning process. They are humble, smart and fast.

So don’t be afraid to fail. Don’t even be afraid to be embarrassed. It’s all just part of being successful.