What is Toyota’s Lean Product Development Method?
Toyota’s production system is so well known, but is there anything special about its product development?
I will outline the three key elements of the Toyota Lean Development Method and its implementation based on my experience of teaching the Lean Product Development Method and providing organizational reform support for many manufacturing companies regardless of product area, including automotive related, home appliances, communication equipment, office equipment, healthcare, metal processing, and others.
While it is said to be the development method of Japan’s Toyota Motor Corporation, the method started to spread from European and American companies and is gradually gaining attention in Japan. Let’s decipher the essence of this development method to see if it can solve various problems occurring in product development organizations.
Rather than just adopting the methods that have been handed down as theory, we will explain why this method works well and how to apply the theory to your own organization and put it into practice.
Contents of this article
What is Toyota-style lean product development?
I would like to explain in as simple a way as possible what the Toyota method of lean product development is all about.
The Lean Production System is the most famous of the Toyota methods.
Lean product development, on the other hand, is actually not so well known.
In the first place, the development methods of each company are usually kept secret from the public.
Toyota did not try to disclose their own development methods, and in my opinion, they probably did not even think that they were practicing a special development method.
First, let’s look at the historical background of why the Toyota method of development became widespread.
Around the 1990’s, Allen Ward, an assistant professor at the University of Michigan, came to Japan with his mentor, Professor Jeffrey Riker, to observe the Japanese automobile industry and learned that Toyota was practicing the set-based development that he advocated.
After that, Allen Ward sent his students to Toyota to study Toyota’s development methods in detail and systematize them.
Allen Ward later became independent as a consultant and worked to spread Lean product development in the U.S. Unfortunately, he died in a plane crash in 2004.
Unfortunately, he was killed in a plane crash in 2004. After his death, the manuscript of the book he was writing was discovered, and thanks to the efforts of the people around him, the book Lean Product and Process Development was published, accelerating the spread of Lean development once again.
In the U.S., Harley-Davidson and Ping, a golf club manufacturer, introduced Lean product development and achieved success.
Among them, Teradyne Vensos, a manufacturer of inspection machines, also enthusiastically promoted Lean development, and Bob Melvin, the general manager of the development division of Teradyne Vensos, created a unique process and published a book called “Knowledge Based Product Development.
In Japan, Kimio Inagaki (President of Globaling Co., Ltd.), who had translated books by Professor Riker, a famous researcher on Lean production and Toyota, published a book titled “Development Strategy Delays Decision Making” in 2012 to introduce Lean development methods to Japan.
This is the historical background of this trend.
As you can see here, the Toyota method of lean product development was actually theorized by American scholars and spread in Europe and the United States in the beginning.
The Lean development method, which is expected to spread in Japan in the future through the translation of books from the U.S. and Mr. Inagaki’s book, has its starting point in Toyota, but I think it is important to understand that what is being handed down is a theory that has been developed by scholars.
You can’t make reforms in the field just by reading idealistic theories. I think it is important to read the essence from the ideal theory.
Let’s take a look at the overall picture of lean product development.
When you read books, you tend to think that it is a complicated method and a complicated system, but in fact, there are only three important mechanisms that are key.
- Chief Engineer System
- Set-based development
- A3 Report
Of these, the chief engineer system and the A3 report are relatively well known, and many of you may be familiar with them.
Many companies are trying to copy and adopt the chief engineer system.
However, as far as I know, many of them are just copying the form of the system and not achieving the desired effect.
Similarly, there are many companies that have adopted or are planning to adopt the A3 report, but I often see cases where it is unclear what they are trying to achieve by establishing the A3 report.
As you can see, the three mechanisms of Lean product development are not just about creating a mechanism, but it is very important to know what the mechanism should achieve.
What the three mechanisms seek to achieve are
- Reduce development time
- Maximize the use of organizational knowledge
- Eliminate waste by integrating planning, design, purchasing, manufacturing, and sales
- Create a process with no rework
- Develop products that customers really want
- Create an organization that is constantly learning and improving
- Create an organization that develops human resources
The essential objective is to achieve these things, and we need to recognize that the structure is a means to achieve it.
The most important thing is to learn what kind of effects can be obtained by creating a system or process, to set the objectives that each company wants to achieve, and to create a system or process that is appropriate for that company.
Let’s take a look at the three mechanisms of the Toyota method of lean product development one by one.
Chief Engineer System
The first one is the chief engineer system.
In a typical development process, the value chain (planning, design, production preparation, production, and sales) is managed in phases, and the person in charge of each phase passes on the baton of responsibility in a relay fashion while managing the phase gates.
In Lean product development, on the other hand, a single superman called the Chief Engineer manages the entire value chain in a single process.
The chief engineer not only manages the project, but is also responsible for the product liability, or profitability, of the model he or she is in charge of.
The chief engineer is also expected to have the ability to act as a marketer, planning the products that customers really want, strengthening and maintaining relationships with outsourcers, controlling the organization by function, optimizing the use of human resources, managing the learning process, etc. The chief engineer uses a wide range of knowledge and know-how to lead the project to success.
By concentrating responsibility on a single person throughout the value chain, we can maintain consistency in development philosophy and policy, smooth communication between phases, and greatly prevent rework and waste caused by communication problems and organizational barriers.
However, it is not easy to cultivate such supermen and super generalists. Perhaps Toyota’s strength lies in its culture and history of creating such human resources, as well as its system for passing on know-how, and this is the reason why other companies cannot easily imitate it.
In order to implement the chief engineer system, it is necessary to abolish the phase-gate development process.
This means that the entire organizational structure and the entire process from product development to manufacturing and sales needs to be reviewed.
Even if you can’t make such a drastic change, there are many companies that would like to promote projects with strong leaders who are comparable to chief engineers, even if only within the scope of product development projects.
In order to imitate the good points of the chief engineer system and to incorporate it as a mechanism, project managers (PMs) are organized to create strong leaders.
However, if we don’t decipher the secret of why Toyota is able to produce excellent chief engineers, including not only the organizational structure but also the cultural background, who succeeded first and how it was passed on, etc., I think we will end up with mere negotiators across organizations with only the title of PM, and operations that are far from ideal.
The following reference article explains in detail about the selection and training of project managers. I hope you will find it useful.
Reference article :Be Aware of the Awesomeness of Chief Engineers, and Develop Excellent PMs First!
Many books have been written about Toyota’s chief engineers, but the book “Toyota Chief Engineer’s Work” by Naoto Kitagawa, a former Toyota chief engineer, gives a very clear picture of how Toyota’s chief engineers are trained and what they actually do.
Set-based development
The second mechanism is called set-based development, but before we talk about set-based, let’s look at the problems of conventional development.
In contrast to the term set-based, the traditional method is called point-based.
In many companies, while examining the methods to achieve the target specifications at the conceptual stage of development, they decide on one method to adopt and proceed with development accordingly.
This is also the origin of the name “point base.
In the conceptual stage, there are usually many unknowns and challenges to be tackled, and at this time, there are usually multiple candidates of possible methods to tackle these challenges.
When selecting the most appropriate method from the multiple candidates, experts gather hypotheses and opinions on various evaluation items, have a heated discussion, and then select one method in a form of a circle-and-× formula to make a formal decision.
In this process, the evaluation is a mixture of facts, predictions and opinions, and in the end, the method is decided by saying, well, this seems to be the best one.
After deciding on a method, the priority is to manufacture the product as quickly as possible, and the process of detailed design, prototyping, evaluating, identifying problems, correcting, and prototyping again is repeated until the product is ready for mass production and sales.
In other words, the idea is to build a muddy boat and ensure quality while crushing problems. However, it takes time to solve complicated problems, side effects can lead to a whack-a-mole situation, and more importantly, the time required to solve the problems is unpredictable and people try to shorten the time by psychology, which leads to schedule delays, rework, excessive overtime, and other problems.
Since the method is decided at the early stage of development, the quality of the product will not be any better than what was decided at the conceptual stage.
It is difficult for developers to create products that excite them while developing.
Solving problems is also a race against time, and there are many cases where a product is launched without being able to solve or find the problem, and it becomes a market problem.
As developers are driven to solve problems for market problems, they lose time to do new things.
As a result of trying to continuously develop a large number of models with a small number of people, the development method may have actually created a vicious circle.
Set-based development is a solution to this kind of problem.
At the conceptual stage, we have to figure out how to create new customer value, what are the technical challenges, what knowledge we don’t have, what are the trade-offs, how to solve them, and how to acquire new knowledge, and then solve them one by one.
While repeating small experiments and small hypothesis tests, we continue to learn as an organization and make decisions based on the results of our learning in an orderly fashion.
In the learning cycle, we set up small decision-making events called integration events, and from the learning results, we decide on the next action and narrow down the method again.
As the learning cycle progresses, hypotheses about technical issues and customer value are verified, and when the method is decided, the technical issues are solved and the exciting product that the customer wants is completed.
Since the integration event basically involves all the stakeholders, there is no need to go back later to overturn decisions, and since the learning cycle solves detailed technical issues, at first glance it may seem like a method that would take extra time, but when you think about it in total, it can actually save a lot of time.
When I explain the concept of set-based development, I sometimes hear executives from major companies say that we already do this kind of thing because we separate element development and product development in our company.
However, the concept of set-based development is not at the level of separating element development and product design, but rather, it is a development method in which all the unknowns, or possible risks, are brought out in the product design, and risks and knowledge are acquired as development proceeds.
Set-based development is a system that is difficult to understand exactly, and it is also a method that is difficult to understand how to put into practice.
I think the important thing is to acquire and accumulate new knowledge step by step about what you don’t know and what is unknown.
Please consider the approach of how you can apply it to your own processes.
For more information on how to implement set-based practices, we can assist you.
Related article:
Understanding Set-Based Development
Obstacles to Implementing Set-Based Development and How to Logically Convince Top Management
※ The book is based on the author’s experiences in a manufacturing company and the experiences we have had in the past.
It’s a very realistic story. For more information, please refer to “Break the Common Sense of the Product Development Organization” For more information, please refer to the publication announcement.
A3 report
The third mechanism of the Lean Product Development methodology is the A3 report.
The Toyota style A3 report is more than just a report.
It is closely linked to the set-based development process, and is used to accumulate the knowledge acquired in the learning cycle within the company.
It is an intellectual asset of the company, an asset of the veteran’s tacit knowledge, a source of information to avoid repeating the same mistakes, and a driving force for innovation.
It is not the end of the story once it is written, but it will lead to the development of both the supervisor and the subordinate as they work together to improve and nurture it.
In order for the report to be concise and to be used correctly by the readers within the company, it must be written with a solid story so that it can be understood in a short time.
When an A3 report takes root in an organization, the ability of the entire organization to think will improve, and organizational strength will be greatly enhanced.
Many companies are trying to introduce the A3 report because it is easy to understand at first glance and the results are easily visible.
However, it is important to note that simply making the report format A3 and asking employees to write anyway will not have a true effect.
Product Development Innovation through A3 Reporting Culture
A case study of organizational reform through improved report writing
Lean development practices
Do you understand the three mechanisms of lean product development?
As I mentioned in the beginning, Lean Product Development Methodology is provided as a theory, and in order to implement it in your company, you need to understand the essential meaning of the three mechanisms, consider your own circumstances and concerns, clarify the objectives you want to achieve, and create your own process.
If you try to adopt only the form of Lean product development, it will never work.
It is essential to analyze your company’s current situation objectively and accurately, while reading the essence in the theory and putting it into practice.
In addition, it is essential to grasp the essence of the method and innovate the development process while utilizing the company’s own circumstances and commitment.
The figure below shows the process that an American company called Teradyne Vensos went through over a period of about five years, learning Lean development, gradually incorporating its essence, and making improvements. In the book “Knowledge Based Product Development” (not for sale) that I mentioned, the story of the reforms that this company undertook is described in detail, and the author of the book says that the most difficult part was to establish the theory as their own process.
Teradyne’s approach seems to have been to start by having all employees write A3 reports to accumulate knowledge within the company.
The message from the top management was, “If it’s not on A3, it doesn’t exist in this company.” So, we will establish the A3 report culture.
The relationship between the development process and the A3 report database was clarified, and the company’s own decision-making system was established.
The head of the development department at Teradyne recalled that they were able to do this because the president himself took the lead in promoting the reform.
However, at the same time, I was impressed to hear him say that even after seven years since the start of the reform, the chief engineer has not been trained yet, although there are two candidates.
Difficulties in Lean Product Development Practices and How to Address Them
I have explained the three key elements of Toyota-style lean product development: the chief engineer system, set-based development, and the A3 report.
I believe that each of these elements should not be thought of as functioning separately, but rather as three elements that make up one development system.
In other words, practicing Lean development methodology means redesigning and implementing the “development system”.
To “reform” means to change the status quo.
Why change?
How to change?
If there is no guideline for why and how to change, the reform will not be successful.
If you think that you can just copy what Toyota is doing because it is successful, you will definitely fail.
First of all, I think it is important to work with the idea of changing the development system, not just one element at a time.
The approach we recommend when adopting the Toyota method of lean product development is to reform the flow of information called “knowledge”.
The aforementioned company, Teradyne Vensos, has implemented a reform of lean product development by reading it as “knowledge-based development.
They created a development system that allows the entire company to create knowledge, distribute knowledge without stagnation, accelerate innovation through knowledge, and achieve development efficiency by eliminating waste of internal resources.
And the chief engineer is the one who leads the organization so that the “knowledge information” can flow smoothly within the organization.
The idea is to create a development system that uses set-based development to accumulate new “knowledge” and leave it as an A3 report, and to draw out the “knowledge” already in the company from the A3 report and utilize it in development.
The premise of this reform is that the current way of development causes various problems due to the lack of smooth flow of information.
Conversely, if the cause of the problem in the development organization is the stagnation of information distribution, the idea of reforming the flow of “knowledge information” fits perfectly, but if the cause of the organizational problem is elsewhere, this idea does not apply.
First of all, I think it is important to firmly and accurately understand the root cause of the current organizational problem to determine whether the Toyota method of lean product development can be used.
At our company, we use TOC (Theory of Constraints) to analyze organizational problems. (Reference article: “What is TOC? ～How to apply TOC to a product development organization”)
Now, how was my talk on the theme of Toyota-style lean product development?
I would be very happy if you could get some hints from it.
We offer a product development innovation support service to help you understand the root causes of organizational problems and create your own development system.
We also offer a “free trial seminar” to help you understand our services. (See “Product Development Innovation Support Service Information”)
Related Article：
How to turn an idea into a product with Lean Development
How to proceed with futureship development process innovation and the time required
Lean product development methodologies are not meaningful if only one person in the organization understands them.
The majority of the organization must understand the benefits and have the support of the management.
We have experience in understanding the organization as a whole and how to persuade the management.
In addition, there is a limit to how much you can objectively analyze your own development problems on your own.
We have a lot of experience in reforming global companies and companies with different products.
Please feel free to contact us if you have any questions about product development reform.
Please contact us using the form below and we will get in touch with you.
