Gated development processes have been around for over 25 years now, and I rarely come across a company these days that does not have some form of a gated process in place. A gate review process, when well implemented, allows leadership to evaluate projects from a business perspective at critical junctures, leaving day-to-day project execution to an accountable project team. Then why are so many of these same companies falling short of their innovation goals?
Kalypso conducted a study of 30 companies across multiple industries and found that, while all claimed to have a gate review process in place, few went very far beyond a list of phase objectives and deliverables. Their project teams lacked sufficient guidance and tools needed to plan, monitor, and successfully execute product development projects. They were missing the “how”. In other words, guidance on what happens “between the gates”.
This viewpoint is the second in a series that explores key steps in the product development process. The focus is on execution with practical tips for project teams.
Product Requirements Development
The primary objective of product requirements development is to translate customer and user wants and needs into a definitive description of new product capabilities. The most effective product requirements describe the product’s functions and attributes using unambiguous language with terminology that is meaningful to the customer or end user. The resulting document is used to guide the development effort and ensures that the resulting product matches the intended requirements.
Three common problems companies face when developing product requirements include:
- 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
Here are some practical tips for project teams who want to improve product requirements development.
Develop Product Requirements Cross-Functionally
While the marketing project team member is responsible for obtaining and synthesizing market, customer, and competitor information, he or she cannot create requirements in a vacuum. Effective product requirements development requires a careful balancing of customer needs against 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.
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”. 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 are stated in a way that clearly differentiates the “what” from the “how”. They are clear, concise, complete, and measurable. They avoid vague, subjective, over-generalized, or incomplete statements (e.g., avoiding words like “similar,” “easy,” “at least,” and “should”). The following is an example that shows the cascade from the customer’s voice to a well-written requirement:
Customer Voice: “I’m very busy. I want to start my patient’s IV and move on…”
User Need: Nurse sets up IV in minimal time
Product Requirement: IV system is set up within 30 seconds of initial interaction
Avoid Late Stage Changes
Nothing slows down product development cycle times more than late-stage changes to product requirements. With every significant change comes the potential for re-design, re-test, and in extreme cases, 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. This 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.