Article
The Power of Making Mistakes During Product Development
"Do it right the first time" is total BS. If you want to create a great product, you need to eliminate perfection from your thinking and embrace making mistakes. The key is to learn from mistakes and quickly iterate and improve your design.
I don’t think any other six words in the English language have done more damage to product developers than “Do it right the first time” (otherwise known as DRIFT). Generations of engineers have been forced to endure endless hours of quality training where DRIFT was drummed into their brains. If we “do it right the first time,” the theory goes, we would be able to cut development cost, reduce development time and dramatically improve quality.
Executives love it. It sounds so easy and attractive. But it’s total BS. Here’s why.
I want you to think as hard as you can and answer this question: “What significant task have I ever ‘done right the first time’?”
Time’s up, and I’m going to bet that you came up with absolutely nothing. I mean, when you were born you probably needed help figuring out how to breathe! The truth is, to get just about anything “right” requires that you try, fail, learn and repeat the cycle until you get it.
The Myth of Error-Free Product Development
The expected benefit of DRIFT is the promise of faster and error-free product development. In my experience, it has quite the opposite effect. Product development becomes slower, more costly, and more frustrating for everyone involved. How can that be, you ask? The fundamental reason is that the implicit message in DRIFT and its various brothers and sisters like “measure twice, cut once” is “don’t make a mistake.” It is not “design a great product your customers will love that also makes your company a lot of money.” Although someone may add it as an Appendix to the Product Requirements Document under “misc.”
“Don’t make a mistake” leads to a variety of behaviors that can be counterproductive, including overspecification (aka “paralysis by analysis”), overplanning, and micromanagement. Proper specification and planning with the right amount of oversight is critical to success. However, when too much is applied too early in a project, the only result will be frustration and ultimately failure. If you’ve ever worked on a development team that’s focused on not messing up, you understand what the impact of endless planning, preparation, and review can be.
Great products rarely result from teams driven by a fear of failure. Great products are much more likely to emerge from a culture that listens to project stakeholders, hones skills with practice and training, desires to try the untried, keeps trying when things go wrong, and embraces serendipity when it drops by. Developing a great product requires balancing the right amount and type of effort at the right time. But mostly it’s about taking the risk to try, learning from our failures (and successes!), and repeating this cycle as quickly as possible as many times as necessary.
Tips to Avoid Unproductive, Overly Exacting Product Development
Here are tactics you can use to prevent aimless “DRIFTing”:
- Keep your specs simple. Don’t try to define every possible item that might arise at the beginning of a program. A little bit of risk analysis goes a long way. Document the big things, and don’t include how you intend to achieve them. Keep your specs alive and change them when necessary based on new knowledge and updated facts. Try to keep your specification documents at five pages or less. If they are any longer, no one will pay attention to them.
- Try, learn, repeat. When I was leading software development teams, one of the ways I could tell how close we were getting to the end was by looking at the rate of change in the source code. Early on, it was in a state of constant flux, but over time the change rate decreased, which meant things were starting to gel. The same is true of all product development. There should be tremendous change early on, and as failures are resolved, the rate of change will decline and the product design will converge. The key here is to do as little as possible in as short an amount of time as possible to validate ideas as quickly as possible. In fact, you should focus on making your product fail quickly, not making it work. Repeat as required.
- Plan what you can plan. Microsoft Project and Excel are wonderful tools, but they can be abused and lead you into a false sense of security if you equate a large number of detailed tasks in your Gantt chart and sub-dollar precision in your spreadsheet with planning accuracy. Don’t put everything you can think of in the project file. Keep it simple and focused to start. Fill in the gaps as you progress. There is nothing wrong with saying you will have a month to “ideate solutions with two engineers” as a single task instead of making up 25 unique subtasks that allocate everyone’s time to the minute. Add detail as the project progresses, but always strive to keep it as focused and simple as possible. After all, the only certainty about an MS Project Gantt chart is that it will be wrong once the project starts.
- Control your costs. You should strive to avoid spending a lot of money relative to the overall project budget during the early stages of development. Don’t wait to fully validate designs in their entirety, especially if they are complex and require expensive manufacturing techniques to build. Break the design down into its subsystems (we call that functional decomposition) and hack prototypes together to quickly (in)validate your ideas. Forget about cosmetics. If you can, scale the design up or down to make it easier to work with.
- Remember when it needs to be right. DRIFT originated in the manufacturing world and still makes a lot of sense in that environment. The closer you get to selling and delivering a product to your end users, the higher the impact of an error will be, and it is not a linear relationship. It’s one thing to make a new 3D print of a part that doesn’t work during development; its quite another to have to scrap an expensive injection molding tool in production. Just don’t let yourself fall into the trap of thinking that you can’t make mistakes before you deliver it to your manufacturing team. Failures always occur during product development; the key is to force them to happen at the right time!
Doing It Right Requires Making Mistakes!
Finally, don’t confuse DRIFT with “Do it right.” Never forget that your goal is to design a great product for your stakeholders. You’ll never get there if all you do is focus on not making product development mistakes. That kind of DRIFTing approach will turn your project into a wreck. Instead, make a lot of mistakes as early as possible and apply what you learn to your design with lightning speed.
You’ll be on your way to creating the next great product.
“I have not failed 10,000 times. I have succeeded in proving that those 10,000 ways will not work.”
– Thomas Edison (rumored to have developed a few successful products)
