Most business leaders I speak to crave additional bang-for-the-buck when investing in new product development; it is arguably one of the keys to superior growth. The idea that additional value can be created in shorter timeframes with fewer resources is not a new one—it has been the pursuit of lean transformation for many decades. However, practical frameworks to achieve improvement have focused more on transactional areas like manufacturing or supply chain management and have been far less common in complex business areas like product development.

A company that offers insight into one such way of approaching product development is Toyota, which is not surprising as the foundation of lean product development originates in the Toyota Product Development System.

For many decades, Jeff Liker has been at the forefront of the lean movement and particularly lean product development. In addition to being a consultant and author, Jeff is currently Professor of Industrial and Operations Engineering at the University of Michigan. Professor Liker is well known for the seminal text The Toyota Way and The Toyota Product Development System, co-authored with James Morgan. Professor Liker’s articles and books have won nine Shingo Prizes for Research Excellence, with The Toyota Way winning the 2005 Institute of Industrial Engineers Book of the Year Award and the 2007 Sloan Industry Studies Book of the Year.

Given my own interest in the intersection of lean product development and growth, I am very pleased to be catching up with Jeff today as part of Invetech’s series on growth.

Colin: Jeff, good morning, thank you for your time, it is great to catch-up again.

Jeff: Good morning, thanks for inviting me.

Colin: It’s our pleasure. Jeff, I thought I might start off by asking you about nomenclature. The term “lean” is widely used these days and perhaps not always with the original intent of James Womack, the pioneer of lean production methodology in the U.S. What is the best way to think about “lean” in the context of product development?

Jeff: The term “lean” was introduced in The Machine that changed the World by Womack, Jones and Roos. They needed a brand name for what they saw as a vast difference between the Japanese automakers in the early 70’s and 80’s and the American and European car companies. It wasn’t just a small difference; it was a difference of one, two, 10 times better in Japan. Everything from engineering hours devoted to developing a car, to the lead-time, to the quality of the parts, to the space that it took to make those parts, to the amount of inventory that was held. So the idea of lean was doing more with less while also creating better quality and what the customer wanted. It’s the right part, at the right time, at the right amount. The right part being what the customer wants.

We are providing a better product, which is what the customer really wants, when they want it, in the amount they want. You can go through all value streams of all the different steps of product development and ask, “What does the next customer want? When are they ready? How can I give them a small batch instead of overwhelming them? Can I give them just what they need, when they need it, for one part?”

That basic concept applies as well to product development as it does to manufacturing. It’s what any engineer who is doing excellent work should be doing. No one wants to be overwhelmed with information at one time, because then they have to sift through all that information to pick out what they want. It’s very likely that they won’t check everything that is given to them because they are not going to use it for a while. So you end up with defects. Defective information, based on wrong assumptions, passing down through the value stream.

What engineers want is everything to happen when it’s supposed to happen. They want really good thinking, really good analysis, a good understanding of the customer. They also want the work to flow, and the customer wants the product now. So if you’re designing the product for them, the design has to be done as quickly as possible as companies don’t want to spend more money than they have to.

A company that simply looks at lean product development as “faster and at less cost” will really miss the boat because a company is only as good as its products. All you have to offer are the products that you sell to your customers. So if your products are not as good as your competitors’—or are not vastly superior to your competitors—you won’t be excellent or high-performing.

Colin: Jeff, I think you make an excellent point there—the idea that it’s about excellence rather than about cost-cutting or beating up on engineers to get products to market faster is a very good one. In some of your publications, you take this a little further and say that this area of product development is described as an organization’s next competitive frontier. What do you mean by that?

Jeff: Again, The Machine that changed the World was really describing the whole enterprise and what it means to do excellent work with fewer resources. What ends up happening is that big companies were imitating Toyota’s most visible part, which is manufacturing. Toyota gives tours freely of their manufacturing plants and particularly assembly. Therefore, you are seeing a highly repetitive process: it may take one minute per cycle and then it repeats, and they are trying to get the waste out by the second, and you can physically move things around. So that’s where most companies started.

At first, if you were the only company doing that, and you could reduce your inventory and costs per unit and give your customers much better lead time than your competitors, which gave you a competitive edge. But it didn’t take that long for your competitors to get it, and they may do things that you may not do. For example: perhaps they have set up shop in a low-cost country, they have a big warehouse and are building and shipping just-in-time. From the customer’s point of view, they will offer the same lead times and price as you, so now you’ve lost your competitive advantage.

