Professional Documents
Culture Documents
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:
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.
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.
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.
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.
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:
When these questions are answered and understood by all members of the development team,
the likelihood of a successful development effort significantly increases