Long before the successful launch of any new product, a team is assembled to create a working document that captures all of the product’s requirements. This document encapsulates all the customer’s needs and wants into a definitive description of the new product’s capabilities.
Once developed, this becomes the roadmap the design team will follow to ensure that the resulting product matches its intended requirements. Kalypso, an innovation consulting firm, conducted a study of 30 companies across multiple industries and found several common problems that companies face when developing product requirements. These included:
*Viewing product requirements solely as a marketing responsibility
*Jumping too quickly to solutions before fully defining the product
*Changing requirements late in the development cycle
3 ways to improve the development of product requirements
1. Develop product requirements cross-funtionally. Engineers are smart, but they can’t create this type of document in a vacuum. Neither can marketing. Product requirements must balance the needs of customers with technical, market window, schedule, product cost, production and resource considerations. A cross-functional team, including operations, engineering/R&D, quality, and customer support, should work together to evaluate alternatives, prioritize requirements (e.g., must-haves vs. nice-to-haves), and conduct the inevitable trade-offs that come with requirement generation.
2. Avoid the temptation to jump too quickly to solutions. Product requirements focus on the “what” of the development effort. Teams need to avoid the temptation to jump too quickly to the “how” part of the equation. While it is wise to think through alternate design approaches and to conduct proof of concept studies in conjunction with product requirements development, starting detailed design activity before requirements are nailed down can create unnecessary churn and add significant risk and delays to the overall development cycle time.
Well-written requirements clearly differentiates the “what” from the “how” and are clear, concise, complete, and measurable. Avoid vague, subjective, over-generalized, or incomplete statements.
3. Avoid late-stage changes. Nothing brings product development to a screeching halt than late-stage changes to product requirements. With every significant change comes the potential for re-design, re-test, and, in worst case scenarios, re-tooling. That said, sometimes changes cannot be avoided. Changes to product requirements can be driven by a variety of factors, including shifting market conditions, changing customer needs, and unanticipated competitor moves.
Project teams can minimize these late-stage changes with a robust front-end process for validation of market and product requirements, which should include frequent customer interaction, rapid prototype development and test, market and competitor scenario analysis, “should cost” analysis, and the use of tools, such as quality function deployment (QFD), product roadmapping, and conjoint analysis to gain a clear understanding of perceived customer value.
Product requirements development is the central, integrative step that brings together all functions that touch the product development process and, done well, will set the stage for effective full-scale development and in-market success.