The next competitive frontier is that you offer a product that is clearly superior to your customers. It solves your customer’s problems better, so they are willing to pay even extra for your product. If you patent that and own the intellectual property, then you just cut out your competitor. That happens in pharmaceuticals and high-tech businesses regularly. The real opportunity is to understand the customer and ask, “What are the problems the customer has that I can solve?”

We work with Caterpillar, and in their case, Caterpillar equipment is the productivity tool of their customer. They can make their customers more productive if the equipment is easier to use, if it will pull more tons than their competitors, if it is lighter weight and uses less fuel, and also if they can provide excellent service. Caterpillar has twenty-four-seven service and if your equipment goes down, they’ve got someone out there almost immediately to fix it—that’s part of their competitive edge.

You have to look not just internally at how to reduce costs so as to increase profit, but also at how to increase the customer’s positive experience. You want your customers to say: “My Danaher product is so much better, I can rely on it, it doesn’t break down. But if it does break down, it gets fixed. It provides features that are so easy to use, I can take it out of the box and use it, I am willing to pay extra for that and I don’t even want to consider using another product.” That’s the situation you’d like to find yourself in.

Colin: Absolutely, I think you’ve made an excellent point that all a business really has to represent itself is its products, and therefore making those as customer-centric and as value-adding as possible is part of the edge that comes in business. Given that the business leverage can be found in the products that are developed and launched, you would expect more management attention directed towards trying to implement an excellent framework in product development.

From your perspective and from your research, what are the main benefits of implementing this type of do more with less approach? Is it seen mainly in time to market? Or is it more in the quality of the product? Or is it a product that better fits with market needs? Or is it something else entirely?

Jeff: Well, it’s all those things. We worked with a division of Caterpillar called Solar Turbines, which makes gas-to-electric turbines for use in power generation. They use complex combustion systems and their PHDs in combustion engineering are the elite of the company. When we first started working with them, they had all these chimneys of experts and departments. Purchasing was mainly interested in low-cost piece prices, and the combustion engineers were doing their thing, and they were kind of worshipped for their brilliance.

The manufacturing people were trying to put these things together and then install them in the field; the prototype people were trying to build prototypes; and all these chimneys were doing what they considered to be excellent work. But work was not flowing across the different departments. Every department had its complaints, which were mainly about other departments.

One of the consequences of that situation was long lead times—they never met any of their business objectives. The first time they used a lean system, both projects came in on time and on budget, with great quality. They met every one of their targets and couldn’t remember when they had ever done that before. So it’s really everything. From the point of view of an operational excellence project, you don’t really care what the target is. Whatever it is, you can hit it if you do this right.

Colin: Given the potential upside as you’ve seen through the implementation at Solar Turbines, why do you think it is that organizations struggle to make progress with lean transformation in product development? You know, what is it that holds them back?

Jeff: That’s a good question, one I’ve asked a lot because it seems so obvious to me and once companies do it, it seems obvious to them.

I think there are a number or reasons. One is that it’s less clear in product development as to what to do. You have a bunch of people who sit around offices and have meetings and draw things. You don’t even know what they are doing. Whereas in manufacturing, it’s very obvious and you can see physically what the person is doing. You can physically move things around. You can see the space free up very quickly. You can see the consequences of your actions very quickly, and often it means fewer people, so that’s a cost that comes off the books that’s very easy to account for.

A second thing: there is, frankly, a certain type of arrogance. Engineers think they can learn anything by reading a book. In fact, the lean concept tools are quite simple. One of the tools we used for Solar Turbine was value-stream mapping. It was sticky notes, rough estimates of time; very unscientific from an engineering point of view.

They had already being trying to do lean themselves, and they were trying to do a computer simulation of the engineering process. They spent about a year doing it and hadn’t implemented anything. Then we come in with sticky notes, get people together and in three days have a plan. That looks really fluffy and non-scientific to these engineers and then once they see it, they say, “Well this is easy, this is like kindergarten stuff, not PHD level”. But what they don’t understand is the skill required to facilitate, to get people together, to get them engaged, to keep the process moving.

