Product definition is a critical starting point in the development of any new product.

Yet for its

importance, there are a number of common shortcomings to the process of product definition in
many companies:

• No defined product strategy or product plan

• Lack of formal requirements as a basis for initiating product development
• Product requirements developed without true customer input
• A marketing requirement specification (MRS) that is completed late - after development is
underway
• Engineering having little or no involvement in development of MRS, thereby lacking a true
understanding of requirements
• An incomplete, ambiguous, or overly ambitious MRS
• Creeping elegance or a constantly evolving specification that requires increasing
development scope and redesign iteration

A company doesn't blindly respond to customer needs and opportunities. A business strategy
which defines customers and markets to be served, competitors, and competitive strengths
provides a framework from which to evaluate potential opportunities. The result of this evaluation
of opportunities is expressed in a product plan.

Product Planning

The product plan helps resolve issues related the markets, the types of products and the
opportunities that the company will invest in and the resources required to support product
development. More specifically, the product plan is used to:

• Define an overall strategy for products to guide selection of development projects;

• Define target markets, customers, competitive strengths, and a competition strategy (e.g.,
competing head-on or finding a market niche);
• Position planned products relative to competitive products and identify what will
differentiate or distinguish these products from the competition;
• Rationalize these competing development projects and establish priorities for
development projects;
• Provide a high-level schedule of various development projects; and
• Estimate development resources and balance project resource requirements with a
budget in the overall business plan.

Few companies have a formal product planning process, let alone a rigorous process. While a
product plan is generally prepared on an annual basis, it should be reviewed and updated at least
quarterly, if not monthly. Market conditions will change, new product opportunities will be
identified, and new product technology will emerge all causing a potential impact to the product
plan. These opportunities need to be evaluated and the product plan changed if needed. This
changes may result in re-prioritizing development projects or making a decision to hire additional
development personnel to undertake a new development opportunity.

Capturing the Voice of the Customer

Once a product plan is established which defines the target market and customers, the next step
is to plan how to capture these customer's needs for each development project. This includes
determining how to identify target customers, which customers to contact in order to capture there
needs, what mechanisms to use to collect their needs, and a schedule and estimate of resources
to capture the voice of the customer (project plan for product definition phase).
As opportunities are identified, appropriate techniques are used to capture the voice of the
customer. The techniques used will depend on the nature of the customer relationship as
illustrated below.

There is no one monolithic voice of the customer. Customer voices are diverse. In consumer
markets, there are a variety of different needs. Even within one buying unit, there are multiple
customer voices (e.g., children versus parents). This applies to industrial and government
markets as well. There are even multiple customer voices within a single organization: the voice
of the procuring organization, the voice of the user, and the voice of the supporting or
maintenance organization. These diverse voices must be considered, reconciled and balanced to
develop a truly successful product.

Traditionally, Marketing has had responsibility for defining customer needs and product
requirements. This has tended to isolate Engineering and other development personnel from the
customer and from gaining a first hand understanding of customer needs. As a result, customer's
real needs can become somewhat abstract to other development personnel.

Product development personnel need to be directly involved in understanding customer needs.

This may involve visiting or meeting with customers, observing customers using or maintaining
products, participating in focus groups or rotating development personnel through marketing,
sales, or customer support functions. This direct involvement provides a better understanding of
customer needs, the customer environment, and product use; develops greater empathy on the
part of product development personnel, minimizes hidden knowledge, overcomes technical
arrogance, and provides a better perspective for development decisions. These practices have
resulted in fundamental insights such as engineers of highly technical products recognizing the
importance to customers of ease of use and durability rather than the latest technology.

Where a company has a direct relationship with a very small number of customers, it is desirable
to have a customer representative(s) on the product development team. Alternately, mechanisms
such as focus groups should be used where there are a larger number of customers to insure on-
going feedback over the development cycle. Current customers as well as potential customers
should be considered and included. This customer involvement is useful for initially defining
requirements, answering questions and providing input during development, and critiquing a
design or prototype.

During customer discussions, it is essential to identify the basic customer needs. Frequently,
customers will try to express their needs in terms of HOW the need can be satisfied and not in
terms of WHAT the need is. This limits consideration of development alternatives. Development
and marketing personnel should ask WHY until they truly understand what the root need is.
Breakdown general requirements into more specific requirements by probing what is needed.
Challenge, question and clarify requirements until they make sense. Document situations and
circumstances to illustrate a customer need. Address priorities related to each need. Not all
customer needs are equally important. Use ranking and paired comparisons to aid to prioritizing
customer needs. Fundamentally, the objective is to understand how satisfying a particular need
influences the purchase decision.

In addition to obtaining an understanding of customer needs, it is also important to obtain the

customer's perspective on the competition relative to the proposed product. This may require
follow-up contact once the concept for the product is determined or even a prototype is
developed. The question to resolve is: How do competitive products rank against our current or
proposed product or prototype?

Organizing Customer Needs

