Be among the first to get the latest insights from LEI’s Lean Product and Process Development (LPPD) thought leaders and practitioners. Subscribers to The Design Brief, LEI’s newsletter devoted to improving organizations’ innovation capability.
In the 90s, I was heavily involved in research on Toyota’s product development approach, while most others were investigating lean manufacturing. As a part of that research program, I partnered with Alan Ward, a young professor of mechanical engineering at the University of Michigan. Al had an intriguing — and a bit abstract — idea he called “set-based non-recursive design.” He had worked in developing products and then got a PhD at the Massachusetts Institute of Technology, focusing on his pet peeve: Most companies seemed to leap into a particular design solution before considering alternatives. He called this approach “point-based design.” Once a company’s designers committed to a small part of the solution space, they got stuck.
They were committed to that solution and then spent their effort on making it work. More often than not, there were limits to their initial idea, which would fail in many ways, so they iterated as they discovered the various problems. The problems were generally discovered over time, particularly as the drawings were passed on, in waterfall fashion, to the next function. The result was endless iteration fixing things until time ran out, and they launched what they had — often continuing iteration after the product was in the hands of customers.
The theory behind set-based design was — and is — that it is more effective to start by broadly considering a range of alternatives from multiple perspectives, which Jim Morgan and I called front-end loading. Over time as you test out the set of ideas, you converge toward the solution that is working out the best. The convergence of ideas happens in parallel across functions. This new theory presented a new, more effective way to develop products, processes, and services — an excellent idea, but would it work?
Putting Set-Based Design to the Test
Trying to address this question is the reason I got involved. Al was not sure how to test his ideas, and I was trained as a sociologist to conduct research studies testing hypotheses, so we partnered. At some point, we got the idea that Japanese companies might be more apt to use a set-based approach, so we compared U.S. and Japanese companies’ approaches to automotive development.
We conducted several interviews at American auto companies and some of their primary suppliers, and the verdict was clear. What they were doing was mainly point-based in waterfall fashion with a lot of iteration. In fact, most of the design effort was on fixing the design with relatively little time spent upfront exploring alternatives.
When we went to Japan, we were excited to finally find at Toyota — after a few disappointments — good examples of Al’s theory in practice. We visited Mazda, which mainly used point-based, and the set-based ideas did not seem to make sense to them. Ditto a few of their suppliers. Same story at Nissan. We might as well have been speaking Martian.
We were dejected by the time we traveled to Toyota in a hot, humid summer carrying our bags from the railroad station. But why not one more? In his usual energetic fashion, Al started to explain his theory to a general manager of Body Engineering who did not appear to understand well what he was saying. Finally, the GM stopped Al and said he was going to a conference to explain Toyota’s approach to development, and he could show us what he was going to say.
He started drawing on the board a perfect representation of Al’s set-based design process across functions, and the rest is history. We wrote about it in Sloan Management Review in 1997 in an article called “The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster.” The first paradox was just-in-time: With less inventory, you can go faster, better, at a lower cost with fewer parts shortages.
When Jim Morgan delved more deeply into this for his PhD dissertation focusing on Toyota’s automotive-body development, a few things became clear.
Design Must Start with a Customer-Driven Concept
Toyota does a lot of up-front planning for the portfolio of products they will work on, setting guidelines for price, cost, features, and customer base before launching a particular vehicle program. To start a program, the company names a Chief Engineer (discussed below), who is expected to form a team of some of the best and brightest engineers of critical functions.
In this stage, the broad guidelines and specific targets for cost and features are set, but the solution space is wide open. The chief engineer starts by gathering information from the customers, suppliers, and the engineering team, with the aim of writing a concept paper that will lay out his vision for the vehicle, its target market, and many key attributes — size, general look, target customers, features, competitive products, and more. The chief engineer then presents the concept paper to a large group representing essential functions and suppliers, officially launching the development process.
One Person Must Be the Chief Architect and Integrator
As Al and I presented the set-based design model at conferences and to individual companies, we found our audiences were most interested in learning more about Toyota’s Chief Engineer role. It seemed to us that most organizations’ program managers focused on cost, quality, timing, and features but cost and timing seemed to be their primary concerns — they were, first and foremost, project managers. Often, a separate, less powerful role, called something like “technical lead,” focused on the program’s engineering issues.
At Toyota, there is one person, the Chief Engineer, who treats the program as a start-up company. This person is the founder, visionary, chief architect, and key integrator from start to launch and sales. It is often said, “this is the chief engineer’s car.”
The starting point of development at Toyota is getting to understand customer needs, which can include living with customers like an anthropologist combined with the unique insights of the chief engineer — these special individuals who have been groomed intentionally for the role over several decades. As much as we believe in teams as the heart and soul of product development, the guiding brain is an individual — the chief engineer.
Study Drawings Enable Broad Exploration
The concept paper launches the “kentou” phase, which is a study period. During this time, the design team broadly explores the solution space from every perspective: customer, supplier, engineering functions, manufacturing. The key tool for Toyota is the study drawing, which most often are sketches, many of them hand drawn. Drawing on a computer adds complexity to the rendering process and tends to cause engineers to commit prematurely to a detailed design. Sketching is freer and, Toyota veterans believe, creates a superior mind-body connection. Sketching, sharing ideas, discussing, and then sketching some more allows for a broad exploration of the solution space before making commitments.
Technical Excellence is Paramount
In addition to being obsessive about listening to the customer, Toyota believes in deep functional expertise — specialist know-how. Most engineers specialize in a specific function, such as body or transmission engineering. If the Chief Engineer is the chief architect of the vehicle, the General Manager of a function is the chief developer of Engineers. The general manager is the master black belt who is responsible for providing to the chief engineer top-level engineers expert within that function.
Chief engineers rarely request specific people for their team; they expect that whoever the General Manager assigns will be excellent. In the kentou stage, only the best and most experienced explore and make critical decisions about overall vehicle specifications. As the program develops and people are added, they are mentored by these top-level experts. One of the senior experts’ skills is that they can predict the outcome of tests by looking at a drawing before completing the test. They have almost a second sense about their specialty — plastic, steel bodies, glass, and the like.
Once the concept is developed and the main target specifications for the vehicle are determined, the execution stage — the bulk of labor hours — focus on working out engineering details, running tests, building prototypes, preparing the factory, and generally refining the design. Refining a poorly conceived design is considered as just spinning wheels — a lot of waste. The most important intellectual work happens in the front end of set-based exploration.
Designing the Future
An Introduction to Lean Product and Process Development.
