There are many scenarios that can arise throughout product development programs. There is one in particular that I have seen unfold more than once: I call it the “Plus one program.” Don’t let the name fool you; it’s horrible to watch unfold.
A startup or established player introduces an impressive jump in industry-standard technology, or sometimes an established player introduces an innovation to their industry. Since the technology is so innovative, there is great value in getting it to market quickly even if it isn’t a mature design. In this case, it is actually a smart move to go to market with a device that doesn’t have “ideal reliability.” In other words, the value of getting it out there quickly is worth the field issues. Those issues will be tolerated by the customer as well, if the technology is that good.
However, this tolerance for a less than optimal failure rate by both the customer and management will wear thin pretty quickly. The excitement of the new product darkens in the shadow of its growing field issues. It’s no longer a matter of just “working out the bugs,” at this point we are suffering from incomplete design maturity. Simply put, the fruit of bad engineering practices and no DfR.
Warranty cost is consuming the bottom line and customers are wondering if they made a mistake. Alarm and chronic firefighting is now the norm. With the realization that these issues are not going away with the current “find and fix” strategy, leadership decides to develop a second-generation of the product with the aim being “redesign for reliability.”
One problem. They use the same methods as they had when creating the first-generation. What happens? The same result. This is where it goes from bad to worse. The first-generation product, release 1.0, has been ramped down to accommodate the release of 2.0. But here is the thing, 1.0 is actually doing ok now because while 2.0 was in development, 1.0 was maturing under a new joint task force. We have our test engineers and reliability lab (the customers) plus the new improved design team (anyone who gets sucked into the Field Issue Tiger Team). It’s not the most efficient process, but with enough time the design improves.
Then what happens? First, we stop production of 1.0 and ramp up production of 2.0 effectively setting our field failure rate back to what it was when 1.0 first rolled out. This is all done under the premise that 2.0 is going to fix all the issues. So the disappointment is epic.
We are now in the danger zone. If this is a startup company with one product line, this could very well be the end. In fact, I can list specific instances where it was the end for many companies with very promising technology. On the other hand, for an established company, the outcome is entirely dependent on the rest of the portfolio.
But wait, we have one last trick up our sleeve. We reskin 1.0, to look like an updated 2.0. Then we quickly release “2.0 +” and everyone will forget about that little bump in the road.
Alright, now we have products going out the door, a decreasing field failure rate, and a half way efficient process for fixing field issues.
Things are ok, but what kind of organization is this?
We can’t really develop or advance the product because we are likely to start the entire cycle over again. At best we can implement small updates to the stable design in the field. We have no way to innovate; we are sitting ducks just waiting for a competitor to come in and take our market. In the end, we no longer have the advantage of being first to market and we aren’t confident that we can innovate.
If you find the first half of this story familiar, don’t panic, you don’t have to suffer through the second half as well. There is a solution.
When the first part happens, don’t just act on reflex and make a “this will fix it” 2.0. Take the time to discover and implement the design for reliability tool kit. You have time. The 1.0 design is going to continue to improve if you keep a team focused on it, especially if you have them pull from the reliability tool kit as well.
What will the Design for Reliability (DfR) tool kit do? It creates a process in design that systematically measures and improves the design to a set of reliability goals. This tool kit will in no way extend your product development time. In studies, it has been shown that if the DfR tool kit is implemented from the beginning of a program it will, in fact, drive an earlier product launch than planned.
Once this improved product development process is in place, the team can approach 2.0. But this time 2.0 will be about advancing your technology and staying ahead of the competition instead of just patching up your old technology.
-Adam
Leave a Reply