What Comes Next

When evaluating new ventures, a lot of energy goes into thinking about the risks involved. I’ve been breaking things down into two major categories, and trying to consider those relatively independently.

The first, execution risk, has been well covered - I especially like this old post from Martin Tobias. In a nutshell, execution risk covers the risk involved with successfully doing those things that are under the company’s direct control. I think many entrepreneurs have a tendency to underestimate execution risk in the same way that drivers who correctly understand the population’s risk of having an auto accident underestimate their personal risk, but that will have to wait for another post.

The second category is what I think of as ‘assumption risk,’ the risk that the world does not actually end up working the way the entrepreneur believes it does. Market risk is one type of assumption risk, but it is by no means the only one.

Since I focus on ventures with a big technology component, I’ve noticed that technical assumption risk is often misclassified as execution risk. This may be due in part to the problem of modeling complex systems - many of the systems we work on are sufficiently complex that it is not feasible to prove the validity of a solution without some measure of real world trial.

The misclassification may also be due in part to the roles in a startup; often, the people thinking about risk in a business planning context are different from those thinking about technical assumptions. When senior management is relatively non-technical, there are a couple of ways to deal with technical risk:

1. Think about all technical risk in terms of “the chance that our technical team will pull this off.” Essentially, this is an intentional classification of all technical risk as execution risk.
2. Work with the technical team to distinguish execution and assumption risks, and plan accordingly

It likely goes without saying that well-run startups choose the 2nd approach.

When we first started building the TurnTide product, we faced plenty of technical risk from both categories. There were a couple of primary assumption risks: how effectively would the application of our traffic shaping techniques to email streams control spam? would good email get through even from nodes that also sent spam?

No amount of modeling or analysis could tell us with absolute certainty what would happen in the real world. The only way to deal with these assumption was to get a beta product deployed in a large, real-world mail stream and test.

There were also execution risks from every direction: would we build a stable network appliance? would the traffic shaping implementation work as designed? would the analysis system accurately determine how much of the network resources to allocate to each sending node?

Execution risk is certainly quite different, in that we know from the outset that a correct solution is possible. We knew that we could do all of these things successfully; in order to mitigate our execution risk we needed to figure out how to maximize the chances that we would do so.

In a sense, the elimination of assumption risk could be considered the creation of value, in the same way that the discovery of mineral deposits would be. The elimination of execution risk, then, is the realization of value - analogous to the process of extracting and refining the buried minerals. Both are clearly necessary, but the require different investments and deliver different returns.

The process for technical startups is nowhere near as linear as I’ve just implied, but since the amount of risk is inversely related to the valuation of a startup company during its various rounds of funding, it seems to be well worth thinking about these issues when planning funding rounds and the progress made between them.