Another key concept is Obeya (Information Centre), where they meet at least every week—even more frequently is better, asking “How did each function do? What do I need from another function?” The plan keeps changing week by week, so in three months this plan will be out of date. That drives engineers nuts. “Why are we spending all this time developing a plan that is going to be out of date in three months?” The purpose is to get them to just talk to each other. Understand how much waste is created because they don’t communicate, they don’t coordinate, they don’t release small batches, and they don’t get feedback quickly. And then come up with a vision that they all agree on to get started moving forward.

In working with Solar Turbine, I’d start by giving the introductory speeches and they listened, but I could tell they weren’t excited. By the end of that three-day value-stream-mapping workshop, they were just on fire, they were so excited. You have to get them started and they have to experience it and then look back and say, wow, that was different from what we normally do. But trying to intellectually explain it to them is pretty tough.

Another issue: if the VP of Engineering doesn’t actually participate, you’re still in a position of trying to convince that person intellectually or show them the results. In the case of Solar Turbine, the VP of Engineering came to the room, and he could see their excitement and enthusiasm, so everything they asked for he agreed to on the spot. These were things they had been asking about for years.

So while that scenario worked out, we often have difficulties getting the senior leaders to even come and see, let alone participate. Therefore they are trying to understand this intellectually, as opposed to experiencing the process where they actually understand that this is game-changing.

You do need somebody who actually has been through it and has the vision and the experiences and skills to lead the early stages. Some companies don’t like to hire consultants, but they will hire only when the cost and benefit analysis is very clear. “In the first year, we will save five times what we spend.” That’s very clear, you’ve documented it. But then with lean product development, your products will be better, your customers will be satisfied, you’ll meet your cost targets two years from now. It’s not a clear business proposition. So there’s more taking it on faith.

Typically, when we work for a company that has many plants, they might engage us for one lean consultant in each plant for two weeks per month for the first year. Then we go into product development where they have 3,000 engineers, and they ask us to do five workshops for the whole organization. The level of investment is a fraction of what it is for health, for teaching, compared to what we see in manufacturing in most companies.

Colin: What you say resonates very strongly with me, that the success and effectiveness of any implementation of lean product development is a function of the leadership and the mindset that they bring to the task. As you say, it’s sometimes tricky to show the ROI in a spreadsheet, or the timeframe of it may be beyond what people would like, but with the correct mindset and experience of having seen it work elsewhere, normally people get on their way.

When you studied Toyota, that’s an organization at the other end of the spectrum. Toyota has invested significant time in maturing their approach and certainly believes in it. What’s your sense of the motivation within Toyota for the investment, and why is it they are able to generate results over decades when many struggle? Do they have some kind of secret sauce here? Or is it something else?

Jeff: The mindset really is number one: long-term thinking. What happens this month, this quarter, is almost irrelevant as long as we are making progress toward how we will be 20, 30 years out. They are very strategic thinkers. I just came out with a new book called Developing Lean Leaders at all Levels. In it, I use the example of the Scion; it’s a new car for young people. They had a lot of success early on, and then their sales went down a lot and they were criticized as being an unsuccessful product line. When Toyota started the Scion line, they had a very strategic purpose: to bring young people into the market.

They had great success: about 80 percent of people who came in were young and did not own a Toyota. The idea is that once they own it, they are more than likely to retain that customer. Toyota is thinking about what that person buying a Toyota or a Lexus will be saying 20 years from now to their friends and children.

So, profitability of the brand is not the main point. The main point is the average age and whether they already own Toyotas or not. The more they sell, the more they can impact young people. But if they have a few bad years because they decided to invest in development for other products, that’s fine. It doesn’t have to be year on year, justifying itself. Not that many companies are long-term thinking like that. They might judge that same product and say it has been three or four years and we’ve been losing money, why don’t we dump this product. Or we need to do something to revitalize this product now. They would get very anxious and there would be a lot of pressure.

Whereas Toyota is quite relaxed about it, because they know the placement of that product. They know the strategy. They know the purpose and they prioritize what they are going to spend more time on. That long-term thinking happens to be supported by the overall infrastructure of the company, which still is run in Japan, and still led today by a Toyota family member who has love for the company. He has a long-term vision and is pretty much immune personally to Wall Street and to pressure from stock-holders. He can ignore them and decide to do whatever he wants to do. There is no external board of directors to fire. So that helps a lot.

