Fail Early, Fail Often

Success is 99% Failure - Soichiro Honda

Seth Levine's blog post about failure inspired me to write some thoughts on the subject. Most of my career experience has been as an entrepreneur in contrast to Seth's experiences as a VC. I really appreciated Seth's views. He's right; the failure part happens pretty fast. It's the process leading up to failure that takes a long time.

One of the most difficult challenges as a leader is knowing whether to cut your losses and move on, or be persistent and see it through. There's all kinds of folklore about those who had an idea and despite repeated failures and naysayers telling them it wasn't possible, they see it through to success. But I'll bet even most of those cases, the results produced in the end evolved pretty drastically until a successful outcome was achieved.

I'm always best at something when I really believe in it. And I'm most loyal to a team objective when I believe in the mission and believe in the leadership in charge. When either of those aren't true, it feels like I'm in the "uncommitted" category. I suspect most people feel much the same way.

One of the things I enjoy about the early stages of a start up is your ability to try lots of things, test them, do it, get feedback, adjust, assess the results, and repeat the process. You can't be all over the map, but the cycle for getting feedback and then reacting to it is pretty short. That's true for product ideas, marketing ideas, target customers, and to some extent, even business models.

As you grow, build a customer base, and then start to build brand in market, it becomes more important to choose a market, product and business focus. Flexibility, healthy self skepticism, and constantly testing your assumptions are critical to taking measure of your decisions and execution. You have to just use your best judgment about taking opportunities that come your way, or that you create, vs. staying on course.

Failure is good, just as long as it isn't the kind of failure that takes the company down. And even in those catastrophic cases, it's likely there was too much commitment to "the plan" and not enough recognition that it's time to claim failure, change and move on. Failures along the way are a sign of progress.

I was working with a product development team this week. and we are moving into the full QA phase of the release cycle. A really good, talented group of people. First thing to pop up was a severity 1, or "blocker" bug. Not much further could get done until this was fixed.

Being a new member of the team, I'm guessing the team members were probably wondering how I would react to the bad news. I think my words upon hearing about the sev 1 were something like, "That's great. I'm glad to hear we're running into problems." I said it with a smile on my face, and a positive tone. My audience probably thought I was goofy or something. Managers are supposed to get pissed off when they get bad news, right?

Nope. If you've ever been around product or software development, it seems like you're always hearing about problems. Software is very much a systemic and a refinement process. Creating software by its nature means it's likely to be complex. Writing one little piece of code is easy. Making the whole thing work and work reliably is the challenge, or at least on of them anyway. Bugs, minor and catastrophic, are just a part of the process. 

It's when you don't have problems, then you're really headed for trouble. That's why finding the sev 1 bug was a good sign. I hope we find more, as early as possible. I know from experience that if we don't see bugs early in the process, and more of them for really new software and features, then it's likely we're building up to a really rough period at the end of the release. Better to fail early and often. Finding problems, especially big problems, are great the earlier you find them.

Two of the easiest metrics to capture in software QA are tracking the test cases that have been performed and how may bugs of different severities you are finding. If you aren't finding them early, you're probably in trouble. There are many other things of course that go into managing a software process, but over time you see some pretty common curves that tell you how things are going. I'm always encouraged the sooner we find problems and the more of them we find. You just want to see progress as you work through the test cases, automated preferably, that you're working toward a successful release.

I've taken and applied this same philosophy to research, product management, marketing and business. You don't want all of your ideas to fail of course, but if you aren't seeing some failures along the way, it's a pretty good idea you're not stretching, challenging and really going for it. You're probably believing in your own assumptions and plans too much. Again, fail early and fail often applies the same as it does in software.