I finished reading Product Development for the Lean Enterprise: Why Toyota's System Is Four Times More Productive and How You Can Implement It, by Michael N. Kennedy.  This book explains why Toyota's internal product development process has enabled them to surpass the Detroit auto manufacturers production in both volume and quality.

If you haven't heard already, Toyota now sells more cars in the U.S. than General Motors, as of 2007.  It's also no secret that Toyota makes the highest quality cars you can buy today.

In his book, Kennedy contrasts the Detroit product development models with Toyota's model.  He explains that the Detroit manufactures have concentrated on improving the manufacturing process by incorporating JIT (Just-In-Time) Assembly, and investing in Robotics.  He points out that although gains have been made, the Detroit manufacturer's have really been missing the core of product development--the customer.

In contrast, Toyota has focused on the development process, not only the manufacturing process.  He explains that Toyota invests much more time up front studying customers and getting their insight about product features.  Moreover, Toyota product managers "catalog" various component options and make them available for other product managers to pick from and learn from.  Ever wonder why basically every Toyota and Lexus model car has the exact same window-up/down buttons?  This is why.

These tactics give Toyota both the flexibility and the insight to be able to deliver higher relevance and higher quality in their products.  Not only does Toyota now sell more cars in America, in terms of volume, but also has more vehicle models available for consumers.  This is a direct effect from successfully gathering the voice-of-the customer.

You can't help but commend Toyota for getting it right.  You should always gather customer insight with any product being developed.

I think the Toyota model translates well to software development in the following ways:

1. Gathering customer insight about a software product should be mandatory.


2. Structuring code in re-usable formats (classes) will improve the effectiveness of the development group over time.


3. Keeping a library of UI artifacts and ideas can help a development team make decisions faster, and have a more consistent look and feel across a large project, or across multiple projects.


4. In the software industry, we often make the same mistake that the Detroit manufactures make by supposing quality is our final endpoint (ie: "Quality is Job One!").  We need to understand that relevance is different from quality, and we need to structure our processes to maximize and measure relevance, along side of quality.

Mike J Berry www.RedRockResearch.com