Product Development is like walking on water – It’s a lot easier when it’s frozen.

I remember being a new engineer bent on setting the world on fire. I was less than 5 years into my career, excited to be working at General Motors on the Chevrolet Corvette. I recall seeing a cartoon pinned up by the desk of one of the ‘experienced’ engineers. The cartoon was of a person walking on a frozen lake. Under the cartoon was a caption that read, “Engineering is like walking on water – it’s a lot easier when it’s frozen”. I remember thinking, ‘That’s right! Why can’t we just get clear product development specifications that are frozen before we start and don’t change, so we can do our work?”

I spent most of my career with that mindset, “Why can’t those guys just decide what they want and freeze the specs so we can design?” (By the way I’ve found it’s always ‘those guys’) As I learned and managed through stage-gate processes, I put a lot of emphasis on clear requirements and freezing specifications early in a project. It was a lot of work and specifications always changed during the project. I consoled myself by justifying the work of freezing specifications with the belief that if we didn’t invest that time, it would only be that much worse.

It wasn’t until I started working with Dr. Allen Ward and he introduced me to Lean Product Development that I realized my approach was nothing short of absurd. How could I possible freeze specifications at the beginning of a project when I knew the absolute least about a project? Development is all about closing the gap between what you know when you start a project to what you need to know to launch a project. Freezing specifications and picking a solution early (point-based) results in an organization frantically forcing a suboptimal solution in an attempt to make a launch date.

The whole basis of Lean, or Set-Based product development centers on narrowing the specifications as the organization learns more about the capabilities through the course of product development. As the design progresses, specifications and respective sets of solutions are gradually narrowed based on the knowledge gained. Counterintuitive to everything I had been taught, critical design decisions are deliberately delayed until the last possible moment to ensure that customer expectations are fully understood and the final design converges on an optimal solution that meets the requirements of all functions (design, manufacturing, etc.).

Set-Based (Lean) product development provides for a structured approach to narrow solutions sets in a way that brings specifications and technical capabilities together to optimize the design and the project. A fundamental byproduct (or perhaps the driver) is that the organization works to learn and capture knowledge in such a way that the learning is reusable on subsequent projects making each project more efficient and effective than the previous. I’ve seen 2 and even 5-fold improvement in organizations that switch, and the work is more rewarding as well.

Isn’t that why we all got into product development in the first place – we like learning, discovery, and introducing cool new products and services?

Death to Stage-Gate

Allen marched into my office with authority, slammed his fist down on my desk with a loud bang and proclaimed, “Damn it Dantar! You’ve got to abolish stage-gate! Its evil – Kill it or I’m not working with you.”

Dr. Allen Ward was brilliant, a bit eccentric at times, but that was part of his charm and effectiveness. I had convinced Allen to work with us to improve product development at Harley-Davidson. Now just a few meetings in, he was demanding I abolish the backbone of our development system. The entire organization was focused on stages and exits? I had grown up with Stage-Gate systems. It was comfortable. It’s all I knew. Abolish it?

It was after this conversation that I really began studying my metrics and with Allen’s coaching started looking at numbers I had always monitored in a different way. When I looked at my data differently I came to realize that over the past 5-years there had been absolutely no correlation between stage-gate exits and successful projects. All my effort had been focused on forcing the organization to work harder to get their exits on time. What a waste! But, that’s what I had been taught, and all I knew.

Before the obituary for stage-gate is prematurely written, let me say that stage-gate has value, just not as a development process. Stages and Gates can be effective for fiscal oversight, but makes for a very poor development framework. But replace it with what?

Shifting to a Set-Based, Lean development framework driven through Integration Events drastically improved our throughput and predictability. It’s not an easy switch, and I found much of what Allen taught me to be counterintuitive. But the efficiency and effectiveness of a set-based, Lean development framework is well worth the journey.

Why do organizations persist in using an ineffective development framework? Is it all they know?

If you are interested in a framework for the systematic improvement of product development through organizational learning, there is information in this article: https://www.linkedin.com/pulse/framework-systematic-improvement-product-development-dantar-oosterwal

If you’d like to learn more about the transformation to Lean Product Development at Harley-Davidson, there is information here:
https://theleanmachine.org

