When we design new products, we tend to focus on the requirements that will make the product a success. However, unanticipated weaknesses or flaws can drive failure. As you design new products, challenge your teams to actively find those flaws and weaknesses and eliminate them before you launch.
The Rest of the Story:
In one of my career steps I worked for a business that designed and developed security devices for residential and commercial buildings, namely door locks. As you can imagine, the last thing we could tolerate in a product was a Web site or YouTube video publishing how easy it was to thwart one of our locks.
Our design teams got in the habit of challenging each other to find a weakness in our new designs. We would offer lunch or other rewards for any business personnel who could identify a practical weakness. Many of us just wanted to be the one clever enough to out-think his peers and thwart a design.
We would often begin the process as soon as digital CAD models were rendered and would continue the challenges through the various prototype and testing phases. We even engaged outside locksmiths whom we identified as having especially creative problem solving talents to try and crack our locks.
For the most part, these challenges were cheap to the point of being nearly free. Most of us made our attempts to break our peers’ designs in our spare or personal time. Why? It was fun. Like solving a puzzle. Sure we would be thinking about it in the backs of our minds while at work, but we were still getting our work done without much distraction.
Most of our engineers became trained in varying degrees of locksmith expertise to learn the tools and methods, and thought processes, of the trade. It helped us be better designers of locks. And we practiced. We would buy our competitor’s products and find ways through them as well.
For example, I found a way to bypass a competitor’s premium deadbolt product in the residential market repeatedly in 15 to 30 seconds using a simple piece of steel strip 3-4 inches long. I didn’t publish my discovery on the Web to discredit a competitor (it was not in my interests or our company’s culture to risk people’s security by telling criminals how to break locks), but it did go into our database of bypass possibilities.
The games we played with our designs and competitors’ product paid off. On several occasions we identified genuinely practical bypass methods before launch and blocked or removed them. We also identified difficult, but plausible weaknesses and eliminated those wherever possible within the cost constraints of the product.
Looking back, it was a virtually free exercise that potentially saved the company hundreds of thousands of dollars in liability or product recalls and lost sales due to product insecurity or reputation. What’s best is that the engineers started the game and challenge because they recognized the potential.
Given the recent news articles about hacks into Netflix and Citibank, and recent identification of potential avenues of insecurity in several of Apple’s portable electronics products, it seems that many product development agencies could benefit from similar practices. Some of the recent hacks have been embarrassingly simple.
Even if the products or solutions that your business develops are not security or safety devices, your designs might still benefit from a focus on actively finding their failures. Take a moment and go through your own catalog and see if maybe it could be true.
We don’t always naturally do so. We focus on ensuring success by identifying the right requirements and then we focus on meeting those requirements with our designs. We try to build test plans around verifying the requirements and validating performance, and sometimes those test plans include environmental or use-and-abuse tests.
Many of us incorporate risk analysis and mitigation methods such as Fault Tree Analysis and Failure Modes and Effects Analysis (FMEA). However, even those risk practices tend to focus on how our designs might fail to function under normal circumstances or fail to meet a requirement. We don’t necessarily think about how our products might be accidentally or deliberately undone.
I’ll give you an example. My neighbor goes through a-lot of car batteries. Her minivan will leave the dome light on any time the door is open. Sound’s perfectly reasonable, except that she has a large family with children of various ages who don’t always agree about who’s job it is to close the door or don’t appreciate the importance of doing so.
As a result, the car door might be left open overnight after one of them has come back to get something and neglected to close it, or because the last one out didn’t close it. It sounds like a small thing, but it’s enough of a defect for her that she has declared that her next vehicle will be from a different automotive brand.
Granted, it’s hard for a design team to think of every possible thing, especially for a system as complex as an automobile, but it’s easier for an entire population of engineers and product development personnel to think of them. Also, a small change to the car’s program concerning dome lights would be a very simple change if it were made during the development process. The light in my truck goes off after a set time regardless of door operation.
Regardless of how much your own development teams currently address possible failures and risks, or what methods you use, take some time and evaluate if you can reasonably turn your entire product development population loose on the task of finding faults in designs before they are finalized or launched. The cost of doing so is negligible and the benefit of it could be priceless.
Stay wise, friends.