On the other hand, I started this new book on developing new leaders, talking about Jim Collins’ work on great companies. His companies are all American companies. A common denominator for great companies that stand out is that the CEO and senior leaders have a love for the company, a passion for the company and a passion for the customers. They care not just about profits but they care about the company as an entity in itself, like the way they would care about a child or about a great piece of art. They want the company to survive them. So it’s just not simply Toyota, it’s really any great company. In these great companies, the leaders have a passion and they care, so they make the short-term investment needed to be great for the long-term.

Colin: Yes, certainly it’s a great inspiration and you mentioned Jim Collins’ work, which I enjoy also. For us all to be taking that longer-term perspective to bring that right mindset to the business that we are trying to nurture.

In the study of Toyota, again, a great company, you and James Morgan distilled down your observations to thirteen key principles across three areas: process, skilled people, and tools and technology.  The first principle I wanted to pick up on, and this is from the process area – is to establish customer-defined value to separate value-added from waste. Can you provide a thumbnail sketch of how Toyota separates customer-defined value from waste?

Jeff: Well, first of all, we wanted to emphasize that it starts with the customer. Then we wanted to emphasize that the lean concept of waste, which is anything that is not value added, depends completely on defining what is value added and value added can only be defined from the customers’ point of view.  If you don’t really understand your customer, you have no way of prioritizing what is value-added and what is waste.  One thing that really helps in Toyota is the chief engineer system, which we talk about in the book. By chief engineer, I mean the Chief Engineer at Toyota has a vision for the product. He actually has to understand what the customer wants and leads the overall architectural systems engineering and also delivery for timing, for profitability, for every aspect of the program. If the car is profitable, if it works well, without defects caused by design, the Chief Engineer is successful and Toyota will say, “It’s the Chief Engineer’s car.”

Now that puts sales and marketing in an interesting position, because in most companies that I know of, you find out what the customer requirements are by talking to sales and marketing. They will then give you the requirements; if you’re a program manager, you have to satisfy sales and marketing requirements. In Toyota’s case, the Chief Engineer is the customer of sales and marketing. In order for sales and marketing to be successful, they have to educate the Chief Engineer, and the Chief Engineer has a lot of power, so he decides what he wants to be educated on. He will either listen to them…or not.

At Toyota, if sales and marketing give the Chief Engineer a bunch of data that he thinks is irrelevant, he will just ignore it. He might say, “Let’s just go and see—line me up with a 100 customers in 50 different states and I want to talk to them.” Or, “I want to go to the dealers, I want to talk to the dealers, or I want to talk to the repair people to see what problems they have with the cars.” He gets a holistic understanding of the product: how’s it going to be used, what the customer base is like.

Then the Chief Engineer will usually summarize that in some simple diagrams and perhaps trade-off curves (e.g., trade-offs in the customers’ minds between styling and cost and fuel economy, etc.). Then once he has that, he issues a Chief Engineer concept paper that says, “Here is what this car needs to look like, here’s what it needs to do for the customer, here’s the cost target, here’s the timing.”

Now when he’s leading the project, he’s running around all over the place talking to suppliers, to purchasing, to product development engineers. Any difficult decision, any trade-off that they can’t make, the Chief Engineer can make on the spot. And he can also go into a meeting and ask, “Why are you working on this, it’s not a priority for the customer.” He translates what he sees, his vision of the customer, into technical requirements very clearly, very easily. The brake engineer knows that this is what the Chief Engineer expects of the breaking system. Once those requirements are known, then they are posted in the Obeya. Every meeting will start out with customer’s requirements: “Let’s remind ourselves what is it that we are trying to do, what is it that the customer wants.” That gives you a means during that meeting to say, “Wait a second, are we spending our time on the right thing?”

Colin: Yes, I think the process that you described here ties in very well with the second principle I would like to discuss, which is to front-load the product development process to explore thoroughly alternative solutions while there is maximum design space. You talked of the vision of the Chief Engineer meeting customers and understanding what it is that they are looking for. Then spending the right amount of time to figure out how to achieve it.

This one resonates very strongly with my own experiences that the chances of creating a winning product are significantly higher if the homework is done upfront both from the customers’ side (the market side and the commercial side) and also on the technology side—the architecture that the product might have and so forth. From your perspective, why should organizations embrace this principle and this way of working?

