The majority of companies I have encountered in my working and consulting life are organized by order, that is, they develop products against customer orders.
These customer orders are often characterized by a request for customized solutions, and a simplified Agile or Easy Agile management mode can be applied to them, as I was able to describe in my previous article “managing a custom order.“
All the companies organized by order that I have come across have a common issue, they face the challenge of developing new products, that is, suitable for multiple customers, within the paradigm of order management.
In other words, they identify an order, with generally longer lead times, within which to develop a new product, often in agreement with a selected customer. This approach involves the inclusion of products containing much innovation, and therefore with complexity, within a technical and production process normally equipped to handle the complicated world consisting of existing products containing customizations.
This condition that I have almost always encountered makes me think that it is a structural condition of small and medium-sized Italian companies and one that I have also found in large companies.
I think it is the child of many decades of investment in the efficiency of predominantly manufacturing business processes (Exploitation) accompanied by relatively little investment in product development processes (Exploration), beyond investment in CAD and product information management systems (PDM/PLM).
Whenever I get involved by companies to initiate an Agile transition in new product development, I am faced with this situation.
Only in very few cases is it possible to experiment with a process that is an alternative to order management and aimed at developing a new product according to the fundamentals of the Agile Factory. In these cases, the result that is always achieved is a major reduction in development time and thus a reduction in the cost of delay along with a growth in the skills of the people involved.
Planning thus leads to a real overlap of the typical phases of product development : Design, Construction, Assembly, Validation, and Industrialization that separate the initial Feasibility Analysis or Concept phase from the Series Production phase.
In this case being overlapping we could identify them by the level of product development and naming them “prevalent phases.”
The overlap of the prevailing phases can be depicted as follows:

In most situations, the shortest route to approach Agile new product development is to place it within the custom order management paradigm.
This is achieved by adding the Feasibility Analysis or Concept phase followed by a development approval gate or gate, inserting a validation phase identified by a start milestone and a validation closure milestone with a gate or gate function of “eventual” approval to release for mass production.
Planning could then take on this aspect:

The breakdown of the work, i.e., the backlog, can be done in a similar way as described in the article “managing a custom job order“, and its contents are represented in the gantt diagram with the Iterative and Incremental Development activity being the envelope of the set of development iterations.
All development activities that are not related to the production processes of Construction/Purchasing, Assembly and Testing are contained within the Iterative and Incremental Development activity.
They are managed iteratively and incrementally in a simplified Agile mode.
Within the backlog should obviously be included the typical macro topics of product development that are not taken into account in a custom customer order. Canvas, and validation activities in particular will have to be developed, since this is a new product.
In any case, a cross-functional team is needed, and the roles of Product Owner and Scrum Master may well fit into this more simplified mode of the Agile approach.
Working in this way, it is evident that all of the multiple perspectives of concurrent design ranging from, for example, environmental impact, cost, assemblyability, manufacturability, etc., are less easily achieved than the more comprehensive Agile approach that characterizes the Agile Factory. The results come very close, and this is a good way to go in the direction of full Agile development.
The classic construction and assembly phases by job order are only partially overlapped with that of design, and as a result the reduction in development time is less than in the integrated Agile Factory approach.