Sparring about your Lean issue?
Call René
Due to the product branch time as a perspective, we can better align technical decisions with market demands, leading to better design, manufacturing and material choices.
Why should customers choose your product over that of your competitors or over other ways to achieve the same results? How can you offer superior design, better customization, fast delivery, service and maintenance? And all at an affordable price? Lean Product and Process Development (LPPD) is probably the most influential aspect of Lean Thinking. After all, it is product development where we create value for the customer. These outcomes of the above questions are the result of thousands of technical decisions, both at the product feature level and in making the right manufacturing and material choices.
Product development is a flow of design information and technical, manufacturing and material decisions. Making these decisions on the basis of available design information is all the more difficult because a sum of features does not yet make a product, just as a sum of production decisions in terms of return on investment on one project does not guarantee a total return on assets for the company. There are cases, for example, where the counterintuitive choice to abandon large old factories for smaller, newer setups, as our 'Lean' friends in Ukraine are currently forced to do by the Russian invasion, improves one's return on assets. The same goes for material performance: switching from plastic to paper materials does not necessarily improve the footprint of the product.
Unfortunately, most companies miss the deeper understanding of LPPD because CEOs see Lean as a "production thing," one of many methods of improving operational efficiency rather than a complete business strategy (and because consultants tend to stick with what they know and sell production projects): production is the testing method for design decisions. The impact of any design decision will be seen first in production and with suppliers (can we make this safely, at quality and cost?) and then in the marketplace (will customers accept the product?).
What is worse is that because much of Lean manufacturing comes from outside Toyota (within Toyota, the emphasis has always been on designing and building ever better cars, ever since its founding, while GM and Ford cars were broken down and copied), LPPD tends to be interpreted as applying Lean manufacturing techniques to remove waste in engineering processes - which clearly makes little sense. Accelerating project lead times will not in itself produce a better product; on the contrary, it risks forcing engineers to make premature decisions that will affect the market performance of products. As engineers learn to estimate better, development lead times will become shorter with fewer errors and rework. But you can't make a car go faster by moving the speedometer needle on the dashboard. The goal of any LPPD activity should be to create the conditions for better engineering choices so that products become more attractive to customers.
In engineering, the two tough questions are: are we doing things right? (Following design guidelines, modeling the right calculations, controlling the impact of decisions, etc.), and are we doing things right? These are difficult questions to answer.
Without a crystal ball, how can we know if we are doing the right things and if we are doing things right? Creating a vision for future products is crucial in product development because it fundamentally challenges existing products. This is why it is difficult to choose the right design topics: should we focus entirely on solid-state batteries or should we work with existing batteries? Should we focus only on BEV (Battery Electric Vehicle) or should we continue to develop full hybrid offerings? Do customers really buy electric vehicles at their true price, or are they unduly influenced in their choices by government incentives and communications? How can we know?
There is no knowing, but we can get better odds on our guesses by narrowing the scope of our bets. We can start LPPD reasoning by looking at our entire product range, assuming that each product offering fits into a market niche, and then ask: what is the product branch time?
Instead of choosing to renew a product when sales have dropped catastrophically, we can learn a discipline of reviewing each product every six months, two years, four years to decide what to change and what to keep. What are the long-term investments in new resources (technology, materials, etc.) that the company is committed to, and when are we ready to make the switch?
By thinking this way, a Lean Chief Engineer starts with clear sales and profitability goals for a product innovation and answers in-depth questions about what customers are looking for now and what they still value and buy without mentioning it (things like quality, safety and durability are obvious to them). Thinking in terms of product branch time radically changes the way you look at engineering because it encourages you to look at a full value stream, not a single product release. This will have a huge impact on production costs because we can better choose which new processes to install and which existing processes can be used.
A product takt time is also key to making better use of marketing and model identity because marketers can more confidently answer the question "what does this product need to appeal to customers today?" rather than "what would be the perfect product for this niche tomorrow?" Product takt time helps calibrate all marketing and engineering questions and prevents deadly flights of fancy of impossible requirements and blue-sky thinking about features that customers will never really buy once they are told how much they cost.
Clearly, LPPD involves much more than product takt time. Years ago, we tried to capture the entire Lean product and process development system with Freddy Ballé:
But it's also easy to get lost in a check-off exercise and miss the overall point. By starting with lineup and product release takt time, you orient the minds of your engineers the right way and begin to think differently about how to allocate and develop your engineering resources (e.g., do you have the right people to develop the next generation of products?).
There are, of course, different kinds of branch times. As we have suggested, looking at regular product upgrades is a good place to start, but it is certainly not a good place to stop. As we gather new knowledge from these engineering activities, we need to use this knowledge to think ahead. What markets or segments are we not competing in? What will the next generation of customers value differently than current customers? How do we keep up with the zeitgeist with our product portfolio? And what regulations will we face in the future and how do we form new solutions in response?
To deal with these long-term challenges, we can also think in terms of takt-time. This is basically what Toyota does with its model innovations. It is also how Apple systematically implements new and improved technology in their product portfolio. Toyota, for example, has traditionally had several cycles in terms of product takt, coupled with the training of new chief engineers. Regular upgrades occur annually and are led by upcoming "junior level" CEs. Mid-level CEs handle the generational changes that usually occur every three to four years - product releases that usually involve larger changes in technology and value offerings of existing models. Finally, senior CEs are responsible for developing completely new models that often focus on new markets and new technology at the same time. Well-known examples are Hasegawa and the first Corolla, Uchiyamada and the first Prius, Suzuki and the first Lexus. However, there are other examples where Toyota developed new market niches with product launches: for example, the first model in the luxury crossover segment was the Lexus RX series, first developed by chief engineer Tsuneo Uchimoto. These types of releases usually occur at intervals of about eight to 10 years and require much more investment in all aspects of design and product development. Apple, on the other hand, has a smaller product portfolio that is continually updated in annual or biennial cycles. Sometimes only minor design changes are made, as new technologies are not implemented until they are completely ready (see the case of portrait mode in this HBR article), while other times major upgrades are made to the fundamental design or technology.
One of the main reasons these types of high-risk development projects fail (and both Apple and Toyota have had their share of failures) is probably the lack of accumulated knowledge in the engineering organization, both technical knowledge and knowledge about the market and customer preferences. Knowledge that can only be developed gradually as hypotheses are tested on the gemba, the real and messy world of customers and production. So start with product branch time and ask yourself what the natural cycles (short, medium, long term) of your markets and customers are and how to align the engineering organization with these cycles. As we have discussed in this article, the answer will be branch time.
Michael Ballé is Lean author, executive coach and co-founder of Institut Lean France.
Eivind Reke is Lean author and president of Los Norge
Yu-Hsiu Josh Hung is professor and director of the Center for Lean Product Development, National Cheng Kung University, Taiwan
Sign up for our newsletter
