Detrimental Connotations in New Product Development - Product Requirements

The phrase 'product requirements' may have detrimental connotations for some members of a new product development team. Typically, the connotations of the phrase 'product requirements' include the set of associations implied within the prevailing new product development culture. Connotations impact development decisions and priorities. One result of detrimental connotations may be the launch of a problematic product. To some, the phrase 'product requirements' tends to evoke thoughts regarding the selection of product specifications and features.

Requirements trump preferences

The denotation of the term 'requirements' includes words such as obligatory and indispensable. How will individual team members distinguish a requirement from a preference?

Sometimes, preferences about proposed product attributes are presented as if they were product requirements. NPD teams process inputs from many sources to determine what product to build. A few of the declarations I have heard during development include:

• "I am responsible for defining the requirements" - Product Manager
• "I know what customers need" - Product Champion
• "If feature X is included, I guarantee we will exceed our sales quota" - Sales Representative
• "I know and I will decide" - HiPPO (highest paid person's opinion)
• "The product requirements were determined during the Front End of Innovation by an extensive Voice of the Customer (VOC) process" - Technique Expert
• "We need to reach a consensus on the product requirements" - Group Facilitator
• "We must meet this requirement to sell the product in Europe" - Compliance Representative

When product requirements are presented early in the development effort, my evaluation questions may include:

• What are the perspectives of the person presenting these product requirements? Are they likely to have a particular bias?
• Does the data presented justify these choices? Are these inputs valid? Are there other options?
• Are these requirements harmonized with other project constraints?
• Have the appropriate cross-functional issues been resolved?
• Will these requirements be valid one year from now when the product is launched? What may change?
• What is missing?

PDMA's NPD Glossary contains the following insightful definition:

Product Requirements Document: The contract between, at a minimum, marketing and development, describing completely and unambiguously the necessary attributes (functional performance requirements) of the product to be developed, as well as information about how achievement of the attributes will be verified (i.e. through testing).

This definition of the Product Requirements Document contains insights to minimize detrimental connotations. Note the  inclusion of the terms necessary, verified and testing. How are product requirements are validated?

Instead of using the phrase 'product requirements' during the early portion of NPD, consider the impact of using the phrase 'unvalidated inputs.' All inputs can be tested during development but the decisions they impact are validated by results that include a successful launch.

Undisputed product requirements

Because many products are subject to a set of safety or electrical compatibility regulations, a product's compliance requirements are not likely to be subject to much dispute. Factors that determine compliance requirements include the product category and the geographies where the products will be sold.

Other posts in this 10-part Detrimental Connotations in NPD series

Quick Fix, 1/10
Subject Matter Experts, 3/10
Design, 4/10
Designers and Developers, 5/10
Marketing, 6/10
Launch, 7/10
Best Practice, 8/10
I know it when I see it, 9/10
Collaboration, 10/10