Three Critical Misconceptions in the Product Development Process

Reform of the product development process is not progressing as expected.

You know what the problem is to some extent, and you think you are making progress in reforming the development process: you haven’t had a hit product in years, you are developing the same kind of product but keep having the same kind of problems, and you are always behind schedule. I would like to know what is wrong and what is lacking.

I would like to know what is wrong and what is lacking. I will answer such questions from the standpoint of someone who is familiar with the development sites of several manufacturing companies in Japan and the U.S.

Three Critical Misconceptions in the Product Development Process

Sometimes what you do for the best of reasons is actually the true cause of the problem

If you think that there is something wrong with the product development process, I would like you to review the following three points when you take action to deal with problems occurring in the product development field.

• Seeking to build things (prototypes, etc.) quickly
• Thinking that it is important to reuse design assets
• Improving efficiency by splitting up specialized areas and dividing labor

It may not be that each and every logic is wrong, but in fact, there is a big pitfall in blindly believing and proceeding with these.

Demanding that things (prototypes, etc.) be built quickly

”Don’t worry about anything, just make it!”

I can hear you saying, “It’s faster to build it than to think about the theory! ”

“Don’t think about it, just do it!” is also true in some cases.

However, I would like to stop here and think about whether this is also true in product development.

Even if you are developing similar products over and over again, the structure and operating principles of most products are complex in their own way.

Even though they are called similar products, as new products, they contain no small number of new functions and new challenges.

In the product development process, if you are asked to make a product first, it would be wasteful in terms of both cost and time to make it, try it out, learn various things, and then use the knowledge you have learned to start all over again.

In other words, development is carried out in the form of improvements and upgrades to the base prototype that was made anyway.

In fact, this is the most important point that is often overlooked and is the start of mistakes.

This way of doing things is to create a shape, even if it is a muddy boat, and then modify it from there, splicing and patching it together to create a good product.

No matter how good an orthopedic surgeon you are, there is a limit to how much you can splice together.

The quality of the first prototype (mud boat) will actually leave an absolute impact on the quality of the final product.

A poor quality prototype will have hidden seeds of quality problems inside, and the problem areas will often survive to mass production.

This is the reason why prototypes should not be made too early in the product development process.

Toyota’s product development method is an example of success without making prototypes quickly.

It is also called the set-based development method, and is clearly distinguished from the conventional method of quickly deciding on a method and manufacturing products at a single point, which is called the point-based method.

The title of the book by Kimio Inagaki, who was the first person to introduce Toyota’s lean product development method in Japan, is “Delay Decision-Making for Development Strategy”

See at Amazon

We need to change our way of thinking so that we can reach innovation by testing and learning from what we don’t know, what is unknown, and what challenges us in small units (Minimum Viable Experimentation).

Think it’s important to divert design assets

Put your past design assets to good use!

This also sounds like something a senior manager would say, and yet it is not wrong.

I know several companies that have failed badly by forcing the reuse of their design assets.

The reasons for failure are twofold.

• The design assets to be reused are not at a level that can be used elsewhere.
• The engineers who reuse the design assets do not understand the required specifications and quality and the quality of the assets to be reused.

I don’t know if the term “goodness theory” is appropriate, but we tend to think that design artifacts that work on one model will work on any model or environment.

If the first designer designs his design deliverables to work in all environments and models, and if they are verified to work in all environments, he gets a perfect score of 100.

At least 70 points (-30 points because it has not been verified) if the designer has taken care to design the product to work in all environments and models.

However, in the reuse of design assets that I have seen, things that were designed only to work on one model fail when they try to use them directly on other models.

This is obvious if you ask me, but among senior managers, there are quite a few who are not sensitive to this kind of variation.

The development process is set up with the idea of reuse in mind.

Even managers who are working a little harder put pressure on the designers to make sure that the design is usable for another model, but as mentioned above, it is not verified, so it is a 70-point situation.

Moreover, the problem is not a simple matter of simply replacing some of the design assets, but in many cases, the surrounding designs that are to be replaced have also changed significantly.

It is not a simple matter of proceeding with the modular design.

Anyway, theoretically speaking, if something is working on a different model, it should be able to be used elsewhere, and it will eventually cause major quality problems without compromising the premise.

Furthermore, if there is such a dangerous situation, the designer who takes over the design asset should be aware of it, but as mentioned in the second reason here, the designer who tries to reuse the asset is not aware of this risk

To put it more simply, the fact that the development process is organized on the premise of reuse on a module-by-module basis means that there is a big misunderstanding that the module is technically complete and does not need to be looked at, and that technically inexperienced designers are assigned to the module on the assumption that even those who do not understand it can do it.

