Many of the principles of lean product and process development (LPPD) can seem counterproductive at first glance. For example, what if someone told you that the best way to see if a product will truly work…is to break it? That’s exactly what Professor Larry Navarre of Kettering University told me when I first met him – and there was no way I could let him leave without him explaining more. That conversation turned into this interview, on his self-coined concept of Extreme Testing:
So let’s start from the ground up. What is Extreme Testing?
The principle is this: It’s not enough to know that it works. You must know when it breaks. I explain it to my students in that way because we have to test way beyond the planned operating conditions of the product or the service. What we’re trying to do is push it to its limits to find out when it breaks.
It doesn’t do us any good to test to the specification. Products will often just work to the specification. What customers really want is a very durable and reliable product. You don’t learn things just by testing to the specification.
How did you first realize that this concept of Extreme Testing existed? Was there a specific event?
Not exactly. Well, it was a specific product that we were developing when I was in industry before my academic career. We were developing a system. It was actually looking very, very good, both on paper and in the lab.
We thought we had a really good product on our hands. Everything looked good. When it operated it was performing well. We went ahead with the product launch, got a lot of attention and began shipping products.
One year later we began experiencing fatigue failures with critical components in some of our systems. It was really a very negative situation. We were falling all over ourselves trying to help our customers. We crashed the redesign program. And that’s when we really started doing things correctly. Instead of just throwing a fix together and putting it into the field, we actually took the time to do a lot of extreme testing until we figured out what our problem was and then confirmed the fixes by doing even more extreme testing.
How does it compare to the existing testing process on product development lines? What advantages does Extreme Testing hold?
Well, the thing that I try to pass on to my students is that you’re going to get value in extreme testing in three ways:
The first is that you’re going to get safety. You’ll know when a system fails and how to protect your users. The second is reliability. You’ll know the expected life of your product. You’ll know how it will fail. The third is knowledge. When your product fails you can learn what’s going on. You can discover improvements to your product that you would never get if you allowed it to run at the normal specification.
Sounds like a universally useful concept! But are there any industries you think would find Extreme Testing particularly valuable, maybe more so than others?
I think where you’ll find Extreme Testing most valuable is in critical environments where human injury or even death is at stake. Examples might be medical devices, aerospace, automotive safety, things like that. However every industry and every service could benefit from Extreme Testing.
Without Extreme Testing, you only discover the problems in your product when your customer puts them in front of you. Then you realize you should have done a little bit more to anticipate the negative situation. It can happen in any industry. Just because it’s not life-threatening doesn’t mean it’s any less important to your business.
I can’t help but feel that a product engineer to whom I recommend Extreme Testing would say, “That’s a waste of money. You’re just testing it to see that it breaks.” How might you respond to skepticism like that?
It’s all about set-based concurrent engineering (SBCE) – one of the unusual characteristics of LPPD, and also one of the four cornerstone principles. If you dig into SBCE what you’ll realize is, in my experience, we lack the underlying knowledge that you would get by going through doing extensive testing and developing the knowledge that we should have had.
In SBCE we would have tested the extremes of our sub-systems of the total product system. We would have created knowledge briefs that capture the design understanding and our test results from our experiments.
Importantly, we would have developed tradeoff curves to visualize our knowledge and track our progress. That would have led into knowledge that we can reuse in the future. I’d like to point out that you don’t lose anything.
You don’t waste anything in gaining this knowledge, as long as you reuse it going forward by capturing it in knowledge briefs, tradeoff curves and eventually your design standard checklist. Then, all future products will look back on the knowledge you’ve gained in the current projects.
That’s incredible value. Companies that do this have an insurmountable competitive advantage. They know their fundamental technology. That gives them incredible value in meeting their customers’ needs and exceeding them, delighting their customers with excellent products.
