For many years, Michael Kennedy has immersed himself in the study of Toyota’s style of product development. Tobias Fors met him at a seminar in Södertälje, Sweden, and followed up that first meeting with a back-and-forth on the topic of knowledge work and product development.
Mike, you’ve studied the way Toyota does product development for many years now. What roads took you there, and what is it that you find so fascinating about Toyota?
My role during my last few years at Texas Instruments was one of the product development process owners as we were reengineering our core processes. Our efforts had resulted in us winning the Malcolm Baldrige National Quality Award and probably the most benchmarked companies of that era – mid 1990’s. About that time, I met Dr. Allen Ward in a workshop sponsored by the National Center for Manufacturing Sciencesto explore different paradigms for product development. Allen presented the Toyota story. I was immediately mesmerized by their success and the amazing contrast to our practices. However, the primary thing is that it fundamentally seemed to resolve all the issues that we had just assumed to be the nature of product development – incessant design loopbacks, one off designs, missed schedules, and so on. For the next eight years until his unfortunate death, I worked with Allen to first understand and then, to this day, how to apply their paradigms outside the Toyota culture. In reality, the Toyota product development paradigm is like a complex jig saw puzzle; their practices are easy to see, but to understand how they fit in context with their overall system is truly fascinating. Then, making that system work in the Western manufacturing world takes the puzzle to another level. Every company we work with are helping us fill in all the pieces. This has been and will continue to be a great learning experience.
Speaking of puzzles: what have been your biggest challenges, so far, in trying to articulate and translate Toyota’s philosophy and practices to a Western context?
Actually, getting companies to see the power of the Toyota paradigm has been amazingly simple. That is why my first book registered with so many people as they saw the fictional IRT company as similar to their own and the contrast of logic to Toyota practices was evident. Unfortunately, recognizing the silliness of full scale designing a product before you truly know your customer interests and before you really know how to resolve known knowledge gaps is a lot easier to grasp, than actually changing it. In reality, the Western way of managing is still based on the principles of Scientific Management where the goals of management is control and compliance to rigorous processes. The Toyota paradigm is much different; it is based on ongoing learning, capturing the learning for wide reuse, and continually improving the knowledge across generations of products. To do this takes a lot of management understanding and commitment to guide the change. The good news: the engineering community will embrace the changes.
So, knowledge and learning seem like big parts of the secret sauce. About a hundred years ago the Wright brothers went head on with a hard product development challenge: building a working airplane. You’ve used their story to explain how to handle knowledge in development work. What made the approach used by the Wrights so unique?
The Wright Brothers made the observation that all their predecessors and their peers were spending about 5000 hours designing an aircraft and about 5 seconds testing it – which often killed them. Here is a quote from Wilbur. “We thought that if some method could be found by which it would be possible to practice by the hour instead of by the second there would be hope of advancing the solution of a very difficult problem…and without any serious danger.” They epitomize the shift in paradigm from “Design then test” to “Test then design” that we so often use to define the Toyota paradigm. The Wright Brothers didn’t start with detailed specs; they started by identifying their key knowledge gaps and developing brilliant experimentation techniques to solve them; once solved, then they designed the plane and flew it. To me, it is amazing that most companies today design their products first in order to find their problems and fix them with loopbacks. Toyota understands the lessons from the Wrights; most companies don’t.
Starting out by closing key knowledge gaps does not just mean “spend more time on requirements”, right? Can you elaborate on how your approach differs from the age-old adage to “get the spec right first”?
Great question that gets to the core of the problem. Generally, requirement specs are a smorgasbord of marketing wishes that may or not really address the real customer interests, and even if they do, they are buried in a long list that mask the critical ones from the trivial. The specs are also very specific which corner the engineering staff into making sub optimal decisions with no opportunity to explore alternatives or to match capabilities with the real customer interests. The Wright brother’s customer interests were pretty simple – take-off, fly, land, live to tell about it. The Toyota Prius customer interests were also simple – a midsize car with 50% better gas mileage. All the other details should emerge as you learn and optimize. Many companies, most actually, launch product development projects when they know they really don’t know the true customer interests and they really don’t know whether they can do it – now what is the logic to that? So, the goal is not to “get the specs right first”, but “to understand the true customer interests and whether you can do it first”.
So the purpose is to begin by understanding the true customer interests and whether you can create something that lives up to them?
Yes, exactly. More specifically, you really want to find the critical few customer interests early on, understand your knowledge gaps to do those, and resolve them before committing to the project and the schedule. Many companies have a portfolio planning process that precedes product development. Logically, this early learning should be going on there.
Given that we’ve managed to identify and close our major knowledge gaps: what is your advice when it comes to actually integrating the parts into a valuable whole?
I am not real certain of the intent of the question – the “valuable whole” could be the specific product being developed or could be the overall product development process. Let’s assume both. For a specific product development project, closing the major knowledge gaps allows a baseline concept to be defined that can be scheduled and actually be met with minimal loopbacks; then set-based design becomes the way for continued innovation against the set schedule. You can evaluate and develop multiple alternatives knowing that you have a safe viable solution in your back pocket – a very powerful approach for continuous innovation.
The other whole is the flow of knowledge for future products. Once you have solved the critical knowledge gaps for a specific project, that learning should be generalized for broad applicability, documented as to the limits of the solution, and established as knowledge standards thereby completing the PDCA cycle. The learning from resolving the critical knowledge gaps therefore has both enabled a successful product launch and has created knowledge available for future product launches.
Set-based design seems to be a key to enabling innovation here. What makes set-based design possible?
Fundamentally, set-based design is the ability to see the impact of alternative design decisions on customer’s interests so as to make informed tradeoffs. The key is having the knowledge to do so, usually in the form of generalized limit curves that show performance limits from multiple perspectives, and having flexible customer targets, not hard specs, to have the flexibility for optimization. Dr Allen Ward had referred to set-based design as “many innovations seeking limits”, the limits being what the customer wants, when he wants it, what you know how to do, and the business impact. The goals are to eliminate the weak alternatives to a firm schedule for a given product while continuously pushing the limits of performance for future products.
Software and hardware are different, but they are both big parts of product development today. What would be your advice to someone trying to make your ideas fit in a software context?
Actually, from the perspective of rapid cycles of early learning to meet customer interests, agile software techniques are ahead in their proven effectivity to meet schedules and customer expectations. In companies with software embedded with the hardware, I believe that there is little difference in set-based thinking between hardware and software decision making – optimize decisions based on the known performance limits while continually extending the limits. In pure software, since software is not limited by physics, I really don’t have a good feel how to formulate a set based strategy that innovates across generations of products and I am not sure whether this is well defined in the agile methodology.