“Do these things and you will be successful!”
Every business improvement related book or article is filled with solutions and usually, a prescriptive, step by step approach for fixing something. Back in the 1990s, as a chief engineer at GM, I became interested in improving our product development process. We needed higher quality launches, we needed to improve the time it took us to deliver the usable information that manufacturing needed to make the products, and we needed to lower the cost of development.
When I went looking for help, what I discovered was a list of many “best practices” to add to our existing processes. But what I have learned is that adopting someone else’s solution to your problem often creates more work, more problems, and more complexity.
This article takes a look at improving the product development process by using an approach called “Problem Solving for Complexity” rather than adopting one or more blanket solutions in the hope of a quick fix. This approach helps individuals and teams reduce lead-times by working on a few high leverage improvements and engaging people who do the work in running experiments around focused goals. People and teams learn how to use fast cycles of learning as a way of continuously improving the work. This creates alignment, helps teams produce more robust products and/or services, and reduces the time to market through reductions in delays and rework. Equally important, it creates a much more engaged workforce.
New Product Development: The Basics of Knowledge Creation
First, let’s remember that Product Development is a process for creating new knowledge that is packaged and delivered to manufacturing in usable form. Below is a figure that highlights the four critical aspects of creating knowledge in this context.
To do this well, let’s look at Russell Ackoff’s model “From Data to Wisdom.”
Working with data is just where most of us spend our time. How many times has your boss asked you to “get the data?” So, you gather the raw data, and put it into a spreadsheet so she can take a look at it. So far, the two of you have not moved up the Data to Wisdom pyramid at all. It will not be useful yet because it does not have meaning. To move up a level, you need to look at the data in the context of answering some basic questions. What does the data mean? What, when, where, and how many? Now your data has some meaning and can be considered information.
Next, you convert information to knowledge through answering some how questions. This is what is delivered from product development to manufacturing. Knowledge is conveyed by instructions that are useful for building a product on an ongoing basis. Delivering this new knowledge is the output of a strong and effective Product Development Value Stream.
Designing a product requires going up to the next level of understanding in order to create a deeper, more valuable form of knowledge. New understanding is needed to define the product so there are never any failures. Teams spend effort on understanding, getting answers to the why question. Answering this why is root cause problem solving focused on eliminating all failures. This step is cognitive and analytical and requires people to be engaged in continuous fast cycles of learning. This part of the process, developing understanding, is not transferred as an output to manufacturing, but instead needs to be captured and reused for other product developments. Most organizations struggle tremendously to do this once, let alone on an ongoing, consistent, basis.
Finally, Wisdom is about evaluating and making sense of understanding. Wisdom is critical because it is needed at the very first stage of new product development. Having wisdom is about being able to understand the true needs of the customer. Wisdom is typically about the future whereas the other steps (Data, Information, Knowledge, and Understanding), are about the past.
Wisdom is most evident in products that transform our current understanding of the customer (and the larger marketplace) such as Uber, the Apple iPhone, etc. These products or services change the way customers think and act. Improving flow just reduces lead-time; flow is used to improve the efficiency of the value stream. Effectiveness, on the other hand, is having the right product at the right time for the customer in the context of the marketplace. To achieve effectiveness takes Wisdom.
How does this relate to the product development? All five levels of Ackoff’s pyramid are required to have a high quality, high performance product development value stream.
Now, let’s direct our attention to the concept of organizational paradigms, which can tell us more about how we approach the knowledge creation process in the first place.
A History of New Product Development “Solutions”
Most leaders today work in a paradigm we might call “Imposing Blanket Solutions.” Someone (usually a leader or a consultant) has an idea about how to make improvements and rolls out expectations across the organization, assuming everyone will adopt and apply the new concept. Then, they measure each function, department, and/or individual for compliance. The alternative to this deeply embedded paradigm is to create the conditions for a new culture of problem solving to take place where people at all levels and functions, every day, work at making their work processes (and the larger system) better. Individuals work together, across functions, with a system problem solving approach that is ultimately focused on delivering value to the external customer while reducing lead-time (the time from start to finish of the process).
Let’s review how paradigms work. A paradigm is a generally accepted perspective which is based on some fundamental assumptions. It is the foundation for how people act on a daily basis, and it’s difficult to see. For example, doctors in the mid-1800s had competing paradigms after a few extraordinary people became aware of Germ Theory. This new paradigm was in conflict with the prevailing Humoral Theory which proclaimed that having four substances call “Humors” was the condition for a healthy human being. If someone became ill, the physician would administer bloodletting to rebalance the humors and cure the patient. The new paradigm, “Germ Theory”, completely eliminated the need for bloodletting because the illness was understood to have a dramatically different cause.
The difficulty for leaders today is to willingly, radically challenge their own leadership paradigms just as physicians challenged their own beliefs about medicine in the 1800s. It’s this simple and this difficult. What makes this difficult is that we live inside an existing paradigm that we simply take for granted; we don’t spend the time to challenge the prevailing thoughts, actions, and dictates. While I worked inside General Motors, we were well trained in all the most popular Fads. We were expected to adopt and integrate Phase Gates, QFD, Robust Engineering, Design Reviews, Integrated Supplier Development, FMEA, and others. This resulted in more steps, more complexity, confusion, and overlap. The paradigm we were in was solutions-oriented with the unquestioned assumption that if we just adopted these things, we would get better.
During this same period, the concepts for improving product development were guided by experts suggesting multiple, overlapping solutions. For Example, PDMA (Product Development Management Association), at the time was considered the gold standard for product development. In 1990, they suggested over 40 best practices for companies to embrace. Even though each of these best practices was a good concept, instead of suggesting that Directors of Engineering should identify their specific problem areas and experiment with a few best practices, they led many to believe that they needed to roll out 40 plus to be successful. After following the PDMA solutions-oriented guidance, many company leaders found that they did not make the performance improvements expected and eventually abandoned many of these practices.
Embracing a New Paradigm: “Problem Solving for Complexity”
Let’s walk through how effective problem solving works specifically for product development.
The problem definition at the delivery point of the value stream should be tied to a business problem and defined as a gap that can be measured. Product Development is a primary value stream with a few important considerations that have already been discussed.
- The customer is manufacturing. Product Development delivers knowledge to manufacturing so they can deliver products to the
- The delivery is knowledge – all the information manufacturing needs to build the product including specific documents like the customer needs, product drawings, bill of materials, processing equipment, process steps, and quality
The First 3 Steps of Problem Solving
Problem solving starts at the top of the organization and leaders need to convert their solutions thinking—their ideas for what will work--into problem gaps. To do this, leaders learn effection problem solving and specifically focus on the first three steps.
Below is a picture of a Product Development Value Stream where the delivery point to manufacturing is clearly identified. There are three separate, sequential steps for leaders to begin the process of using a problem solving approach to making product development improvements.
P1 – (What) Define the problem at the point of delivery.
Stay focused on the output of the value stream. Don’t jump to what are the problems inside the value stream at this point. For now, just the P1 focus is important. What is the problem? Discuss the metrics at the point of delivery: quality, lead-time, on time delivery, safety, and price versus cost. Which one is the largest and most important problem to solve? For example, the delivery of the knowledge to manufacturing for product development can have a problem with lead-time, the total time it takes to go from start of the project to the beginning of the manufacturing process. Look at the recent launches of products made last year. Capture how long each project took from start to end. Average the information and then set a target for the new performance level. Let’s assume the average was 24 months; you can set a new target of 12 months for example. Your gap--the number of months you want to remove--is 12 months.
P2 – (Where) Determine where inside the value stream there are contributors to the gap define int the P1 problem definition.
The next step is to walk through the value stream steps and phases and look for those areas that create disruption to flow. The typical disrupters are delays, rework, interrupts, defects, and handoffs. For the 12 month gap, determine how many months each phase is contributing to the 12 month gap.
For example:
- Product Definition Phase 2 months
- Concept Narrowing 2 months
- Concept Selection 1 month
- Detailed Design 7 months
These are the phases where the delays are exposed but, not necessarily the place causing the delays. The next step uncovers the root causes of these delays and rework.
P3 – (Why ) Find the root causes at the points where the work is done.
The individual process steps are performed by the people creating value. Here, the people doing the work will work in cross-functional teams at problem solving to identify the root causes of the problem contributors in the value stream. They select improvement projects, define how to analyze for root causes, create experiments, look for countermeasures, and verify irreversible fixes.
The most important part of the above three step process is writing a good problem definition, one that clarifies an important problem at the delivery point to the customer. You also need a way to measure that problem gap. And lastly—this is important-— leaders need to work on one or just a few problems at a time to allow the organization to learn how to use an integrated cross-functional problem solving process.
How to Create a Problem Solving Culture
No doubt about it, transforming from the “Imposing Blanket Solutions” to “Problem Solving for Complexity” paradigm is a total culture change. Making this shift cannot be done in a linear fashion; it takes leaders owning, practicing, and modeling thinking and actions in concert with the new paradigm. Meaningful results start to occur when all team members begin thinking and acting differently, in concert with the mental models of the new paradigm of their own volition.
In our research, there are three interdependent actions to take in order to transition to a Problem Solving for Complexity culture.
Action 1: Build a Framework for Problem Solving and New Knowledge Creation
The work here is to get everybody aligned and focused on delivering value to the customer. To do this, teams that engage different functions need to work together looking for problems inside the value stream. This enables people to solve problems together, not inside their individual silos.
The figure above shows two value streams: Product Development and operations. It shows the starting point (product strategy) and the ending point (delivery of products or services to customer). For defining the framework for creating knowledge, our starting point is the identification of the product strategy and the ending point is the delivery of knowledge to operations. The key idea here is we need to go from product strategy to delivery of knowledge to operations in the most efficient and effective manner.
Next, we can look at four specific actions we can take to support this process of creating new knowledge.
- Cross-functional teams that are focused on problem solving
- The management process based on creating first, then executing tasks
- Fast cycles of learning
- Making real time information available for managing and learning
Cross-functional teams that are focused on problem solving
From the start of the value stream (product strategy and kickoff) all the way to the delivery of knowledge to operations, creating new knowledge needs expertise from different functions to answer the questions about customer needs, technical product needs, business needs, and manufacturing needs. All of these teams and functions need to work together, in parallel, to minimize the delays and rework.
A management process is based on creating knowledge first, then executing tasks
We need to have clarity on the exact point in product development when work moves from creating knowledge to execution and the synthesis of this knowledge is converted into usable documents. After the knowledge creation is finished, the next part is called execution. The motto here is learning before execution.
If we look at the path of Product Development from Product Strategy to delivering knowledge to operations, we need to make a conscious effort to separate the knowledge creation part from the execution part. Why? If knowledge creation is mixed with execution, we will have real trouble extracting learning from rework. Learning and rework can actually look like the same thing. If we aren’t careful, we will easily create unwanted rework and delays.
So many product development processes I have observed have these two parts mixed together. Some leaders believe that you need to build a complete production part in order to find the problems. But by separating knowledge creation from execution and making sure that your teams learn first, this teaches people the value of effective problem solving upfront, which makes everything else later more effective and the whole process smoother.
The knowledge creation aspect of this work, the place where the most learning takes place, is really about getting questions answered as fast as possible. This phase includes defining customer needs, identifying concepts to solve customer problems, narrowing these concepts down through a rigorous deselection process, quickly finding the concepts that do not work, and then verifying that the concepts are robust. The Execution phase includes detailed design, final validation testing just to make sure, and lastly, packaging the knowledge to hand off to operations.
Fast cycles of learning
The teams are cross-functional and structured for fast learning using a PDCA (Plan-Do- Check-Adjust) learning cycle process. This starts with the teams getting together regularly (daily) for fast execution.
Teams start with a quick Check using the following questions:
- What did we get done?
- What worked?
- What didn’t work?
- What did we learn?
Then they Adjust based on how they answered those questions:
- What are the questions to be answered? (You can ask teams to fill out a knowledge creation template that captures what they have learned, what are the next questions, and what are the fastest ways to get answers).
- What are the actions to answer these questions (countermeasures)?
The next step is to Plan for the day:
- Actions are selected, timed, and assigned responsibility. Many of these actions are related to acquiring new information and
The last part of the cycle is Do, to complete the actions.
- Team members disperse with the tasks/actions they collectively identified and aim to accomplish them before the next
The PDCA cycle is the framework for learning. The sense of urgency comes from the personal commitment from each member to get the answers needed to grow the team’s collective knowledge rapidly.
Make real time information visible for managing new learning
The final action is to create the framework that has problems, measurements, and actions made visible. This is so that teams can use real time information to assist with the process of learning and creating knowledge (about the product and the development process).
There are two different levels of visual management: Project Execution and Value Stream Improvement.
Project Execution. In order to keep people on track, visual management might include:
- The timeline for the next phase review
- The top five problems currently being addressed
- Which step in the problem solving process is active
- What questions need to be answered for that review
- A knowledge capture sheet including what is known (and how you know it), what are the next questions,
- The next day’s plan with actions (and clear roles and responsibilities)
Value Stream Improvement. The visual management for making improvements to the product development process might include:
- The value stream map
- Problem areas on the value stream map including rework, delays, and interruptions
- Measurements on the map including speed of learning, lead-time, quality handoffs
- Improvement goal, responsibilities, features, questions, action plans for problem areas
Action 2: Grow Respectful Social Connections
In many companies, I see technical problems given to individuals as problems to solve. The person does his or her best, but often does not take advantage of looking at the problem from multiple perspectives. There is little collaboration around problem solving.
The problems to solve in product development also require looking at problems from different points of view and creating opportunities for people to learn and experiment together. No one person can see the big picture, and how all of the parts are connected (influencing each other all of the time), especially in social systems. In order to effectively learn together, people need new communications skills. We need to practice how to listen with respect, accept other people’s thinking, and then work together to find more robust solutions to problems.
There are three basic types of communication methods in social interchange: Dictate, Debate, Dialogue. From David Bohm to Judith Glaser to Ed Schein, many of our best thinkers have written about how dialogue is the only type of communication that builds respect and trust between people. Dialogue creates a safe and transparent environment that truly advances learning and serves the work. The easiest way to create dialogue is model the communication style as the leader.
Dialogue starts with respecting the other person for their thinking capability and they probably know something about the problem situation that you have not observed. Then, shut down your thinking about the problem and direct your energy to empathetic listening so you can understand their thinking. Finally, ask open-ended questions for guiding deeper thinking and creating greater understanding.
Action 3: Accelerate Learning For Knowledge Creation
As leaders, we need to be proactive and personally invested in developing fast cycles of learning. We need to set expectations and model behaviors for learning through cross- functional teams that are focused on problem solving. Leaders can create a clear process for bringing people together where they can share ideas about the product design and the product development process. Creating a mechanism for fast cycles of team learning is essential to grow and accelerate learning.
Accelerated learning organizations have the following characteristics:
- Cross-functional teams that meet regularly to solve problems. They capture what they know, especially what they need to know to be effective in their work, and then keep this knowledge visible for
- Teams use a standard process for problem solving and participate in “active prioritization.” All work is framed in terms of the next, highest leverage problem to solve. Each day, teams review problems that were solved the previous day and select the next one to work
- Deep reflection on a regular basis is just part of everyone’s job. This is the Check and Adjust part of PDCA. For example, there can be a weekly reflection for weekly plans. Reflection is encouraged and supported, and it’s usually the leader who facilitates reflection
Conclusion
In his book Thinking Fast and Slow, Daniel Kahneman explains how there are two concurrent systems in our brains. System 1 is our automatic system. We use this system more often because it takes less energy and we are structured for energy efficiency.
System 2 requires more energy and conscious effort, and it operates methodologically. In order to control the use of System 2, we must create a focus on what we actually want and intend to do.
Most product development organizations today are stuck in System 1 and need to make the transformation to System 2. This is because the current paradigm we see in organizations today (“Imposing Blanket Solutions”) supports and encourages creating more noise, more information, and more actions. When we are living in this old paradigm, we continuously engage System 1. And, of course, it is tempting to put our faith in one blanket solution that will solve our work problems rather than carve out dedicated time to focus on real problem solving! To start for “Problem Solving for Complexity,” we have to do the much more challenging work of engaging System 2 even though we’re hard-wired against this. It’s a total paradigm shift that requires a deeper level of self-awareness and discipline because we simply need to use a different part of the brain. But the hard work is worth it. The new “Problem Solving for Complexity” paradigm can help clear the mind of noise and create desperately needed focus. It uses a systems approach and engages everyone in the organization in the practice of daily problem solving… something that very quickly becomes meaningful for people and builds strong teams.
R&D and or Product Development is the place where this paradigm shift is most likely to yield the best results. Why? Because Product Development is about creating knowledge based on facts, as fast as possible. The most effective way to create knowledge is to engage the entire organization in breaking the old habits of solutions thinking and adopting new habits for learning fast. As a result, your organization culture can be transformed to everybody becoming highly developed problem solvers.
Over the past 15 years, my partners and I at Lean Transformations Group have been continuously improving an intervention methodology that helps leaders and teams make this transformation. This methodology has evolved from other successful engagement approaches including Action Research, the GE model called Work-out, and the GM program named GoFast. And since these earlier programs were deployed based on the Blanket Solutions Paradigm, we adopted concepts from complexity theory and modified the intervention approach to help it grow from the bottom up, maintaining a connection to senior leaders who are focused on solving business problems.
At LTG, we are also proud to have created an intervention methodology that allows us to interact with clients as co-learners. For our clients, this enables dramatic performance improvement through learning. For more about these principles, visit lean-transform.com or explore my book published by Routledge in 2019, Transforming Leader Paradigms.