One of the topics that frequently arises when I'm talking to someone about lean product development is the concept of failing fast. They usually tell me that their culture won't accept failure as a Lean principle so they're having trouble with adoption.
But when I ask them if they know about the science and economic principles behind Lean, they invariably say, "No"...
This is part 1 of Series on Lean product development.
One of the major Lean and Agile project management tenants is “rapid learning." (Which is often embedded in principles like “build, measure, learn”, or “test first, then design.") That makes sense and it’s easy to understand the benefit.
Product development is inherently uncertain, so we have to learn as fast as we can. For example, we have to answer a lot of questions like: What does the customer value?; How much will they pay for it?; Do they prefer this vs. that?; How can we develop it?; How long will it take?; How much will it cost?; and so on and so on.
These questions are knowledge gaps. In product development terminology, we like to call them "risks." And these knowledge gaps are closed (or these risks are mitigated) by getting answers to the questions. In other words, learning.
So, it’s the R&D team's job to learn as much as they can, as fast as they can. But what does learning have to do with failing?
First of all, learning comes from information. So to learn fast, we have to generate (useful) information fast. And it turns out that we generate information the fastest when we get unexpected results half the time. Let’s take a look as this in detail.
Most engineers like to work on something until they’re confident it will work. Naturally, they don’t like to fail, and I don’t blame them. So they’ll work on a design until they have a high degree of confidence it will work, and then they submit it for testing. But if the design passes the tests, you have to ask, “Did you learn anything?” The answer is, "No," you just confirmed what you already believed.
...But what would have happened if it had failed? Then you absolutely would have learned something. And that event (failure) in product development has a lot of useful information. (And good thing it happened now, and not after release!) So those unexpected failures have a lot of value, which is good. But they don’t happen very often.
Another way to look at this is from the opposite scenario. What if an engineer had a test scheduled but never got enough time to work on the design. So in frustration they had to submit something that was unfinished. But much to their surprise, it passed the test! This was also an unexpected event that has a lot of useful information. [It also saved a lot of time (waste) in over design.] But again, this doesn’t happen very often either. And remember, we’re looking for the optimum rate of useful information, not periodic spikes.
So, what is the optimum rate of “failure”? As it turns out it’s 50%.
Now then, don’t run off and blindly apply this everywhere. With every rule, there are cautions or exceptions. Remember, we’re in business to maximize profit. There are a lot of drivers of profit. And usually, the biggest driver is time to market.
So, if these unexpected outcomes, or failures, cost us a lot of time or money to build another test unit or otherwise get to the next stage in development, it might make a lot more sense (and we'd make more money) if we spent more time perfecting the design before testing and breaking it. By the way, this is one of the key differences in applying Lean and Agile to hardware product development versus software--the expense and time involved in the build-measure-learn (or test) cycle.
I hope this helps you understand the science and economics behind “failing fast” so that you don’t have to take it on good faith. Or, if you’re trying to get this lean product development principle accepted in your company, you can show management why it not only makes good sense (cents) but lots of dollars as well!
P.S. I can tell you that when I first learned that you learn faster when you fail half the time, I immediately called my mom and told her I had actually learned a lot more in college than she thought! (She didn’t fall for it, but it made me feel better.)
P.P.S. A lot of credit must be given to Don Reinertsen who first introduced us to this concept (Information Theory) in his book Managing the Design Factory and explained in more detail in The Principles of Product Development Flow.
This is Part 1 of a series of Posts on implementing Lean Product Development. Stay tuned for Part 2 where I discuss why Lean Product Development really is the opportunity of the century!
In the meantime, watch this webinar hosted by Management Roundtable where one of our customers shares the steps they took to cut seven months off their schedule and net $15M additional profit by getting to their trade show a year early.
Guide to Lean Project Management
Guide to Lean Product Development
Science and economics behind “failing fast”
Lean Product Development the Opportunity of the Century.
Lean Product Development Case Study
Principles of Lean Product Development
Lean Product Development Value Chain
Get started with Lean Product Development
Lean Product Development: Cultural Resistance
4 ways to Ensure Your Lean product Development Initiative Won't Fail