The product-development process is often seen as an undependable black box” that rarely produces results that exceed business expectations. Traditional financial models have limited success exposing the numerous product-development risks that underlie the assumptions in a typical business case. Applying the same rules to development as they do to research, managers often accept unpredictable performance as normal.
Most companies’ evaluation and approval processes are driven by accounting-based metrics such as discounted cash flow or net present value (NPV) that make understanding the underlying risks of development difficult for decision makers. When risk is discussed in the business case, technology uncertainty is often confused with product-development risk, and the narrative discussion of risk is designed more to persuade than inform. In this environment, decision makers are often hard-pressed to evaluate the potential commercial success of the new-product-development investment.
With an approach called “net present value, risk-adjusted” (NPVR), author Craig R. Davis, CFO of product-development consulting firm Product Genesis, offers an operational framework that gives decision makers quantitative tools to evaluate relative project risks. He shows how these tools can be integrated into existing stage-gate methodologies to create a risk-adjusted NPV that considers the impacts of product portfolio, user needs, and technical and marketing risks. The framework also provides insights into the value of additional research in advance of full commitment to development.
The framework provides a vocabulary appropriate for complex technology products in medical, commercial and industrial products but is easily adapted to the unique terms, methods and measures for each risk-assessment area.
2 Comments On: Calculated Risk: A Framework for Evaluating Product Development
To minimize the risk I am using the 80/20 rule. In a current project (software) I am releasing a minimum feature set. As the audience grows I will add additional useful features. My past observations are that this iterative approach builds customer loyalty.
@JeffreyEvans
I am curious how you decide upon the minimum feature set for your software?
For example, if your software was a project management tool, do you design it for yourself? Or, do you have beta testers to ensure your minimum feature set isn’t *too* minimal?
Btw, I think that your 80/20 approach is especially relevant these days because with so much information out there “less becomes more.”
Have you read the book REWORK by 37 signals?