The common way that financial people will judge the potential value of a project, or a design concept representing a potential future concept, is by building a model, usually a discounted cash flow model like Net Present Value (NPV). The calculation essentially asks, if we do this project and gain the profit we think we’ll gain, how much is it worth to us right now? That way we can compare it against our other options.
The problem with these models is that they assume the world doesn’t change. The model tries to predict everything that will happen in the project from beginning to end in order to arrive at a single numerical value. But in the technology world, there’s lots of change.
So peeps at the forward edge of product and service development have started using real options to value projects. Real options essentially breaks the project down into a series of decisions. At each decision point a number of outcomes can occur, and for each outcome there’s a probability it will occur. There’s also a revenue associated with each outcome that we receive if it occurs. By multiplying the probability by the revenue we get the value of the option.
This is often illustrated using a decision tree, as with this analysis of a drug in clinical trials…
What’s the big deal? It turns out this is a better way to value investments in Internet services for at least three reasons I can think of off-hand…
- Versioning: The Web 2.0 way of doing things is to release our work in stages, the public beta being a perfect example. If the beta is a big fail, we stop there and cut our losses, or we go down a different path of the decision tree.
- Uncertainty: There’s a great deal of uncertainty in our work. Twitter, for example, is a big success, but at the cost of a very tricky technical challenge. Instead of an NPV model that would judge the value of the project to be either simply negative or positive, we can model this reality of “large audience / technologically expensive.”
- Fast Risk Management: The ease of building betas makes it tempting to skip a big financial modeling activity, especially if it can’t accurately reflect (i.e. predict) how customers will react. Creating at least a simple real options analysis can save a lot of investment before building a beta that is hard to emotionally trash once it’s built. And while it’s tempting to say predictions are impossible so we should just run a trial, few managers with any P&L responsibility will invest in that.
Real options isn’t a perfect technique, however. Proponents claim it supports decisions with “mathematical certainty,” but the probabilities are derived from managers’ experience and judgment which is subjective and imperfect. Getting a group of people to agree on the probabilities may be difficult, and once a project is up and running a team may be unwilling to revise their estimates downward to reflect new information, much less kill their own project. Still, for the kind of work we do it’s better than the old ways.