Jeff: Well, if you think about a raft of cost commitments (how many dollars are committed to cover equipment, to tooling, to the number of people you are going to have), what you see is that cost commitments increase exponentially as you get closer to the launch of the product. But when you look at the decisions made that influence those cost commitments, it’s like a reverse exponential. The initial concept and decisions that you make at the very beginning—e.g., what materials are we going to use, what the architecture of the product will be—influence 90 percent of the costs.

So at the beginning of a project, you have a pretty small investment—you haven’t spent money on capital equipment and on tooling. You usually have a small number of your more senior engineers or senior people from different perspectives. Then as you get more and more engineers involved, and they are detailing the design, and you are buying things and working with vendors, that’s when the costs really start to mount. You’re constrained by how good a job the early engineers did, for example, selecting the right materials might reduce your weight in half or it might reduce the cost of that material by 30%. Once that material is selected, there is nothing anyone can do but use that material.

You have an opportunity in the early stages to get a lot of input from a lot of different people, so that you avoid so many downstream costs and problems. As an example, in the front-end stage Toyota, in product development in automotive, you have a styling stage. And you have these artists who are drawing, then making clay models, then those get passed on to engineers who then turn them into databases for building all the parts of a car body. In that clay model stage, there are a lot of decisions (how the car is going to look, which will then influence things like your ability to stamp out the car parts).

Toyota has hourly workers in manufacturing plants—stamping, welding, assembly, paint—whom they pull out of production and put on a pilot team for usually about two years. They will send these hourly people to wherever the styling is being done. They will say, “If you change this, you can make one piece instead of two pieces; if you change this, you can more easily stamp this without defects.” They will have a lot of feedback and then the artist will say, “Yeah, we can change that, and it will still look exactly the same but it will be easier for you guys.” Toyota is engineering very early when it’s just a concept, and they are willing to ship people around the world and even involve hourly employees who usually you don’t think about sending overseas. They make that investment because they know that the payoff is so great.

In addition to that, the engineers do a lot of experimentation. In experimental time, creating representations that are visual or even physical really helps. So one of the things that Toyota got really good at was solid modelling, and then virtual design, and even virtual assembly, so that you can see a person virtually assembling the vehicle and have the assembly people there pointing and critiquing, saying, “If you change this we could assembly it easily and then skip a few steps.” They also will take older vehicles of their last model and they might put a seat into it, so you can sit on the seat and you can feel what it feels like. They do a lot of rapid prototyping, cheap and quick so that you can physically see the product or physically put parts together—which is helpful in that early stage implementation.

The other key skill that is required of all their engineers is that they all have to learn how to physically sketch. Toyota really believes that there is a value to hand-sketching and that the mind-body connection goes beyond what you can do on a computer. So they teach classes, and you have to take the classes every week, until you pass one by one. That’s a lost art in engineering, the ability to sketch in order to communicate with others. It’s so powerful to see something visual compared to someone trying to describe it verbally.

Colin: Certainly one of the things that came out of your insights in the book was again around this perspective of developing towering technical competence in all engineers. Towering technical competence is a very high standard—how do Toyota and others approach the development and the maintenance of that?

Jeff: Well, for Toyota, there are a number of things that they do. For one, most engineers that develop products and processes are in Japan still.  They have a significant number of engineers in Ann Arbor, Michigan. In the Japan case, every year in April, they select the class from school—they’re all wearing the same outfits, they come on buses and are given a basic orientation of the company for a few months.

Then they are assigned to either go out to a dealer or into a manufacturing plant for three months. If they go to a dealer, they become a salesman and actually knock door to door, trying to sell cars. If they go to a plant, they are a production worker and they work on line. They are just trying to give them the most visual experience possible of, on the one hand, the customer; and on the other hand, what it’s like to put this together. Any engineer in Toyota that I’ve talked to, even if they were hired 30 years ago, remembers those experiences. And they remember how hard it is to sell these cars, and how much easier it is if the car is really good and they have something to sell. And how hard it is to put together and the frustration they had.

