Product Definition

Product Definition

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.

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.

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.

About the Author

KENNETH A. CROW is President of DRM Associates His firm focuses on improving product development and the implementation of strategies and practices such as integrated product development, time-to-market, and business process re-engineering for the high technology, capital equipment, medical equipment, transportation equipment, aerospace and defense industries. He is a recognized expert in the field of integrated product development and quality function deployment with over twenty years of experience organizing and guiding product development improvement programs and assisting product development teams. He led a consortium to identify 250 best practices or product development and developed a bench marking and assessment methodology based on these best practices.

He has worked internationally with many Fortune 500 companies. He has written articles and papers, contributed to books, presented at conferences, and conducted workshops in Australia, North America, Europe and Asia on product development, manufacturing, and quality function deployment. He is a founding member and past President of the Society of Concurrent Engineering and is a member of the Product Development Management Association and the Engineering Management Society. He is a certified New Product Development Professional. For further information, contact Ken at DRM Associates, 2613 Via Olivera, Palos Verdes, CA 90274; by phone at (310) 377-5569; by fax at (310) 377-1315 or by email at [email protected].