5 Reasons Conventional Product Development does not lead to Innovation

Most companies involved in bringing new products to market want to be innovative and want their products to leap-frog their competition in terms of technology or other features and benefits. Many companies use conventional product development in tandem with a Stage-Gate process. Unfortunately, iteration or point-based design isn’t the best approach if the goal is leap-frogging and innovation. Why, you ask?

Iteration keeps you close to home

Iteration, by its very definition, keeps you close to home. You start with a particular chosen concept, then develop, test and iterate. As you iterate, you (hopefully) reduce risk and complexity from the starting set of features and functionality specifications. But overall, you tend to stay in a relatively close orbit around the concept you started with.

So, if you’re hoping to leap-frog the competition in terms of innovative new technologies or functionality, you can see how the conventional product development method can actually be quite harmful to the result you’re looking for. The best word (and I have all the best words 😉) to use to describe Iterative’s effect on innovation would be Insidious (Think Emperor Palpatine/Darth Sidious in the Star Wars Prequels!)

How Conventional Product Development typically operates

  1. Sales or Marketing functions define detailed product specifications for the new product. Often, Industrial Designers begin with designs they are excited about and then write detailed specifications to match their concepts.
  2. The team brainstorms and generates a number of concepts revolving closely around the specifications.
  3. Since the Launch Date is just a few months away, the team quickly picks a concept (I’ve been on a few projects where the concept got picked before the product specifications were even written!)
  4. The Design team fleshes out details and adds more needed specifications to the sub-systems and components.
  5. The design is handed off to the Development team for more detailed engineering of the product and its sub-systems and components.
  6. The team then tests the product and all its sub-systems and components. Based on test results, the team will iterate a few times to improve the concept.
  7. The Product is now handed off to the Manufacturing teams. They now have to repeat the “detailing” in terms of manufacturing processes around their systems.
  8. Some Manufacturability issues are discovered during cost-intensive phases like Tooling.
  9. By this time, the teams are pretty close to the launch deadline so they make conservative decisions that keep them very close to the original concept and the deadline, or the project gets cancelled.
iterative product development
Iterative Product Development keeps you close to home

5 Reasons why this is fundamentally flawed

  1. The team picked one concept to work on right at the start of the project based on old information. They did this without waiting for the project to progress and generate new learnings and new data. This forces High Risk or Low Innovation
  1. All the desired specifications were decided at the beginning, again, on the basis of old information. These specifications were a trade-off between what was really wanted and what current technology would allow.
    • At the beginning, we only know what current technology or “state of the art” will allow. We would need to guess what kind of technology will be available at the end of the project.
    • By doing this, we end up with designs that may be over-stressed , over-complicated or under-challenged.
  1. Project decisions are made based on a combination of what is known today and what maybe possible in the future (Wishful thinking, a Waste)
    • Designers often find current technology too constraining for their design aspirations, so they prefer betting on what’s possible in the future.
    • The teams end up trying something so bleeding edge that they don’t know enough about, or how to test and end up with expensive quality issues to deal with late in the development cycle.
  1. Only one concept ends up getting tested the entire design cycle, which is very slow and expensive. Also, the learning from the testing of just one concept, ends up not being very useful for future projects.
  1. All of the above leads to a bunch of project chaos, scatter and rework.

Conventional Product Development forces teams to ask the “Is it worth it” question over and over again. Everything ends up being a trade-off between cost and expectations. It starts off with the best intentions of providing value to the customer. But it quickly devolves into conversations about risk and cost versus the customer.

Iteration is still good for projects where huge innovation is not the goal. It’s still great for product launches where you are going to modify or “Tailor” a few elements from the original design. It also works for “Reintegration” projects. Reintegrations are projects where you only innovate certain selected sub-systems in order to create the effect of maximum re-use.

There is an alternative model where multiple alternatives are explored simultaneously and is better suited for innnovation. It is called Set-Based Concurrent Engineering and you’ll have to wait a week to read about it on my next blog post.

References: [1] Ward, Allen & Sobek, Durward, Lean Product and Process Development [2]. Morgan, James and Liker, Jeffrey, Designing the Future

4 Thoughts

  1. I had a few readers reach out to me and say that Iterative Product Development worked wonders for them. When I probed deeper to understand their success, they all had one common theme – they were iterating off an established and pre-existing successful product concept.

    Maybe I didn’t explain it well above, but this was exactly the point I was trying to make. Iteration or Point-based design is perfect and great for when you are working on new products that are modified versions of an existing product, or when you need to re-integrate an existing product, but perhaps with a newly engineered sub-component or sub-system of some sort. Even Toyota only uses Set-based Design as an absolute last resort.

    They try to accomplish launching the product with variations of standard, existing platforms, systems and components using Iteration. They resort to Set-based only when they have nothing to strong to iterate upon. For example, Toyota used Set-based for the Prius and Lexust brand launches, as they had nothing existing to use as a template to iterate upon.

  2. Hey, this is such a great article! Thanks for sharing. Our team will be excited to read this. We are UI UX design agency in Mumbai and we regularly also express our views on UI UX and product design. Do visit our website for more related content.

2Gemba thrives on reader feedback! Please feel free to share your thoughts!

This site uses Akismet to reduce spam. Learn how your comment data is processed.