Once customer needs are gathered, they then have to be organized. The mass of interview
notes, requirements documents, market research, and customer data needs to be distilled into a
handful of statements that express key customer needs. Affinity diagramming is a useful tool to
assist with this effort. Brief statements which capture key customer needs are transcribed onto
cards. A data dictionary which describes these statements of need are prepared to avoid any mis-
interpretation. These cards are organized into logical groupings or related needs. This will make it
easier to identify any redundancy and serves as a basis for organizing the customer needs.

In addition to "stated" or "spoken" customer needs, "unstated" or "unspoken" needs or

opportunities should be identified. Needs that are assumed by customers and, therefore not
verbalized, can be identified through preparation of a function tree. Excitement opportunities (new
capabilities or unspoken needs that will cause customer excitement) are identified through the
voice of the engineer, marketing, or customer support representative. These can also be
identified by observing customers use or maintain products and recognizing opportunities for
improvement.

Comprehensive Specification

These customer needs then have to be translated into a set of product requirements (more
technical expressions of customer needs) that can be acted upon by Engineering. Quality
function deployment (QFD) is an excellent methodology to support this objective while
considering the competitive situation. QFD is a structured planning and decision-making
methodology for capturing customer needs and translating those requirements into product
requirements, part characteristics, process plans and quality/production plans through a series of
matrices.

These product requirements are often expressed in the form of a product specification, functional
specification, or marketing requirements specification. The degree of formality in expressing
these requirements will vary depending on the complexity of the product, the size of the
development project, and the organization structure and its communication requirements. With a
less complex item, the QFD product planning matrix is usually sufficient. With a more complex
item, a larger development project, and critical interfaces between multiple teams responsible for
individual subsystems, the need for a formal specification increases. In addition to performance
requirements and technical characteristics, a comprehensive specification would also address
ease of use; ergonomics; styling and aesthetics; robustness, reliability and servicing; the product
operating environment or conditions of use; life cycle costs; and packaging.

Several issues can arise with a product specification that can delay time-to-market: an
incomplete, ambiguous, or conflicting specification and/or development proceeding prior to
completion of a specification. In these situations, development often proceeds with assumptions
made about requirements that may or may not be valid. If the assumptions are not valid, the
product may be off-target or there may be further product definition and redesign iterations. When
specification ambiguity or conflicts are recognized before design proceeds, there are further
product definition iterations that require additional time before development proceeds. This is the
lesser of the two evils. It is more appropriate to take additional time than risk a product that
misses the mark in meeting customer needs.

However, to the degree that all team members are involved with capturing the voice of the
customer and with translating those needs into technical characteristics or requirements with
QFD, it is less likely that the resulting specifications will be incomplete, ambiguous, or conflicting.
Team members will more readily recognize these situations and recognize the additional
information that must be obtained or the issues that must be resolved much earlier. Further, if
there is a well-defined development process with this team-based environment, it is less likely
that development will proceed until specifications are completed.

Once requirements for a product are defined, they must be managed and kept stable. When
requirements are a moving target, the redesign iterations severely impact time-to-market. To
minimize the impact on time-to-market and more rigorously manage requirements or
specifications, establish realistic requirements at the start and make needed trade-off's. Avoid a
tendency to proceed with the design before requirements are completely defined. Document
requirements to communicate and develop a consistent understanding. Avoid creeping elegance
and carefully consider the need to change requirements after development has started.

Evolutionary Development

The classic approach to product development involves significant effort defining requirements up
front followed by customer evaluation and feedback of prototypes to refine the requirements and
design. An alternative approach of "evolutionary product development" has emerged, largely
based on the results of some Japanese companies. This approach involves regular, on-going
assessment of customer needs and customer feedback, shorter development cycles with a more
limited set of new requirements or capabilities, and planned evolutionary upgrades or
improvements based on customer feedback. This approach is illustrated and contrasted with the
classic approach below.

Summary
In the rush to achieve rapid time-to-market, short-cuts are often taken with the product definition
phase. The result is a product that is off target or additional time spent with subsequent
requirements definition and redesign iteration. To be successful, a comprehensive, well-defined,
continuous process is needed. The starting point is a product plan which defines markets so that
proper customer needs can be captured.

The requirements definition process needs to based on a marketing orientation attuned to the
voice of the customer (demand "pull" rather than product "push") and regular interaction of
development personnel with customers. Further, regular customer input and feedback should be
obtained during development. Customer needs have to be translated into technical requirements
or a specification. QFD is an outstanding mechanism for this purpose while assuring
communication and understanding among the product development team members. If the
product is more complex or the development effort requires more than one team, create a formal
requirements specification. Finally, once requirements are defined, manage requirements to
avoid creeping elegance and time-to-market delays.

Ultimately, this product definition process must enable the enterprise and the product
development team to answer the following question:

• Who is your customer and what is the customer's problem or need?

• How will the product solve the customer's problem/need?
• What advantages does our product offer vs. the competition and what advantages do
competitor's products offer vs. our product?
• What's most important to the customer in making a buying decision?

When these questions are answered and understood by all members of the development team,
the likelihood of a successful development effort significantly increases