I think there is a big misunderstanding of reusing design assets as, “using the design results as they are.”

In essence, reusing design assets should be “reusing technology and know-how.”

From using design results (drawings and software source codes),we need a development process that reuses “the background of why we design in this way, technology and know-how.”

This will be the transmission of technology within the organization, and through the transmission of technology, young people will grow up and the skills of veterans will remain in the company.

Improving efficiency by dividing specialized areas and dividing labor

When developing multiple similar models on a continuous basis, there are many companies that promote the division of labor by dividing the area of expertise into smaller parts and organizing a group of specialists into a functional organization in order to increase development efficiency.

I don’t think it’s wrong as an idea, and I think it’s important for engineers to have a single, coherent specialty.

The problem is that by being too immersed in one’s area of expertise, it becomes impossible to deal with problems related to cooperation with other fields and other units/components.

I have seen many engineers who can quickly deal with problems within their area of expertise, but when a quality problem occurs, they try to look only at their own unit to see if there is a problem, and once they have evidence that there is no problem in their area of responsibility, they eliminate responsibility for the rest as not being their problem.

Problems that span across multiple units, problems that are compounded, problems that are not coordinated between units as designed, etc. are left unidentified as problems in any of the areas of expertise.

Also, when such problems actually occur, it takes more time than necessary to solve them.

In product development, it is absolutely necessary to have an architect, a person who has a deep understanding of the overall structure and principles of the product, and who is responsible for the overall design of how each unit/component works together to form the operating principles, and who also manages the coordination.

In a product development organization, there are usually several people who are called architects.

Incidentally, Toyota has a chief engineer (chief inspector system) who is also an architect and who controls the entire value chain, including planning, sales, manufacturing, service, and purchasing, beyond product design.

Now, why is it a misconception that it is a good idea to divide the work into specialized fields? The problems that occur during product development are not only caused by the contents of the units, but rather by the coordination between the units and the operating principles within the overall structure.

While it is important for a company to have engineers with their own specialties and to nurture those specialties as a company, it is equally or more important for a product development organization to nurture architects who can understand the operating principles of the overall configuration and distribute the functions.

Rather than architects or specialists, it is also necessary to develop specialized engineers who can at least look at the connections with other units and take responsibility while being in charge of their specialized area.

In my view, this is actually happening in many companies, where the responsibility and awareness of the functional organization in charge of a specialized area is strengthened more than necessary, resulting in a reduced sense of belonging to the product as a whole, and also in a majority of engineers who cannot see the overall problem.

Essential Approaches to Product Development Process Reform

We have looked at three critical misconceptions in the product development process.

In each of them, I believe that the problem is not that each idea is bad, but that the process of operation has deviated from its essence.

When thinking about reforming the product development process, I think it is necessary to suppress the following points from the three misconceptions.

I believe these are the essence of product development.

And in order to regain this essence, I believe that rather than changing the process itself, each and every engineer must imprint this essence in their body.

Once, when I was in charge of the development department of an EMS company in the U.S. (Japanese subsidiary), I was discussing the development process with my boss at the U.S. headquarters, a genius engineer with an IQ of 250, and he said the following.

「He said, “You don’t need a process in an organization with only A-players (let’s call them A-players), you need a process to achieve a certain level of results even if you have C-players and D-players.”

I was shocked, but at the same time I felt a strong sense of conviction.

The three misunderstood development processes I pointed out were all set up in a way that they didn’t believe in the engineers, or as my boss put it, they were set up so that C-players and D-players could get by.

Then I began to think that what we should essentially do is not to bind them with processes and rules, but to make as many engineers as possible into A players.

Unifying our thoughts with a successful model and changing it to our own unique model

There is a recommended way to think about reviewing the development process and to promote development process reform
An example that captures the essence of the above product development is the Toyota method of lean product development.

• Development method of filling in the unknown step by step　→　Set-based development
• Reuse technology and know-how　→　A3 report culture
• Understand the principles of the entire product　→　Chief Engineer System

＊For an overview of lean development methods, please refer to “What is Toyota-style Lean Product Development?”

It can truly be an exemplary model that addresses the three misconceptions.

However, what has become widespread in the world as Toyota-style Lean development is actually a theory systematized by American scholars based on what Toyota is doing.

Therefore, I think there is a twist or a challenge in putting it into practice.

We take the Lean Development Method as a theory, and by doing so, we change the awareness of our employees, and the practice is just to change it into our own unique model.

We have the know-how to teach the Lean product development methodology as a theory, and to change it into a unique process or culture within the circumstances and constraints of each company.

If you are considering reforming your product development process or changing your mindset, please contact us for a consultation. Please fill out the form below and we will contact you.