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.

At TurnTide, we created a product that approached the spam problem in a new way, designed to cooperate with traditional message-by-message spam filters. The Anti-Spam Router used TCP traffic shaping to effectively reach back across the network to the spammers, and limit the rate at which traffic could leave their systems destined for a protected network. The result for customers was great; they had dramatically less spam entering their networks, meaning they saved on infrastructure costs from bandwidth to servers in addition to keeping spam out of the inbox.

The problem we faced was an interesting one… how do we count and report on the traffic that the product keeps out of the network altogether? Traditional spam filters don’t have this problem; they can count and report on all of the messages they receive, process, and mark as spam. We used a few different techniques to report on traffic that was no longer hitting our customers’ networks. We built baseline statistics when the product was initially installed, but before traffic shaping was enabled. We modeled the growth in baseline spam number experienced by the Internet at large. We added a custom reporting engine so that any statistic available to the system could be tracked, measured, compared, graphed and exported.

At the end of the day, these and other features were an effort to make a new kind product report as if it worked like the existing products in the market, since that was how customers had already learned to think about the problem. Since TurnTide really did work very differently from those existing products, reporting using the old metrics was never a perfect fit.

Building innovative products that go after existing markets from a new direction is a good strategy, and its the only way I’d ever want to enter a market as crowded as anti-spam was when we founded TurnTide. Existing markets, however, have established a way of thinking about problems and solutions. The existing vendors have educated the market, defining metrics for success in their own terms based on the structure of their solutions. Products that don’t operate within the expectations set by earlier offerings have some extra work to do; either directly re-educating the market, or trying to fit into the existing metrics until market traction allows for organic change in how people think about the problem. Even with its shortcomings, I’d definitely pick the later approach again.