Checkmate your competition with product development

Last Tuesday I attended a presentation by Michael Kennedy regarding the concepts in his book Product Development for the Lean Enterprise.

This book takes you on a journey that explores the Toyota product development system -- referred to as Knowledge-based Development (KBD). Why Toyota?

Toyota's new product engineers are 400 percent more productive than those employed by most companies. The result? Toyota has more net profit than all the other auto makers.

Don’t let the phrase “Lean Enterprise” fool you. This book isn’t about linear improvements, it’s about a summersault into the future that generates a host of benefits that are off the charts for the typical American company:

4X increase in development productivity

2-3X decrease in development cycle time

2-3X decrease in development costs

2-10X increase in innovation

2-5X decrease in development risk

You see, if you embrace KBD and take the offensive, this strategy will enable you to checkmate the competition. As Kennedy said in his presentation, “When a company performs at this level, it’s game over.”

Using story as his palette, Kennedy paints a richly detailed portrait of Knowledge-based Development that helps you visualize a new way of thinking about product development.

People often become frustrated trying to understand KBD, since it’s not a linear process. To understand it, you need to break free of the process paradigm:

“Try not to think of product development as a series of steps that result in a product, but rather as an overall environment that produces a stream of products.”

This environment is framed by the four pillars of KBD:

Chief Engineer Entrepreneurial Leadership

Responsibility Based Planning and Control

Expert Engineering Workforce

Set-based Concurrent Engineering

Set-based Design is the core of KBD. How to describe Set-based?

It’s not a point-based process that starts with one system concept... and then moves through design and test phases--looping back if required.

Instead, Set-based Design explores multiple concepts for each subsystem.

“You explore multiple sets of possibilities at the subsystem level against broad targets, then systematically narrow and/or combine to tighter targets... The possibilities are generated from every perspective--software, hardware, supplier, whatever.”

Redundancy is an important part of this process. Toyota never misses a major milestone, because a working solution is always included in the initial set.

What happens to a design that doesn’t make it into the final product--maybe because the technology was on the bleeding edge? It goes into the knowledge base ready for the next project.

So, you see, Set-based Design is a major reason why Toyota enjoys a 2-10X innovation advantage.

Another advantage is the chief engineer pillar -- replace administrative project manager with technical entrepreneurial leadership.

“Toyota will designate a chief engineer who is totally responsible for all aspects of a product. It’s his car, period. Even so, the people who help him don’t report to him. He’s the best engineer on the project. He makes technical decisions. He teaches and manages... He reviews status through prototypes and analyses, not completed tasks. He is also the primary customer interface and often spends time in the field understanding the customer.”

Toyota’s chief engineer role is the exception. At most companies, a program manager who has little if any design experience assumes an administrative role over the project.

I’ve observed this is usually where the comedy begins. High comedy for the engineers, low value for the customer--most companies achieve 20 percent value-added to the customer, while Toyota sets the bar at 80 percent.

The administrative approach is equivalent to making me manager of cardiac surgery--one of my career dreams. I promise to implement plenty of procedures so nobody gets hurt, especially myself. The results, I’m sure, would be similar to what 50 percent of IT projects experience--failure. Fortunately, no one has even thought of this idea... and if they did, I’d soon be fired or jailed.

Back to reality. In the book, one of the characters realizes, “Toyota appears to have personalized the concepts within the individual engineers.”

When it comes to design concepts -- if you can’t internalize it, and forget it, there’s probably little nutritional content. Instead of building procedures and structure into a design process, Toyota builds capabilities into its engineers. And everything flows -- engineers have form but are formless.

For that is the whole purpose of KBD: To produce an operational value stream that flows to the customer.

Kennedy is also customer focused. He wants CEOs to pick up his book and wonder if there’s a better way to do product development. And some CEOs have been doing just that. That’s not a surprise to me. Kennedy has succeeded where others have failed. Through story and clear-eyed analogies, Kennedy conveys a complex business subject to executives.

I could go on and on (and I probably have), however, here’s the bottom line. Knowledge-based Development has legs: It’s a filly with ability.

If this book resonates with one CEO in your industry, and that company successfully implements KBD, you’re in trouble... period. The game will be over before it starts, since new product victory has its origin in preparation and practice.

Comments

[Ashay Mehta]

I would request you to provide me the detail info on Toyota's Product Development and the activities involved in different Gateways. Is there any alternative from where I can study about the same.

Regards

Ashay Mehta

[Steve Neiderhauser]

Ashay,

The only book I've read on the topic of Toyota product development is the one I reference in the post. It's written by Michael Kennedy. Check out his website for conferences or other sources:

Targeted Convergence