Why do we need a product development process?!
What is a product development process anyway? Or why do we need a product development process? If it is necessary, how should it be created? Or how should we optimize it?
As an expert in product development consulting, I will explain how to create or optimize a product development process by what procedure and with what approach.
Contents of this article
- What is the product development process? Reform starts with the question, “What is the best way to achieve this?
- How do we reform the product development process?
- Product development process reform through case studies
What is the product development process? Reform starts with the question, “What is the best way to achieve this?
Plan a unique product, develop it, prepare it for production, mass produce it, and sell it.
Basically, the way of doing manufacturing business should be a straight path no matter who does it, but in reality, there is a clear difference in the competitiveness of each company.
There may be a lot of debate as to whether this difference is born from differences in the attractiveness of the product, or differences in sales force, or whether it is the presence or absence of production capacity to make things with high quality, or whether it is the difference in overall strength of all these factors combined
Although we can somehow predict that the product development process has something to do with it, what is the product development process in the first place? Or why do we need a unique process for a single way of doing things?
If you have a good idea for a new product, find a way to materialize it, commercialize it, mass-produce it, and sell it with just a few members, for example, you will just be doing what you need to do in a straight line while thinking about the overall flow.
Basically, the starting point is that there is only one process for product development.
Then, what is the development process in a manufacturing company? I think we can say that it is “the procedures and rules that show the roles of each organization and how the work of each organization should be coordinated“as the activities that started from a small group of people continuously transition to creating products as an organization.
From a larger perspective, if we look at the flow of product planning, product development, production, and sales, the roles and responsibilities of the organizations in charge of each step, as well as the timing and conditions for handing over to the next step, are determined, and responsibilities are passed to the next step in a baton style, so that the product can finally be delivered to the customer. This can be called the product development process in a broad sense.
On the other hand, if we look at product development only in the framework of product development, the role of product development is to receive the requirements from product planning, i.e., product specifications, and create blueprints for manufacturing products according to the specifications or information for manufacturing.
Both the broad sense and the narrow sense can be considered as a product development process.
Again, a product development process is “procedures and rules for organizational activities that are set up to carry out product development in a systematic and continuous manner“.
Furthermore, since it is an organizational activity, the organizational structure itself can be considered part of the development process.
What kind of roles and authorities each organization has, who makes the decisions in various authority transfer situations, and the transition conditions are also part of the development process.
In this sense, creating a development process also includes organizational design.
When a small number of people are developing a single product, there is no need to create a product development process.
You understand that you need to create a product development process because you are developing products systematically and continuously.
Now, if we look a little more closely, I think we can consider the reasons for defining a product development process from the following two aspects.
- To equalize the difference in abilities of developers
- To increase the productivity of the entire organization
To equalize the difference in abilities of developers
On a similar note, if a small team of truly talented members develops a product, there is no need to prescribe a product development process.
This is because everyone understands what needs to be done.
The first reason for creating a product development process is to equalize the results so that the differences in the abilities of the developers do not show up in the results, so that anyone can develop a product of a certain level.
Especially when a company wants to expand its product lineup by developing a series of products or making minor changes, the product development process becomes important because the company wants to develop products of a certain level of quality even if not all members are excellent.
Increase the productivity of the entire organization
When people say, “I want to do something about the development process,” they are often targeting the development process regarding this goal.
As the organization becomes more complex and the product system becomes more bloated, the product development process begins to fray.
This means that the “product development process” is flawed, or that the “product development process” has not been designed properly.
In an ideal product development process, the organization itself functions without wastage, cooperation among the organizations is smooth, and the resulting products are of high quality and are always well received by the market.
The first part, “the organization itself functions without waste,” also depends on the quality of the personnel that make up the organization.
In other words, a good product development process can create excellent human resources and make the organization stronger.
There are clear procedures and rules for inter-organizational collaboration, good division of responsibilities, monitoring of product quality and customer evaluations, and feedback and corrections when necessary.
This means that the productivity of the organization as a whole is high, and the goal is to maximize the productivity of the organization by prescribing a product development process that matches the capabilities of the personnel and the organization.
In my work as a corporate consultant, I have seen that many manufacturing companies are troubled by a number of problems related to product development.
Typical examples are the following problems.
- Schedule delays have become the norm
- Frequent quality problems
- Younger employees are not developing well
- Too many specification changes and frequent rework
There may be more than one reason why these problems occur or continue to occur, but it may be that the “product development process” is incomplete.
Since the ideal “product development process” is connected to the power of the organization and the ability of the individual, it is necessary to grow it together with the current situation of the organization and the ability of the individual, rather than creating the process alone.
In other words, I believe that the “product development process” is something that is continuously reformed and built up.
If the same problem repeats itself continuously, it is a sign that the product development process should be reformed.
What should not be misunderstood is to think of the product development process as a form.
Think of the product development process as a living organism that grows together with people, and nurture it by watering and feeding it.
The same kind of problem is continuously occurring in the product development organization.
If you think that the product development process may be the cause, that’s the start of the reform.
I will explain what steps you should take and what you should do.
If you have doubts about your company’s product development process, you should first look at the outside world.
Study companies in the manufacturing industry that have, or are said to have, strong organizational capabilities, such as Toyota.
What we recommend is to create a development process that follows the Toyota Lean Product Development Method.
As for the Toyota method, there is an overwhelming amount of information on production-related topics, but recently, books and information on development-related topics are also increasing.
When looking at the product development process of a successful company, what I would like you to pay attention to is not the form of the development process itself, but rather to learn about the historical background that led to the creation of the process, the twists and turns that led up to the creation of the development process, and the things that went wrong in the process of creating the process.
The reason for this is that, for example, Toyota is famous for its development system, the chief engineer system.
There is even an anecdote that even Ford in the U.S. tried to imitate Toyota’s chief engineer system and failed.
If you try to bring in the form and process of the organization itself from a successful company, it will not work.
It is important to understand the essential reasons and background of why the process was developed, and to imitate the way it was introduced.
It is also important to synchronize the development process reforms with the human and organizational capabilities.
If the process and organizational structure are beyond your actual capabilities, you will end up with a process that is not well executed.
Reference article： “What is Toyota-style lean product development?”
Why is your company’s current development process the way it is?
It is very important to ask such questions.
One pitfall regarding the product development process is to make the assumption that the current process is the right one.
When the product planning department presents the specifications to the development department, the development department conducts a feasibility study to realize the specifications and formulate a product concept.
At this time, in the development process of most companies, if there are multiple realization This process is part of the development process, but it is not a unique process.
Once the realization method is determined, detailed design is started according to the method, and a prototype of the product is completed.
This sequence of steps is part of the development process, but it is not a unique process.
There is a big difference in the mindset toward reform if you take this approach for granted or if you think there is some other way.
Why is the process of quickly making a prototype of the entire product adopted?
If you are developing a completely new product, wouldn’t it be better to gradually build up the functions and performance of sub-units and components while checking the elements that realize the functions one by one, rather than building the entire product right away?
Why do you make a prototype of the entire product so quickly?
If you have experience in developing similar models, and you think it would be faster to make one based on the previous model, that’s fine, but it’s important to question whether that method is really the best, and to think about what would happen if you used a different method.one method that has the highest feasibility or increases the value of the product and decides on the realization method.
There is also a debate as to which is the better organizational structure: to gather all the people involved in the development of a single model and proceed with development with the optimal lineup for each model, or to create an organization for each specialized area and prioritize the completion of development in each technical area and provide as much common technology as possible for multiple models.
We can think of the development process as a choice between creating a development process with the objective of optimizing the development of each product and each model while maintaining its individuality, and creating a development process with the objective of efficiently developing multiple models or providing consistency by incorporating common technologies in multiple models.
Think about your company’s development process at the moment, and for what reasons you are adopting the current way of doing things.
Once you know why you are using the current product development process and what your objectives are, you can then think about what you have sacrificed to achieve those objectives.
Let’s consider a case study.
Companies that are expanding their sales through existing businesses tend to adopt a product development process that involves gathering the necessary developers for each model in order to carefully develop and sell each model at the beginning of the existing business, but as the business gets on track and the sales volume increases, the product life cycle becomes shorter. However, as business took off and sales volume increased, product life cycles became shorter and the market demanded an expanded product lineup, making it necessary to develop many models at once.
As a result, the need for efficient product development led to the adoption of the concept of developing each model group at once, which led to the gathering of experts in each specialized technical area in one place, and the process of one expert or developer being involved in multiple models.
By gathering experts in the same area, we can improve the level of each technical area, and maintain consistency because there is no difference in concept between models from the customer’s point of view.
However, in the process of seeking efficiency by organizing each specialized area, what we have sacrificed on the other hand is the individuality of each model and the efficiency when looking at the development of only one model.
Instead of closer communication among the same specialists, there is a danger that communication with members in other technical areas within the model will be neglected.
When all the members necessary for the development of one model are gathered for development, the developers can feel what other specialists are working on, what they are struggling with, and what solutions they are trying to take, even if they are not aware of it, and this allows the development members to casually absorb knowledge and wisdom about the entire model development. However, when specialists are connected with each other, they cannot know what other specialists in the model are usually doing, and as a result, they cannot gain knowledge about the model as a whole.
By increasing the technical capabilities of specialized areas, the organization loses knowledge about the configuration of the entire product, the principles of operation, and the connections between units and components.
This is because there is a gap between the time it takes to see the benefits of changing the product development process and the time it takes to see the symptoms of the sacrifice, and the problem is not recognized until after it has become a major issue.
In the example above, the development efficiency by forming a group of experts increases immediately, but it takes several years before the knowledge of the entire product does not arrive, thereby lowering the level of engineers.
I believe that many companies suffer from this kind of time lag in the occurrence of problems.
When reforming the product development process, what you should not make the mistake of doing is thinking that if the problem is caused by something sacrificed in the current development process, you can just undo the sacrifice.
Instead of finding a solution as a choice between two options that you have to choose between, think of a solution that achieves two conflicting objectives at the same time.
The clue to finding a solution can be found in learning from successful companies.
However, if you think of bringing the development process of successful companies as it is, you will fail.
This is because there are differences between your company and successful companies in various situations.
Rather than focusing on the process itself that successful companies have created, we should create our own worldview by referring to what they have won and how they have won it, and set it as a goal to be achieved.
The development process, organizational capabilities, and individual capabilities are all things that can be gradually changed together.
The goal to be reached can be reached step by step, accumulating small achievements.
Having doubts about the company’s product development process, I decided to publish a book with a fictional story of how I created a reform plan with young developers to change the company and get the top management to accept it. (Although it is fictional, it includes a great deal of the author’s actual experience.)
If you are a manager or an engineer in a product development department and have any doubts about the current development process or organization, please refer to this book.
Please refer to the way the company creates its own new worldview and reduces it to a feasible plan while utilizing Lean Product Development, Job Theory, and TOC (Theory of Constraints).
Reference： Introduction article of this book
If you liked this article, please click the “Like” button below!!