New Product Development and Introduction

This article describes a best practice new product development & introduction process, and the objectives of each of the key stages and key roles within it. It includes tips on how you can identify weaknesses in your own development processes and provides a list of relevant tools and techniques that can be employed at various stages in the development. It also shows the key implementation steps and operational needs.

Links to other best practices and training at bottom of page.

Purpose of the New Product Development and Implementation Process

Objective: To generate a stream of market led, technically and commercially viable new products to support the business plan, with minimum risk, and where products and processes are both safe and environmentally friendly. (There may be a risk associated with not doing it.) (See figure 1.)

Figure 1. The new product stream

The process should not be viewed as a series of obstacles as shown in the picture above. But it certainly should include review processes to ensure that successful products are launched. The first issue to deal with is a definition of what is a new product?

What is a new Product?

New products fall into two categories:

1. New Variants
2. New Types

New Variant: "More of the same" type of product.

This is simply a minor variant of existing products, which presents neither significant technical nor commercial risk.

New variants do not require elaboration here.

New Type: A new type of product, which requires major product, process and / or market development. This type of development is the focus of the article.

It is important to note that development process success is not a successful product development alone. It is also the timely changing or stopping of developments that are unlikely to achieve success. A development process failure is simply a product on which unnecessary effort has been expended (with the benefit of hindsight).

Definitions and Self Diagnosis Check

Stream of products

Most large businesses were once small and the life span of many large businesses are measured in years rather than decades. The notable exceptions are those who continuously bring new products to market. One method of systematically looking at this situation is to observe that there are products in all phases of the product life cycle:

Use the table below to identify how many of your products (ignoring variants) you have at each stage.

In particular you should have at least one and preferably more in at least one of the first 3 stages. If you have more than one product in the last two stages this is an imperative! However if you have more than 3 in any stage in all but the largest corporations you are headed for a problem.

Research is divorced from the development process, because although it is focused on learning, it is not necessarily focused on product or process development. In decline the slope of the graph is not relevant because at any point in decline and for a number of reasons a nose-dive could occur.

Market led

Often product development is led by technical innovation rather than market demand. There is a place for both, but whilst technical innovation can lead to breakthrough market creation, market demand led development is less risky (at the risk of lower rewards).

Technically viable

This means that the product will technically deliver quality as defined by customer wishes (not needs). (A frequently used definition of quality is "satisfying customer needs". Our definition of quality is "satisfying customer wishes", which is a rather more demanding definition.)

The second consideration on technical viability is "can we make it fly". You should start by studying your last product launch as follows. If your rate of product or process modification followed the left-hand profile shown in figure 2 you need to rethink your development process using these guidelines. The graph shows an increase in change activity as the product passes from the product development group to the process development group as the first products are being planned & produced. The second peak shows the customer feedback driving further change, (occasionally also including the worst of all disasters, a product recall). There is also a higher level of residual change in poor development. If your profile follows the right hand graph you still may learn something from this article.

Figure 2: Relationship between Product & Process Modification & the quality of the development process

Commercially viable

The product can satisfy the market need and is sufficiently differentiated from competitors at a price that will provide contribution to overheads.

Safe & Environmentally Friendly

You can no longer ignore the safety or environmental impact of your product or processes. You need specific tests to ensure that your business does not face additional risks due to safety or ecological disasters.

Support the business plan

The business plan should provide guidance on likely areas for product development, and in some circumstances will constrain developments or at least provide a strategic method of comparing opportunities.

Minimum risk

There are five methods of constraining risk throughout the life of the development:

1. Be sure that there is a market need or expectation that the market will "want" the product if it is not "needed".
2. Set target costs and minimum delivery, safety, environment and performance criteria for the product (and processes) at the outset.
3. Be sure that project management is employed to deliver the product to expected criteria.
4. Be sure that the development and operational phases are still affordable.
5. Revisit points one to four above, at each milestone via a Programme Management Process.

Figure 3. The Development Programme Management Process

The four basic risk criteria in figure 3 above also form the general criteria for passing all milestones. (See B040: Project Classification)

Owners and Managers

The owner of the development is an individual within the organisation who will be accountable, (act as customer for the development). They will be answerable for the development to the executive throughout its life.

The manager is the supplier of each stage of the development. This may change from stage to stage. The job of the manager is to deliver the Terms of Reference for the stage for which he or she is responsible, or recommend to the owner that the project be stopped at the earliest opportunity.

Concept of Gates, Milestones, Tombstones and Processes

Milestones

Quite often the word "gate" and "gateway" are used to describe hurdles in the development process to be overcome before proceeding to the next phase of a development. I believe this gives a negative overtone to the process, which is not desirable because it invites failure and may cause over-engineering. Over-engineering (which will be covered by a future article), can occur either in a product sense where the product is continually enhanced to overcome obstacles that may not exist. Or it can occur in a process sense where the project will be unduly delayed by "paralysis through analysis", (which will also be covered by a future article). Whilst rigour is needed in the process, unnecessary rigour is a deterrent.

