This series of blog posts will bring up the article “The New New Product Development Game” in the Jan 1986 issue of HBR [1]. It is a well cited article in many books and articles. It describes some Japanese* and American companies, like Honda and 3M, which made some very successful new products in short time with new ideas both in product development and production. This was achieved with a strong collaboration between sub-teams working in parallel, where a cross-functional main team** with a wholeness view throughout the whole project hold the conductor’s baton, and with only subtle control from management.
So, let us elaborate on what the authors of the article found out as the way of working for these companies, and compare its fulfilment of our set of principles. In this first blog post, we start with the right part, the activity side of our start organisation definition “People that interact to solve activities with interdependencies”. We take the principles one by one, starting with the right side of our start organisation definition “activities with interdependencies”.
Principle: We need to take care about encountered product or organisational problems directly and also continually do improvements, as well as clearly understand the difference between them.
This is why the companies made the organisational change at all, they tried to solve their organisational problems they have in the new market of speed, flexibility and more complexity when making the products.
Principle: We need to be able to work in parallel (if needed).
If you need to work fast, you need to work in parallel, as we discussed in this blog post about Agile development and in this blog post about parallel work for I-shaped teams. If you also have uncertainties or need to try new solutions, you really need to work in parallel with everybody in the same boat, with iterations of very short time boxes from the start, to be able to leave the Complex domain in the Cynefin™ framework as fast as possible.
The companies in the article had both the need of speed and flexibility for their projects; very challenging goals that required new pioneering technical solutions both in the products, and the way they were produced, and that the projects also need to be performed fast.
And their solution for parallel work, were overlapping development phases of two different types, type B and type C, where type A represented the traditional sequential waterfall way of working, like this.
Type B, used by some companies in the article, is the same as our semi-parallel way of working, and looks like this.
Type C, were used by some other companies in the article, and is the same as our parallel way of working, and looks like this.
Since the product development was done with all the phases at the same time, the team members also learnt very fast to give and take, since when everybody is doing everything together, one party cannot do things only for themselves. And, as the authors write about parallel work; “It stimulates new kinds of learning and thinking within the organization at different levels and functions.”, i.e., multi-learning, which is brought up later in the series. Of course, it is very important of an early involvement of the suppliers and production people, they cannot be treated like it still was waterfall way of working, since that certainly would mean a failure of the projects; too expensive products, difficult to produce the products, bad quality of the products, etc.
This means that for this principle, the companies in the article have a perfect match in fulfilment of it.
Principle: We need to be able to work incrementally (if possible).
Incremental work, to portion out the product to the customer, can be done when you have the knowledge, which means that we are in the ordered domains in the Cynefin™ framework, the Complicated or Obvious domains, to just fill the gap.
And as we discussed earlier about incremental work in this blog post, incremental work is easier to see and understand in software product development, then in hardware product development.
If we see benefits of incrementally making the product, we must do that to please our customers, and so we can get early return of our investment and fast feedback from our customers and users. As stated in an earlier blog post, a platform with modules in hardware development is a form of incremental way of working.
Multiple concepts thinking, since long time used at Toyota’s product development, is one way to reduce the risk for failure of the whole car, and can be referred also to incremental development. As long as we have multiple concepts and one of them has low risk, we can at the same time also go for a riskier concept that uses for example a new technology. This means that the riskier concept may be in the Complex domain, but the low risk in the Obvious domain, and the product development of the whole car is therefore in the ordered domains with a predictable release date.
Since the article describes hardware companies, and the article not mention anything about incremental work, this principle is hard possible to evaluate. But the principle is taken care of in some aspect, since the products most probably are modularised in some aspect, so the later different models of the product can be brought fast to the market.
This was all for this blog post, and in the next one, we continue with the principles for the activities. C u then.
*Toyota is not mentioned in the article, but the described way of working in the article is very close to the way Toyota is working, or what we in the Western world later come to call Lean Product Development.
**The first paragraph of The New New Product Development Game [1] states that everything starts with the main team; “In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a method that is holistic—as in rugby, the ball gets passed within the whole team as it moves as a unit up the field. ”
References:
[1] Takeuchi, Hirotaka and Nonaka, Ikujiro, ”The New New Product Development Game”. Harvard Business Review, Jan 1986 issue.
Link copied 2018-09-05: https://hbr.org/1986/01/the-new-new-product-development-game