Calculated Risk: A Framework for Evaluating Product Development

Reading Time: 18 min 

Topics

Permissions and PDF

Product development is often viewed as secondary to research, particularly in technology industries. But failing to attribute strategic importance to the product development that commercializes technology investments ignores the fact that successful technology innovation often fails to produce commercially successful products. In fact, it is investment in new-product development that is the single strongest predictor of a company’s future value.1

The product-development process, however, 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. Net present value (NPV) remains the most commonly used decision-making tool in product development, but has been criticized for not properly accounting for uncertainty and project flexibility — that is, multistage development funding and abandonment options.2 Decision trees more accurately capture the multistage nature of development, using probability-based expected monetary values, but can be time-consuming and complex to construct. An emerging alternative to decision trees is real options,3 a technique that applies financial options theory to nonfinancial assets and encourages managers to consider the value of strategic investments in terms of risks that can be held, hedged or transferred. However, the real options technique has yet to be widely implemented for product development, because the ability of public markets to hedge project-specific “private” risks is incomplete and organizational and information hurdles limit adoption. Applying the same rules to development as they do to research, managers often accept unpredictable performance.

However, a robust product-development process can make the inherent risks understandable and to some degree measurable and controllable. Key to this effort are the stage-gate product-development processes in which ideas are evaluated incrementally at successive stages of substantiation. The initial filter or “gate” is the brainstorming stage, during which many ideas are generated, but a good portion is discarded. The next gate is the preliminary scope of the idea in an attempt to match it to existing goals and constraints. Those ideas that “seem reasonable” by those criteria pass through to the third gate, or business case stage, which filters out those ideas not economically viable or strategically valuable. The goal is to kill projects whose economics become negative. Risks are minimized by keeping investments small for projects that ultimately fail to make the grade.

Topics

References

1. R.G. Cooper, “Winning at New Products” (Reading, Massachusetts: Perseus Books, 1993), 6.

2. See K. Vlahos, “Tooling Up for Risky Decisions,” in “Mastering Risk. Vol. 1. Concepts,” ed. J. Pickford (Upper Saddle River, New Jersey: Prentice Hall, 2001), 47–52.

3. See J.J. Reuer and M.J. Leiblein, “Real Options: Let the Buyer Beware,” in “Mastering Risk. Vol. 1. Concepts,” ed. J. Pickford (Upper Saddle River, New Jersey: Prentice Hall, 2001), 79–85.

4. R.A. More and B. Little, “The Application of Discriminant Analysis to the Prediction of Sales Force Uncertainty in New Product Simulations,” Journal of the Operations Research Society 31 (1980): 70–77.

5. E.B. Roberts, “Generating Effective Corporate Innovation,” Technology Review (October–November 1977): 27–33.

6. For a more comprehensive treatment of risk and uncertainty, see P.A. Roussel, K.N. Saad and T.J. Erickson, “Third Generation R&D” (Boston: Harvard Business School Press, 1991), 67–86.

7. Booz Allen & Hamilton, “New Product Management for the 1980s” (New York: Booz Allen & Hamilton, 1982).

8. Cooper, “Winning,” 12.

9. For a complete description of risk quantification at Xerox, see G.C. Hartmann and M.B. Myers, “Technical Risk, Product Specifications, and Market Risk,” in “Taking Technical Risks,” eds. L.M. Branscomb and P.E. Auerswald (Cambridge, Massachusetts: MIT Press, 2001), 30–43.

Reprint #:

4347

More Like This

Add a comment

You must to post a comment.

First time here? Sign up for a free account: Comment on articles and get access to many more articles.

Comments (3)
Josh George
This is amazing. 

Stumbled on this yesterday afternoon, i reread it multiple times, I dreamed about it, I've sketched the models on scrap paper and I've built this in excel. 

This was the best thing I've read in several months. 

I work in GTM Strategy in the IT/Cloud industry. I wonder how relevant the "risk weighting by development category" is?
Jamey K
@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?
Jeffrey Evans
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.