The following process represents a simple but robust method of ensuring rapid product and process development with minimum risk. At the core of the process is a series of "Milestones" that track, check and approve the following stages. Passing a Milestone is the approval of Terms of Reference for the next stage. At any point in the development, (at any Milestone), the project may be abandoned, changed, accelerated, or simply approved, depending on the prevailing conditions relating to technical or commercial viability and safety, environment or other risk. Milestones should not be viewed as obstacles to be overcome, but an opportunity to ensure that the product will be technically and commercially successful. However unsuccessful projects will be committed to a tombstone at the earliest opportunity. This is not a reflection of the competence of the project manager. It is a reflection of the risk involved in continuing the project. If the project has been conducted professionally it is likely that there will be spin-offs which will mean the project has still been worthwhile. The process is described in figure 4.

Figure 4. Milestone Control

Milestones represent minimum checkpoints for the product development. There may in fact be other stages within these where project management controls may be necessary, due to the risks involved at that stage.

Reviewers

The role of a Reviewer is not to approve the development. It is to ensure that at the Milestone for which they are responsible there is a professional and independent evaluation of the potential success or failure of the development and to decide whether to proceed to the next stage, recommend a change, or stop the development. The Reviewer can be the owner but may be someone else. The manager cannot be the Reviewer because at critical stages in the development an outside (of the project) and impartial view is necessary.

Attitudes of Reviewers

Reviewers are certainly there to identify turkeys, but they are also there to apply lateral thinking and an outside view of the product. Often the project manager is simply too close to the problem to see the obvious. The Reviewer will use a list of pre-established criteria to review the project, but will actively seek to overcome any difficulties. It is not simply a reporting role. This is different to the role of the auditor who sees it as their role to find fault. It should also be recognised by the reviewer that new ideas are fragile precious things just like small babies and as such are easily damaged by thoughtless or prejudiced actions.

The Development Programme Management Process

Processes

The development programme management process comprises:

