“If you don’t have time to do it right, when will you have time to do it over?”
—John Wooden
Upon exiting the innovation spiral and kicking-off the formal product development process, the immediate first step should be creation of product requirements as a direct translation of the Target Product Profile into specific and measurable design characteristics and performance goals. Note that product requirements and the preliminary verification approach should be established before the development strategy and the main project master plan are finalized. Project requirements define the scope and complexity of the overall product development and inform how many different test methods are needed to verify the final design.
Some of the variable test methods could be unique and require time to develop test fixtures and associated Measurement System Analysis (MSA) for demonstrating a test’s adequate Repeatability and Reproducibility (R&R). Only when the fully defined product requirements and corresponding product verification plan are completed, we would be in a position to inform the confident planning necessary for a committable and predictable product delivery timeline. Product requirements are also associated with business requirements (e.g., target cost, branding, aesthetics, and more). These are inputs and design characteristics not intended to be verified in the same fashion as core performance requirements, especially in regulated industries.
Product requirements are considered one of the most defining success factors for a new product development. The underlying root cause for almost every failed product I have observed in the past 20 years could be traced back to inadequate requirements linked to missing or misinterpreted user needs.
“To be in hell is to drift; to be in heaven is to steer.”
—George Bernard Shaw
Once the product requirements are established, it is time to fully define the development strategy and outline exactly how the product will be developed—the Delivery Game Plan. Because both feasible concepts and product requirements are known at this point, we can be decidedly specific and structure the product development around exact systems, subsystems, and functions with all relevant options, trade-offs, and alternatives. That will also provide critical insights into required capabilities (professional expertise and specialties) and the capacity (number of people) required to get it done right and within the target time frame.
Position of product development strategy on the end-to-end product innovation framework.
If we are developing a complex product consisting of, for example, mechanical, electrical, and software subsystems, it is imperative to apply system engineering considerations. System Engineering relies on an integrated interdisciplinary approach that ensures that all system constituents, when working together, are achieving the intended product purpose and functionality. That is even more important if there is a bigger ecosystem within which this product might operate (e.g., Internet of Things).
Even for simpler products, the system engineering mindset could be valuable. In one example when developing a closed system transfer device for hazardous drugs, the device consisted of two interacting parts, one that attaches to the drug vial and the other to a syringe. It was convenient at the time to assign two available design engineers, one to each subsystem; however, this device’s key close transfer functionality was taking place at the elastomeric interface of the two subsystems when they were connected and fully engaged. Perhaps, a better development approach from the system engineering perspective would be to deploy a critical interface function owner with knowledge of the visco-elastic behavior of elastomers and another design engineer to own the overall device design.
A familiar illustrative example of development strategy applied to a residential house project.
The typical pitfall if you are underestimating the need to explicitly define development strategy is to jump to project planning and resources allocation with a focus on workload distribution among available team members. Even though that creates an illusion of an effective internal resource deployment, it does not necessarily reflect true project needs in terms of the actual required resource capacity and capabilities, which leads to potential slips or delays. The emphasis is on understanding critical design functions, variables, and corresponding governing science in order to define the development approach (experimental, modeling, iterative, internal, external, hybrid, etc.) and the required competencies and specialists.
A clearly defined development strategy that includes “what if” scenarios for contingencies and alternatives is foundational for confident, predictable, and committable project planning.
Editor’s Note: Selected topics from Milan Ivosevic’s book, Eureka to Wealth, will be featured as part of this Innovation Principles series in the following months:
- Introduction (Oct. ’23)
- Entrepreneurial Perspective: Human-Centered Design Entrepreneurship(Nov. ’23)
- Entrepreneurial Perspective: End to End Product Innovation Framework(Dec. ’23)
- Opportunity Incubation: The Innovation Spiral(Jan. ’24)
- Opportunity Incubation: Business Case (Sizing the Opportunity and Go / No Go check) (Feb. ’24)
- Product Delivery: Development Strategy (Mar. ’24)
- Product Delivery: Delivery Effectiveness (Apr. ’24)
