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?