If you would like to learn more about Lean Product Development, you may be interested in an on-line seminar with information here: http://leanfrontiersdirect.com/lean-product-development-lean-frontiers-direct/

Related Article: Why do organizations expect the result Lean Product Development delivers but are unwilling to do the work?
https://www.linkedin.com/pulse/reflecting-dr-allen-ward-why-do-organizations-expect-oosterwal?published=t

A Framework for the Systematic Improvement of Product Development.

I tell my friends in manufacturing they have it easy. Manufacturing is easy to improve because you can physically see the work. You can follow the flow of material from incoming receiving to shipping. You can watch a part come into a machine or into an assembly station and see the physical transformation of the part. You can walk into a factory and know immediately if ‘the line is down’, count the rate it’s running (Takt time), and you can see the problems. That is not the case in product development. I can’t stand at my office door or peak over my cubical wall and see if ‘product development is down’. Most organizations don’t even think about their product development rate (cadence). I can’t see the flow of work and I can’t see the problems. I can see the results of the work, the output of my product development system, and I experience the consequences from the problems caused by a system I can’t see every day. So how do I improve a system I can’t see?

History has shown the only way to improve is by learning and doing. You can’t improve if all you do is learn and never apply what you learn. You won’t improve if you work hard but never learn. In order to improve you must ‘Act and Reflect’.

So let’s put this notion of Action and Reflection in the context of a product development system. The diagram at the top depicts a framework for learning and action to improve a system you cannot see. (The Learning / Action Matrix™)

Along the vertical axis are stages increasing in depth of reasoning. Progressing up the axis, each stage increases in leverage but reduces in tangibility. Your greatest leverage for change is in your vision because it has the broadest reach, yet vision is the least tangible. The least leverage is in individual events that occur in the product development process, although they are the most tangible. Unfortunately most organizations spend their efforts on tangible, low leverage events in fits of ‘firefighting’ just to get product out the door and never progress up the axis where the real leverage for improvement exists.

How do you instill a vision and improve product development?

The Learning / Action Matrix™ above identifies the four steps necessary. Learning begins in the first step by observing the events and patterns that occur and testing your observations against your vision. How do the actual events and patterns you observe compare to the vision you have? What are the gaps? Gain clear alignment and document the gaps against your vision, then move on to step two.

The hard work of leadership and improvement begins in step two by assessing the systemic structures of your processes that caused the events and patterns you observe. For example, were resources shifted from later projects to help resolve problems with projects closer to production creating more issues on the projects they were pulled from? Why? What caused the need? A strong leadership team will challenge themselves in assessing their individual mental models of what occurred and why. It is critical this happen without pointing fingers or blame. Build a collective mental model of your development system and test its behavior against your vision.

Step three entails identifying the changes in behavior that the leadership will undertake based on alignment on mental models to support the shared vision. As you assess the connection between behaviors and results, develop the changes to the system and actions you will take. Use the scientific method to improve your next learning cycle by documenting the improvements you believe your changes will deliver.

Finally, step four – take action! Go implement what you identified. Change behaviors based on the structured, deliberate rationale you agreed. Hold yourselves accountable but recognize you have not achieved perfection; so get ready to do it again.

Setting aside one day per month or per quarter for your team to reflect is a good way to start. If you want to kick-start the process, borrow liberally from proven Lean Product Development methods as part of step 3. Do not implement blindly. (Blind followership does not allow for learning) Challenge the changes against your mental models of how your product development works. That’s how you learn. There’s just no way to circumvent these cycles if you want to learn and improve.

Related Article: Why do organizations expect the result Lean Product Development delivers but are unwilling to do the work?
https://www.linkedin.com/pulse/reflecting-dr-allen-ward-why-do-organizations-expect-oosterwal?published=t

If you’d like to learn more about the Learning / Action matrix™ and its application, the book, The Lean Machine, provides insight through its application at Harley-Davidson with information here:

Businessx Front Page

If you would like to learn more about Lean Product Development, you may be interested in an on-line seminar with information here: http://leanfrontiersdirect.com/lean-product-development-lean-frontiers-direct/