Dear Gemba Coach,
What would be a knowledge-based approach to product development?
Well, to a large extent all product development activities are knowledge-based, one way or the other. How could it be otherwise? But I think I understand your question. These past years, most development departments have been focused on a “standardized process” approach to improve development flow that imposes a standard development workflow on engineers. This treats every engineer as a black box that comes in with its knowledge stock and finds his or her place in the chain. Not surprisingly, after early apparent gains as you “streamline” the process, this way of thinking generates a constant stream of mediocre products that don’t cut it with customers.
The only way to improve engineering productivity is to find a magic recipe for engineers to find the better solution (both for customers, for production, and for total cost) quicker. Organizing them better might help, but not as much as worrying daily about what we know and what we don’t know, as well as what we should know but no longer apply in our daily engineering problem solving, so yes: knowledge based.
4 Keys to a Knowledge-Based Approach
Historically, a few lean companies have explored the engineering issue in depth and we have some idea of where to look for new ways of working. This, however, requires us as lean guys to look up and relinquish (for a moment, all I ask) our obsession with flow to think more deeply about value. A knowledge-based approach to product development has four key aspects:
- Understand the product evolution dimensions according to where the market is going led by customer preferences.
- Progress step-by-step, one change at a time by searching for new knowledge based on existing knowledge (with A3s)
- Keep engineering decisions grounded in practicalities and constantly encourage collaboration across functional barriers with VA/VE
- Think deeply about what you know in a variety of situations with set-based concurrent engineering.
Probably the most critical aspect of product design is to share with the entire engineering team what the product should be like. How can we do this when we’re precisely designing a new product? Specifications don’t help much because they mainly describe in minute detail the minimum requirement for various functionalities. Specifications do not provide a global understanding of the product and why it should engage customers and attract fans.
In most markets, products evolve in a certain direction in response to customers trying to solve their specific problems with products. This evolution is not always easy to figure out. For instance, mobile phones decreased in size and width until, years ago, I had the perfect phone (for me) that did nothing else but phone and fit in the palm of my hand, but as smartphones appeared and as video is now dominating the medium, phones have started increasing in size to better accommodate streaming.
I was on the gemba at the beginning of the week with a CEO looking at inspection machines. There are hundreds of requirements to fulfill customer expectations, but when we looked at the evolution of competitors’’ machines, we could see that machines evolved towards (1) faster speeds (to deal with batches faster and ultimately the hope to slave the testing machine to the production line), (2) greater flexibility (to be able to test a wider range of products), and (3) footprint and ease of handling.
This tells us that new products can be visualized as (1) doing what they already do more consistently and with greater robustness and (2) stepping forward towards either greater speed, added flexibility or smaller, easier machines. Any engineer on the project can understand this, and then consider by themselves whether the spot solutions they bring to daily engineering problems help us move forward or backwards.
80 + Alpha Rule
A deep difficulty to knowledge-based approaches is that not all knowledge has the same impact. Savants, for instance, can know the phone book and still not be able to solve simple common sense problems. Knowledge must be directed in order to be useful. Certainly, many insights are born out of making connections from seeing something outside of one’s narrow field, but this greater mental scape doesn’t require the same detailed level of knowledge. Learning is very energy consuming and wasteful, particularly in teams, without an agreement on what we’re trying to learn.
Once the direction of learning has been clarified and we know which way we want to move the existing product, we must be careful to do this in a knowledgeable way and not by rash moves driven by wishful thinking. The lean way to think about this is the “80 + alpha” Toyota doctrine. Can you describe your future product as:
- The list of performances that must get a grade of 80% at the minimum, based on existing features.
- The “plus alpha” performance achieved by a few new features.
There are two knowledge issues here – do we know what we know better or do we discover new stuff. In practical terms this means distinguishing two types of problem solving:
- Quality improvement: Using the existing components but finding ways to make them work better, longer, and more consistently.
- Performance improvement: Finding a new component that radically improves performance (but not necessarily quality)
These two analyses will be very different and lead to different kinds of learning, which is why rigorous A3s presented by engineers are essential.
One of the best descriptions of what an engineering A3 should be that I’ve read can be found in Kimio Inagaki and Toshiko Narusawa’s Essential Thinking for Product Development which describes thoroughly the right level of analysis for an A3 to be of any use. The A3 should help the reader see quickly what is already known and where is the jump towards new knowledge (and how certain of this new knowledge we are). Progress along the evolution dimensions can be seen as moving step by step, one A3 at a time.
A recurring myth in product development is that of the daring leap, mostly against the deep opposition of hidebound conservative colleagues – it made great Hollywood scripts. Certainly, any innovator faces pushback from conservative colleagues, but the daring leap is rarely that daring. Precisely because innovators face opposition, they have usually considered and tested their new ideas for a very long time before they try to get them accepted in a market-ready new product.
New ideas need to remain grounded. Being grounded in development and production practices doesn’t stifle creativity – on the contrary, it nourishes it.
Roles for VA and VE
A key part to teaching engineers to be better engineers is to constantly involve them in Value Analysis and Value Engineering activities:
- Value Analysis: Solving engineering problems with products currently in production, which means supporting production in solving their problems from an engineering point of view.
- Value engineering: Improving future products at the design stage by solving recurring production problems, which means involving production in new engineering designs.
VA and VE activities are essential to create space for enquiry and intense collaboration across functions, especially between production and engineering. Great products are the result of co-evolution of engineering and manufacturing techniques that somehow mesh together.
Last but not least, a further difficulty but essential safety feature is to not let engineers dive into one solution – ever – at the risk of long delays. Quite naturally, engineers will be irrationally optimistic about their new idea: “It’ll work.” This is fine for Han Solo, as the scriptwriters control his fate. In real life, everything that can possibly happen will happen sooner or later and new ideas are usually good, but will hit unexpected snags.
This is why working with alternatives opens the mind to really understanding what goes on. Truly knowing something is not knowing it in one narrow set of lab conditions, but knowing it in a wide variety of settings: knowledge is contextual. This sort of deep knowledge requires the twin discipline of:
- Thinking in sets: Never try one thing, but at least three potentially equally valid ideas;
- Trade-off curves: Think in terms of space of possibles rather than point optimization. Lab results tend to be peak performance, real life is average performance.
The lean literature talks about reusable knowledge. Recent research we’re conducting with Dan Jones, Jacques Chaize, and Orry Fiume leads us to believe we should be thinking in terms of reusable learning: rather than standardize the best practice, standardize the learning path to discover the best practice in specific circumstances. To specifically answer your question, I’d start looking at the four key elements of (1) clarifying how the product should evolve in its market, (2) step-by-step progress based on moving from existing knowledge to new knowledge with deep thinking A3s, (3) constant VA/VE activities to keep the thinking grounded and intensify collaboration and (4) the discipline of thinking in sets and spaces rather than narrow down too quickly on hopeful solutions. True learning is its own reward – but rarely easy!