• Establishing a review board for developments (See B043: Managing Development (Development Committee))
• Establishing review criteria and mechanisms (See T032 Capital appraisal against KSF's)
• Continuously re-establishing and re-prioritising a potential list of projects (See B031: Competitive Comparison)
• Establishing Reviewers for individual projects and stages
• Project management
• Technical and commercial input
• Resource / budget refinement
• Collaborative development
• Team working
• Hand-holding the programme in it’s early life

This process covers the whole period from marketing concept to volume sales.

The purpose of this process is:

1. To avoid waste in the development process (The biggest waste is a disastrous project stopped too late).
2. To provide a technically effective product.
3. To ensure an appropriate response to market needs at all times. (This may require a review of the product specification, resources, budget, timing and speed of the project.)
4. To contain the technical, commercial, safety & environment risk.

It consists of the following stages:

Stages

At first sight this process may seem over-bureaucratic. However after consideration I think you will agree that each step is vital. The administration process does not need to be bureaucratic. In practice this may simply be a matter of writing a single sheet of A4 paper of the Terms of Reference and a plan for the next stage, then convincing the Reviewer to proceed to the next stage. Bear in mind this process is the mainstay of the company's future and each stage may represent a substantial amount of work, time, and cost, but also risk.

Innovation starts with the business plan and thereafter at any stage. For example if anyone in the organisation has an idea there simply needs to be a method within the organisation to capture, evaluate and implement the ideas.

At all stages processes should produce the following minimum outputs for review at the next milestone:

• Progress against the project milestone criteria
• Findings / deliverables
• A proposal to proceed to the next stage with proposed Terms of Reference, or a recommendation to change or to stop the project, or escalation of the problem to the owner (if this is not the Reviewer)
• Recommended Reviewer for the Milestone following the forthcoming one (agreed at the next Milestone)
• Evaluation criteria for the next Milestone (It is important that these are agreed in advance of the subsequent process to avoid "project drift", which will be covered by a future article)
• Lessons learned and possible spin-offs
• Updated project file
• Proposed Terms of Reference for the next stage (or confirmation that the original Terms of Reference are still OK) (See Previous Best Practice of the Week B039: Terms of Reference)

At all stages the minimum outputs of a milestone are:

• Comments on the extent to which the pass criteria have been satisfied or exceeded
• Publication of the lessons learned from the previous stage
• Approved Terms of Reference for the next stage, or other rework or tombstone reasoning (see figure 4)
• An agreed Reviewer for the next stage
• Updated project file

At any stage up to production, field trials, approvals, establishment of intellectual property, and patents may be sought and possibly made a condition of the next milestone approval. Also further market research may be necessary when a concept design or prototype is available.

At many stages additional outputs are required. The outputs are contained in a file "the project file" throughout the life of the project. (Will be covered by a future article. Information available on request)

Summary of Product Development Process Stages and Milestones

The following diagram (figure 5) summarizes the development processes and milestones you need to have in your product development process.

Figure 5: The product development process

Objectives of Individual Process Stages and Milestones

Business Plan

The process starts with the business plan. This provides strategic direction on which to highlight product development needs. (It is not the purpose of this article to describe business planning in further detail. This is covered in our course S05 World Class Change Management)

Outputs:

One of the outputs of the business plan is a list of potential marketing investigations and budgets.

Milestone 1: Approval to do Marketing Investigation

Objective:

To approve a line of marketing investigation, resources, timing and budget.

Process 1: Marketing

Objective:

To identify potential products, and target customer (types) where differentiation is possible, and define differentiation design parameters, regulation or other product, process or market restrictions including timing restrictions.

Milestone 2: Approval to Respond to Marketing

Objective:

To approve an investigation into product opportunities.

Process 2: Ideas Generation

Objective:

To identify how the market need can be met, and evaluate options to be explored to the next level of detail.

Milestone 3: Approval to evaluate preferred or favoured options

Objective:

Test fit to strategic goals, capability. This is also in the nature of a request for quotation or invitation to tender to the development people.

Process 3: Opportunity Evaluation (Concept design, product / packaging prototype, justification, feasibility, delivery model)

Objective:

To undertake technical, commercial, environmental, and safety evaluation, and generate design performance (weight, life, customer requirements etc.) and sales criteria, establish patents, intellectual property, and state assumptions for feasibility.

In product led development the process often starts here at considerable risk of commercial failure.

Milestone 4: Approval for Development

Objective:

To ensure that product is commercially and technically viable.

Process 4: Development (Detailed product, process design, and quality standards, product and process documentation)

Objective:

• To fully develop the product and the processes for Operations and confirm an outline method for delivery/ routes to market
• To establish Design / supply chain partners
• Establish Safety and Environment risks

Note: At this stage a joint Product / Process development project team is necessary to develop the product and process simultaneously. (This method is called "Concurrent Engineering".) An extra step is to include key suppliers (and potential customers) in the detailed design. (This method is called "Collaborative Engineering".) It may also be suitable to use these techniques at an earlier stage (see above).

Milestone 5: Design Review

Objective:

To ensure product, process and delivery specifications meet strategic needs and remain technically and commercially viable and will be safe and environmentally friendly. Provide commitment to process development expenditure.

Process 5: Process Implementation (Supply chain establishment and priming, operations and sales processes)

Objective:

• To undertake process, delivery trials, establish key suppliers, agents
• To establish promotions plans
• Contract review of long lead-time items. (May also require placing speculative orders.)

Milestone 6: Operations Handover

Objective:

To finalise product and process design, incorporating customer and operations evaluation.

Process 6: Pre-Operational initial delivery

Objectives:

To obtain customer (marketing) sign off for the finished product.

To prove the Operations, supply chain and delivery process prior to volume Operations and may include consumer trials and acquisition of long lead time items. NB this is the first time that real final products produced by full volume processes are available for detailed specification and market testing.

Milestone 7: Operations Release

Objective:

To approve volume production, establish delivery infrastructure prior to product launch.

Process 7: Operations

Objective:

To establish full scale Operations and Supply Chain infrastructure to specification.

Milestone 8: Product Fit for Sale Audit

Objective:

To ensure that the product and process criteria have been met, and that improvement actions are identified

To ensure the product and process are ready for launch

To sign off product fit for sale report prior to product launch

Process 8: Product Launch

Objective:

To launch the product and monitor early delivery / market response

Milestone 9: Post sales audit review

Objective:

To check if the product has been launched successfully or not.

Implementation

The following steps are necessary to implement the above process:

1. Form development steering committee
2. Form development wish list (ultimately this will come from the business plan)
3. Establish criteria for prioritising wish list (We use Impact / Ease Analysis)
4. Prioritise the wish list
5. Launch early projects
6. Set up review process (probably monthly initially)
7. Implement the above processes

Operation

The process we have described is an operational process, which needs to operate routinely. For example there should be timetabled meetings of owners, managers, the steering group etc., not just at milestones but also typically a weekly project review meeting, and a monthly steering committee meeting.

All these processes and data need to be owned! (See Previous Best Practice of the Week 001: Ownership)

_____________________________________________________________________

The following further best practice articles connected with new product introduction are available:

The following training courses deal with New Product Development and Introduction:

You may also be interested in the associated courses:

________________________________________________________________________________________________________

Home Page

Ó SM Thacker & Associates Original March 2004 Version 4 February 2008