How Product Constraints Help Product Development (Really)
In the world of design and engineering, product requirements (also called “constraints”) can often feel like restraints to our creativity and ability to design a great product or solution. We’ve all experienced the feeling of frustration when a constraint has kept us from implementing a good solution, sometimes literally by only tenths of a millimeter. And the various coping mechanisms we employ to deal with these frustrations, like screaming at our computer, pulling our hair out or going to get that tenth cup of coffee, are keeping the counseling and healthcare industries in business. No doubt, constraints in product design can make our lives difficult, and finding a solution that fits them all simultaneously is no easy task. However, respecting the importance that constraints play in driving a great design solution may help you look at them more as your friend rather than your enemy.
While preparing a presentation about Design for Disassembly (DfD)—designing so that products could be disassembled easily for reuse and recycling as a way to protect the environment—I realized very quickly that just talking about DFD, although an important topic, was irresponsible and too narrow of a discussion. We, as product developers, are faced with much more to think about in our designs; much more for which we are responsible than just one goal . . . than just one constraint. How silly would it be to optimize a product’s design solely around its ease of disassembly and not consider other key factors like manufacturability, aesthetics, user interface or part cost? It is not that DfD is not important; it is just not the only constraint. Yet, we fall into that thinking when we are in the thick of the design process at work: “Mike, I can’t go that thin in that area or we’ll certainly fail our load test.” “Well, you are going to have to figure something out, John, because we can’t compromise on styling.”
The reason companies have divisions between departments at work is that they are only looking at their own world; their one requirement. Not only are they not willing to walk a mile in the other departments’ moccasins, they are not even willing to try them on. The tension created by product constraints is real and understandable. There is no easy way to work through it, especially when timing is tight and days are long, yet, when harnessed in the right way, the tension becomes the catalyst to a great design.
In his book The Road Less Traveled, M. Scott Peck makes this observation, “Once we truly know that life is difficult—once we truly understand and accept it—then life is no longer difficult. Because once it is accepted, it no longer matters.” If you substitute “Product Development” for the word “Life,” the statement is equally true. However, just saying, “It’s tough. Accept it!” doesn’t make it any easier, but it is a start to overcoming the frustration and team tension. Peck later points out in his book, “Problems are the cutting edge between success and failure.” Again, “Constraints” can be exchanged for the word “Problems” and the statement holds true. Our ability to solve problems, i.e., satisfy multiple constraints, is our competitive advantage in the marketplace. The more you can satisfy, the better your product will be. Instead of fighting for the sole constraint for which you alone are responsible, fight for the balanced optimization of all product requirements for your team. The success of your product in the marketplace depends on it. Over time, doing this well (or not) will also affect your company and ultimately your career. You may even find that you suddenly are getting along better with others on your team if you are showing a win-win desire to help everyone succeed.
In addition to developing a healthy perspective on product constraints, two other hurdles may exist that you’ll need to get over on your project: not knowing all the constraints and prioritizing ones that are conflicting. At our firm, we sometimes get projects that are quite undefined. At the onset, it is an exciting thought that we have a clean sheet of paper from which to start, but inevitably, we will flounder until we start narrowing down our focus with constraints. In fact, the more definition, the better. One of the items we ask for when kicking a project off is the complete list of product requirements. If any area is undefined, we put it on our issues list and strive to define it as soon as we can. Requirements that get defined late in the game can cause costly changes and time delays. Make it a goal to compile all requirements for your project in a single document as early as possible.
Also, prioritizing requirements as a team will help you make design decisions more effectively as you go. During my DfD presentation, I mentioned that a designer’s dilemma is deciding how to balance all the requirements. For example, Design for Assembly (DfA) techniques that drive part cost down may make DfD more difficult and vice versa. Or the intended manufacturing process may have normal variation that does not meet the tolerance requirements of Design for Six Sigma (DfSS). One practice that can help your team focus is to identify those requirements that are non-negotiable and those that are not. This will not only help the team make design decisions better, but will reinforce how the product is intended to compete in the marketplace (e.g., lowest cost, lightest weight, strongest, highest quality etc.).
Product development is difficult. Constraints are challenging and can threaten team synergy. Yet, the team that can satisfy the most constraints, and keep their heads on straight during the process, will come out way ahead.