failure

A Lean Startup has three possible outcomes:

We found a winning product (success)
We learned our idea was a bad one, and did something else (safe failure)
We messed up and failed to seize opportunities (big failure)

Thinking like a Lean Startup, we value fast failure, because it teaches us important lessons that in turn can be used to find a winning product. Big failure, however, is when we fail to implement the thinking in the first place. Big failure encompasses anything from never getting getting started in the first place to greenfield innovation initiatives that – usually seen in retrospect – never could have made it, because they were built on the wrong premises.

This post is about avoiding big failure.

I meet a lot of corporate people who want to learn Lean Startup these days. They mostly expect training in experimentation: Business modelling, customer dialog, minimal (viable) product design and other means for validated learning. Build, measure, learn.

The truth is that learning basic skills of Lean Startup isn’t really that hard. Effective use of cheap learning material, from books and tutorials (and even board games) to Meetups and conferences, will get you a long way. Getting mentored by someone who’s done it before may get you even further, but you’re still traveling along one axis of a multi-dimensional challenge. Experimentatiton skills are the hiking shoes you need to climb the mountain (and as far as I know, no hiking shoes have ever climbed a mountain).

And the horrible truth is:

Our systems always depend on other systems and services and thus may and will be subject to failures – network glitches, dropped connections, load spikes, deadlocks, slow or crashed subsystems. We will explore how to create robust systems that can sustain blows from its users, interconnecting networks, and supposedly allied systems yet carry on as well as possible, recovering quickly – instead of aggreviating these difficulties and turning them into an extended outage and potentially substiantial financial loss. In systems not designed for robustness, even a minor and transient failure tends to cause a chain reaction of failures, spreading destruction far and wide. Here you will learn how to avoid that with a few crucial yet simple stability patterns and the main antipatterns to be aware of. Based primarily on the book Release It! and Hystrix. (Presented at Iterate winter conference 2015.)