SwimBlog  -

+ 1 - 0 | § ¶Not All New Product Development Projects Are Equal

Building on some of my recent posts about the different challenges facing different types of product development teams, I thought it would be worthwhile to try to outline the characteristics of each type. Later I will write about the key challenges for each. Note that I am talking here about 'physical' products rather than software or services (another couple of dimensions to be explored at some later point).

Type 1 : Pre-emptive Product Development - example: new car model.
This is where a company chooses internally what to develop. This is the type most people have in mind when they talk about New Product Development. Its characteristics are:
- Focus on Markets / Customer Needs to drive a product specification.
- Important to identify and kill projects with low probablility of success as early as possible.
- Project lifecycle is relatively long.
- The developer has control over whether and when to launch (caveat: subject to external influences such as trade show dates or competition).
- Design for manufacture is usually important because of the larger production runs.
- There may be significant investment in manufacturing plant and tooling.
- Product costs are important.
- Project costs are typically treated as business overhead.

Type 2 - Core Technology Development - example: Direct Injection Gasoline engine technology
This is where new technologies or processes are developed off-line from revenue generating projects. Characteristics are:
- Project may not generate revenue in itself in the short term.
- Technical risks can be very high so failure is entirely possible.
- Manufacturability and product costs are less important at this stage.
- Typically there is little or no capital investment.
- Project costs are attributed to R&D.

(more)

+ 1 - 0 | § ¶Where am I??

I was talking to a small group of product development managers in a client firm the other day about the scant use of metrics in their projects. I could see that they appreciated the basic message but I strongly suspected that their paradigm was different to mine. I got to thinking afterwards that the problem might lie in the term 'metrics'. This tends to conjure up a mental image of tables of numbers. This in turn leads people to think about measuring outcomes and results. Now outcomes and results are important, but by the time we measure them, it is often too late to do anything about them. I think a far more useful way to make decisions about NPD is to use trends. This means we can intervene as problems are occurring rather then after they have happened. So, I have resolved to stop talking about Metrics and start talking about Indicators.

Indicators (to me anyway) have broader connotations. They give you information about where you are and where you are going. I like to think of three sets of indicators:

1. High level system indicators - these tell us about the health of our 'Product Development System' - e.g. whether we are becoming more or less efficient, bringing products to market faster, improving designed-in quality etc.
2. Project Level Indicators - used to determine the how well our project is progressing - e.g. whether we will complete on-time
3. Product Level Indicators - used to determine the completeness our knowledge of the product / markets and our confidence in delivering a competitive product.

Decisions on how to improve our NPD practices will normally be driven by (1) and informed by case studies or audits of projects using (2) and (3). Decisions on individual projects will normally be driven by combinations of indicators in (2) and (3).

I think most companies have have some kind of indicator they use for (2) but far fewer consider (1) and (3). Lack of (1) means means they are less likely to spot oppportunities to improve their product development processes over time, or measure the results of any improvement efforts. Lack of (3) means that poor products are potentially introduced into inappropriate markets.

There is a linkage here with my previous post on the Question/Answer Breakdown System (QABS). I spot an opportunity for indicators for (3) to be designed around the number of questions answered and the present degree of confidence in the answer.

+ 0 - 1 | § ¶Blogging in NPD

For a while now I've been trying to develop my own thoughts on how to use blogging as part of the product development process. I came across a useful case-study written by Suw Charman on the introduction of a business blog to gather competetive intelligence in the pharmaceutical industry. There's a lot of useful advice from the company in question on how to establish and manage a business blog. However, in the study, the original blog content is provided by a small team of editors. In my view this somewhat resticts the use of the blog to the 'pushing out' of information, as opposed to developing knowledge collaboratively on-the-fly.

It occurred to me that a major feature of blogs is that they facilitate 'useful gossip'. The nice thing is that the gossip does not have to be real-time (unlike Instant Messaging for example), and is more widely visible and accessible (unlike email threads). This encourages reflection and thoughtful analysis by a potentially large number of participants, and allows ideas to develop, or gossip to be corroborated from different sources. In order allow gossip to develop in this way, permission to publish original content must be open.

So, what elements of New Product Development are gossip-worthy? Well - I guess it depends on whether the gossip is directed at product development in general, or whether it is related to a specific project. Some starters:

General
- Competitive Intelligence (!)
- General field / service issues / usability comments for existing company products
- Manufacturability wish-lists and moans
- Latest technology developments relevant to company products
- Latest industry / application trends

Project Specific
- Specification development - logging assumptions, requesting clarifications, establishing confidence in maturity, relevance and importance
- Engineer's notebook - e.g. rationale and feedback on design decisions, problems encountered and possible solutions, current progress reporting
- Prototype build notes / test logs.

I'm sure there are many more

+ 0 - 1 | § ¶Innovation in Engineer-to-Order Companies

