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 related training and further reading on left

Purpose of the New Product Development and Introduction 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.)

The barriers to sucessful development

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:

New Variants
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 New Product Introduction (NPI) development is the focus of the article.

N.B. A development process success is not only a successful product. 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 and cost 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.

Phase of Product Life Cycle:	Number of your Products
Research (Market and Product)
Development
Pre-operations
Fully operational
Maturity (Sales stable but not growing), (in need of a mid-life kick)
Decline (The slope of the decline graph is not relevant)
Terminal decline (candidates for killing) (See B027 Kill old Products

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 20% in any one 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.

The symptoms of poor development processes

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:

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

Four criteria for passing miestones

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 perceived 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.

Milestone processes

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:

To avoid waste in the development process (The biggest waste is a disastrous project stopped too late).
To provide a technically effective product.
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.)
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 / Mission Creep", 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 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.

Stage	Milestones (Objectives & Pass Criteria)	Followed by a Process
1	1) Approval to do Marketing Investigation	1) Marketing
2	2) Approval to Respond to Marketing	2) Ideas Generation
3	3) Approval to evaluate favoured options	3) Opportunity Evaluation
4	4) Approval for Development	4) Development
5	5) Design Review	5) Process Implementation
6	6) Operations Handover	6) Pre-operational initial delivery
7	7) Operations Release	7) Operations & Priming
8	8) Product Fit for Sale Control	8) Product Launch
9	9) Post sales audit review

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 training 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 and 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 Control (using Product Fit For Sale Checklists)

(See Previous Best Practices: B023 Product Fit for Sale Checklist & B048 Product Fit for Sale Control)

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:

Form development steering committee
Form development wish list (ultimately this will come from the business plan)
Establish criteria for prioritising wish list (We use Impact / Ease Analysis)
Prioritise the wish list
Launch early projects
Set up review process (probably monthly initially)
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 B001: Ownership)

_____________________________________________________________________

Bookmarks for this topic above:

Our full range of training

Relevant Training / Workshops

Relevant Further Reading

Top

To discuss your consulting or training needs with one of our independent consultants or trainers please Contact Us

Whilst great care has been taken to provide relevant, accurate, practical, advice based on our considerable process design and development experience, this will almost certainly require interpretation into the context of your unique business. Please be careful in doing so and if in doubt seek expert advice. We would welcome your feedback!

SM Thacker & Associates

Independent Best Practice Training & Consultancy

Highlights of our full range of training courses / Workshops:

Bookmarks for this topic below:

Relevant Training Course / In-house Workshop Highlights:

Relevant Further Reading: The following further articles were mentioned in this paper: