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.
I spent a long time in 2003/2004 working on an expected utility model to back up Value Centered Design so that it’s more than a venn diagram that puts business and user needs on the same playing field (that’s useful, but a valuation model adds a lot more).
The challenge I ran into was that it doesn’t suit work without clear precedents…you have to have experience doing something similar to make a decent assumption about both the assumed rewards and probabilities.
For work that pushes the boundaries, a utility model like Real Options gets pretty fuzzy. At the same time, it’s better than “i dunno” :)
RE>it doesnâ€™t suit work without clear precedents
Great point, and a fourth reason I should add. If you’re doing anything novel that could be innovative, you can’t value it accurately.
And I think that’s yet another reason why Real Options works well, it acknowledges an uncertain world and let’s you gradually unleash your investment as you learn how that new thing actually is working.
I think you’re right – and with real options, successive approximation is a better approach for valuation than expecting to get it nailed from the start. So you revise your valuation assumptions along with product/service/concept iteration.
great post! this is a tricky, but very important topic for design.
for me, a payoff table is an easier way of visualizing this than a decision tree, but different strokes for different folks (example).