My previous entries on the characteristics of an Innovation System and problems in Engineer-to-Order companies lead naturally on to thoughts of where Engineer-to-Order companies should look to innovate. The logical conclusion is that as competitive advantage is mainly contained in the project, this is the area to focus on. Effectively ETO companies would shift emphasis from innovative products to innovative services. The physical product effectively then becomes the part of the service.

So - this means finding ways to be super-responsive to customer bids, proposals and quotes, offering alternatives and options to make it easier for the customer to buy, giving the customer something that will wow them even before you've got the order, and then once the order rolls in, impressing them with delivery performance that exceeds their expectations. So there you are - it's easy isn't it? Unfortunately, just like 'normal' product development, Engineer-to-Order projects can also be higlhy iterative with customers changing their minds, wanting new options, mixing and matching, altering specifications or releasing unexpected information that affects your design. To deal with this, innovative ETO service will be characterised by rapid change analysis, short decision making paths, smooth information flow, connected systems and above all else efficient communication.

This does not mean however that ETO companies can simply forget about the product. Innovative product design and definition can have a significant influence on ETO project innovation. In particular, products, subsystems and components that are designed to be modular, or have similar family / group characteristics that are interoperable, lend themselves perfectly to fast, responsive projects. The problem is, how do you encourage designers to 'think modular' when they are pushed to release their designs as soon as possible to meet the customer delivery date? Well - it isn't easy, but it is possble. There will be more to come on this.

+ 0 - 1 | § ¶Late Decisions vs. Procrastination

Frank Patrick at in this post on his Focussed Performance website mentioned the case for Just In Time decision making, which some people might associate with procrastination.

In product development projects, JIT decision making, or what I prefer to think of as 'committing at last sensible moment', is a desired outcome if teams are to avoid locking in poor design that may require expensive rework later on. Essentially the rule is to keep your options open as long as you can. In product development, our goal is to gain the most complete knowledge about our product and our potential markets that we can, before we launch. In an ideal world, we would commit nothing until we have as much information as we are likely to get, then develop our product in a spectacular frenzy of work.

Of course, in the real world the product devlopment process is not like this - it is a highly iterative voyage of discovery and feedback. It is not possible to know everything in one go. Therefore our last sensible moment for decision making is not necessarily 'when we have all the information'. The criteria for deciding when to decide are likely to include:

(more)

+ 1 - 0 | § ¶Innovation System

We mentioned here that creative ideas do not (normally) just turn into innovative products, processes or services by chance. What is needed is a little helping hand. We proposed the need for an 'Innovation Engine' or 'Innovation Machine'. I'm not sure if I'm totally comfortable with those phrases as they imply a deterministic and distinctly non-creative process. Actually - I prefer 'Innovation System'. The idea is that in an Innovation System there are a number of processes working together to foster creative ideas and help convert them into commercial benefit.

We see the 6 system processes as:

1. Reflect - Become aware of issues, needs, possibilities, opportunities
2. Create - Create concepts and ideas, test theories, try out technologies
3. Select - Filter ideas and concepts, choose those with potential, estimate benefits
4. Exploit - Turn ideas into products, applications, value propositions
5. Protect - Take steps to make innovation proprietary and maintain competetive leadership
6. Enable - Provide management leadership and the means to promote a culture of innovation

(more)

+ 0 - 1 | § ¶Problems to Order

The Product Development community tends to focus on developing tools and methods for manufacturers who 'pre-emptively' (or you might say 'speculativley') design and develop their own products for later launch and sale. In these cases, the focus is very much on making sure the product has a built-in competitive advantage, has adaptability for different market niches, and can be manufactured in volume at low cost.

In contrast, the engineer-to-order world has some different challenges - competitive advantage is largely down to two things: responsiveness to the inquiry > qoute > order > manufacture > delivery cycle, and the ability to provide for a specific technical need. Thus the competetive advantage is more biased towards the project rather than the product. Manufacturing efficiency is normally not a big issue.

(more)

+ 0 - 1 | § ¶There are more questions than answers...

Having been around New Product Development longer than Lean, Six-Sigma, CAD, CAM, PLM, Portfolio Management, Stage-and-Gate, Innovation Management, PMBOK (you name it, I've seen it), I still believe that the key to effective Product Development is asking the right questions and then figuring out how to answer them. I have seen several product development teams and project managers fool themselves into believing a product is right or ready to launch purely because they have carried out all the tasks on the schedule. They then find out that manufacturing capability is still flaky, or reliability is poor, or the product is not suited to a particular application. In a good product development 'system' the questions that would have raised these issues may be embedded in the work content, but the key word there is 'embedded'. What if we were able to make these issues more visible?

I'm currently working on a model of product development that uses a Question/Answer Breakdown Structure (QABS). This QABS would focus the team on the 'real' aims of the development work rather than on carrying out specialist or functional tasks. A metric of where we are in the product development lifecycle could then be how many questions we can answer and with what degree of confidence. With this information more visible, decisions might become better informed.

Early days yet but any feedback is welcome.