Knowledge based product development

Today is my birthday, I always like where possible to take the day of work and do something enjoyable. This time I’m at home taking it easy, catching upon reading and writing. One of things is allowing to his finish reading my latest book. I normally have two or three books go at once, usually a novel, something serious and perhaps another book which I wish I had time to read.

I've commented here before that I have recently become a Product Manager - when I say recently it was almost six months ago now. Of course I want to be a good product manager so I've been looking around material to tell me how to be a good product manager, much to my surprise I find that there are very few books written on the subject of product management.

Indeed depending on your industry the role of Product Manager differs. In some industries the role of Product Manager is concerned with brand management and marketing, in other industries, like the software industry that I work in, Product Manager means somebody who determines what features the product needs, what work should be done on the product and who talks customers about what they want from the product.

So even when you find literature on product management you have to check to see which of the two types of product manager it is referring to. There is more literature on product management as a branding and marketing role then there is on product management as a development role.

In my search for product management books I came across "Product Development For The Lean Enterprise" by Michael N. Kennedy, 2003. This book describes what lean product development is, or rather what knowledge based product development is - as a book itself says knowledge based is a better description than the lean but lean is a better known term. The book is good in that it discusses not just product development but also the change process required to move from an existing product development setup to a lean, knowledge based, setup. What is unusual is that the book is written in the form of a story.

The story form makes it easy to read the book but makes it more difficult to understand what is speculation in what is hard evidence. This is compounded by the fact that the book does not give a great number of references. Indeed I was disappointed that the book fails to reference one or two books already in this field, for example "Thinking Beyond Lean" by Cusumano and Nobeoka, 1998 - another book I would recommend.

That aside, the book is worth reading and I recommended to anybody interested in the subject of lean production or product development.

So what does the book say? I won't give a full precise but here is something to wet your appitite.

It points out that Toyota have a radically different product development strategy to just about any other organization. For example Toyota use setup-based engineering, so rather than design, say, one new gearbox for a car they may develop several new gearboxes and select the best one, or combine the best features of those developed into a new gearbox.

This may seem shocking to many project managers who see wasted resource but there is more to come. Toyota does not use traditional project planning scheduling techniques - no GNATT charts here. Instead they rely on hard deadlines, a fully engaged workforce and personal responsibility to meet meaningful dates.

The idea is that developing a new product is not just a one-off project it is part of a bigger learning exercise within the organization. The exercise generates new knowledge, this knowledge is itself an asset to the company, so the company is seeking to increase its stock of knowledge and experience. In effect developing a product is simply a learning exercise.

There is an interesting theory here the book does not discussed but I will. I don't know of top my head who suggested this theory but I do know that I heard both Alistair Cockburn and Jim Coplien discuss the theory.

According to this theory there are two types of game, there are finite games, e.g. tennis, Cluedo, football, these are games which have a fixed stars and a fixed end, typically they are played to win at the end of the game there is a winner and there is a loser.

And then there are infinite games, these are games that never end, e.g. your career, life itself, in these games the objective is not to win but to survive, the games may be played in rounds and survival in one round allows you to play again.

In business, and specifically a product development organizations, you want to create a new product, you want to bring that product market and you want to be successful, in this way you're playing a finite game and you're playing to win. But at the same time you are playing in infinite game because there will be another product after this one and another round to the game. So in each round you play you have two objectives, the first is to win this round and the second is positioning yourself for the start of the next round.

So often when we develop new product, and specifically when we developed new software, we are concerned with the current project. We want to meet the current deadline so we do everything we can to meet the deadline but sometimes in doing that you are lessening your chances of winning the next round.

Software shows this perfectly, when you wish to meet the deadline is very easy to cut corners, to leave bugs unfixed, not to refactored code (so it becomes a mess) or too misuse the architecture in a way it should not be used.

The insight Kennedy, Toyota, Cockburn and Coplien offer is that is wrong to treat each round of the game in isolation, knowledge accumulated during one round is useful for the next round, indeed it is essential as the key to future competivity because in a knowledge industry, like IT and software development, knowledge is the greatest asset.

Unfortunately, many "best practice" project management techniques (or is it project managers themesleves?) fail to appreciate this.