In the first year they are learning general stuff, then they assign them to a department. Toyota wants their engineers to be able to do their own computer designs so they can think of an idea and put it in a computer instead of finding somebody to do it for them. Toyota finds there is so much waste in that process of separating computer engineering from the design process. They spend time doing this, and then they get their first “freshman” project—a significant design challenge for a real product. They have a mentor, they struggle, and this could take three or four months.

In the third year, they are assigned to a vehicle program—to one particular part of the vehicle. It might be a new bumper and that’s all they are responsible for. They are working with a senior bumper engineer, and they will go through the whole product development process of what happens from concept, to prototyping, to manufacturing. They will do that once, and that might take them a year and a half or two years. Now they’re into four years, and they have designed one part of a car, once, one time.

Toyota’s standard is now they have to do it twice. They then do it a second time, which takes them another couple of years. Now that’s six years, and then Toyota says, now you’re an engineer. For six years you were a novice, and you were in training and now you are an engineer and we can expect something from you. For most American companies, that individual might be on their third job by now, their third company. At Toyota, they’re just now an engineer who can produce something after six years. So that kind of gives you an illustration of the commitment that is made.

The other part of it is that some people, some engineers just love the craft that they are taught. They love being an engineer. They don’t have a desire to manage other people. In fact, it’s a nuisance to them, it wastes their time because what they want to do is to design things. They want to keep learning technical things.

Toyota essentially has a technical track, they never called it a duel track, but they recognize the value of people with their own technical competence. They will decide, based on the individual and their talent over time, what their next assignment is going to be. That next assignment may not involve managing large groups of people for person A, but for person B they might pretty quickly get some supervisory responsibility and move up the ladder. But the technical person who just loves plastics, loves anything made of plastic, studies polymer chemistry and becomes an expert, will be highly valued and can make almost as much money as someone who becomes a general manager.

Those people are keepers of their book of knowledge. They used to be called engineering checklists, because they are going to know everything possible about, say, a bumper, and that knowledge checklist will be put into a set of standards in a database. There will be a super engineer who will decide what’s in that database, what’s not in that database, and also will review each of the designs of the bumper say for each car and essentially has veto power. A Toyota super engineer can just look at a bumper and say, “Look, this just isn’t going to work, it’s not going to meet our crash tests,” almost instantly. The engineers that I talked to say they were sweating bullets when they have to stand in front of people and explain their designs—because you can’t hide from anything.

Colin: Absolutely, and that resonates with me from my own observation as well. That the technically people really are the lifeblood of new product development, and you have to provide a career path and have them as high standing alongside the people managers and the commercial leaders.

Jeff: They often get ignored, or passed over. They are the loser that didn’t get promoted.

Colin: Right, “Ignore them at your peril” is what comes to mind.

As a final question: for those who are inspired to pick up the momentum in their lean product development journey, what would be your advice about where they should put their efforts to gain the most leverage?

Jeff: You have to actually have to do it and experience the benefits. You can do it tool by tool, and you can say, “We are going to invest in rapid prototyping, so let’s bring in the tools for that, and we are going to do frontend loading,” but it’s really everything together. It’s a system that makes it all work. So when Solar Turbines did those two projects, they were kind of revolutionary for them and it was really a turning point for the company.

Then after that, they did decide that all new projects were going to go through a similar process: they would do value-stream mapping up front, they would build a team, they would meet weekly in Obeya, they would use visual management. The original people who were involved in those first pilots ended up becoming the internal experts who continued to be teachers and continued to evolve the process.

I usually recommend that you start with actual projects and you put a lot of time and attention into learning, into starting to develop a skill base, and then you start to spread to additional programs. Then you begin to look at the infrastructure: how we create a new database, how we create a system for towering technical competence. Start with the core. I think about the core as the product development team, the cross-functional team that’s doing a project. Then you move out to the supporting functions and start to develop those. What I know doesn’t work is blanketing the organization by trying to change everything all at once. It’s a losing proposition. Everything will be done superficially and poorly.

Colin:  Jeff, thank you on behalf of all who have benefited from your thought leadership on the lean enterprise in general and lean product development in particular. I know I certainly have. I regularly refer colleagues to your work. It has been a true pleasure to talk to you today and I’m excited to hear that you’ve got a new book coming out on lean leadership and I look forward to reading that.

Jeff: Thanks, and I appreciate it as well. I hope it works out and I’ve enjoyed working with Danaher.