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.

There does seem to be a general upswing in the visibility of math in the commercial world, starting with the extension of the quant revolution in the finance markets to the optimization of a diverse set of industries. The rise in the popularity of poker, and the influx of new players, has led to some new popular interest in math as well - books like The Mathematics of Poker (which I recommend) were hard to imagine on bookstore shelves a few years ago, but have been remarkably successful.

In the world of technology-driven startups, which was the context for Ann’s comment, I draw an imaginary line between two applications of math:

• Creation of a fundamentally new product, business or market
• Optimization of an existing business

The latter of these applications is the one that is driving the quant revolution in finance, poker, and a thousand other areas. In the online world, some big ideas have already broken ground and fundamentally changed the way a number of markets work. The mechanics of business online and the rush to market, however, mean that a lot of the decades of quant optimization in the offline world has been left behind.

I’m pretty excited about the opportunities that come from taking inefficiencies out of businesses that operate at Internet scale, as well as recapturing some of the subtleties of the offline markets. Math is cool again, and some very cool new answers are being created to the age-old question asked of math teachers - “But when will I ever use this?”

‘On behalf of’ logins

LinkedIn and Plaxo are examples of sites doing this to import contact information. In fact, Plaxo makes this functionality available as a service to developers of other applications. Slide, RockYou, Photobucket and a bunch of other widget publishers do this to smooth the process of getting their widgets on users’ pages on MySpace, Bebo, Hi5 and the others. Also, some of the more interesting mashups involve data from the deep web, and require usernames/passwords to get it from 3rd party sites.

API-based authentication

Contrast the ‘on behalf of’ approach with that of Facebook, which exposes APIs providing for access by 3rd party applications, on behalf of users, through a direct authentication by the user to Facebook. As long as the APIs support the access required, this eliminates the need for the 3rd party to collect usernames and passwords.

The fact that MySpace and others don’t have API access (or complete enough APIs) to their sites is what has driven developers to collect credentials and act on behalf of users.

Some sites actually have APIs but don’t take advantage of the fact that they could use them to tighten up security. While Salesforce could use the Facebook-style authentication for 3rd party apps, they instead have those apps solicit and store user credentials (by policy, they allow only “certified” apps to do so).

Why are ‘on behalf of’ logins a problem?

If the 3rd party site is deserving of users’ trust, and everything works properly, there should be nothing wrong with these logins. We don’t worry much about local applications doing this type of thing: blog editors, web design programs, browsers and countless other local apps all store user credentials for 3rd party apps and sites. In fact, this type of login is enabling startups to drive innovation in the new social network ecosystem; if they had to wait for the MySpaces of the world to publish APIs or enable new functionality, these companies would be dead in the water.

In reality, there are some real problems to think about. In addition to a couple of shared issues, the key differences from local applications are also the problems here:

• Trust of the application and vendor - an issue with both web and local applications. The decentralized and volatile nature of web applications, and the lack of user-centric security infrastructure (such as local anti-virus and anti-malware software), make this a tough problem for web applications.
• Authorization of the specific actions that apps take on behalf of their users - an issue with both web and local applications; if this is done really well, the problem of trust of the app and vendor is diminished.
• Location of user credentials - in web applications, these credentials live ‘in the cloud’ somewhere. The vendor claims and reality of the security of those credentials are at best hard to verify.
• Scale - the barriers of installing, and updating, local software limit the scale of this problem in that world. Web applications are easy to sign up for and can be updated multiple times a day, leading to a lot of complexity in managing overall user security.

It looks like a solution probably starts with a way to give users centralized control and management of:

• Authentication credentials
• Authorization of ‘on behalf of’ logins
• Authorization of specific ‘on behalf of’ actions

What about OpenID?

OpenID is a framework for decentralized identity. It supports decentralized authentication and structured sharing of personal information.

‘Decentralized’ in OpenID terms means decentralized from the perspective of web applications; this can in fact mean centralized from the user’s perspective. OpenID could be used to do logins on behalf of users without the collection of credentials, but it does not address the problem of authorization of those ‘on behalf of’ actions. The structured sharing of personal information involves a narrow kind of authorization, but too limited to solve this problem.

The transparency of ‘on behalf of’ action is itself a pretty complex problem - it requires giving the user a way to see and understand what the 3rd party app will go and do for them on the other site. I’m not sure whether this is a problem OpenID is interested in tackling. If it develops momentum as an identity standard, it would certainly be nice to see it go beyond authentication and identity to a more complete view of security (something Microsoft’s virtually dead Passport initiative and the Liberty Alliance project both failed to do).

Small buyers of technology, acting early in the technology adoption life-cycle, are motivated by hope (hope == ROI, opportunity, etc). Large buyers of technology, acting late in the life-cycle, are motivated by fear (fear == risk of loss or punishment).

A good example of this can be found in the typical upgrade cycle. Early, individuals and small groups upgrade to new hardware, operating systems and applications because they hope that access to new features and capabilities will be more than worth the effort and disruption of the upgrade. Large groups don’t upgrade until much later, even if the benefits of doing so are dramatic; they often wait until the fear of loss of support from vendors forces a transition.

I remember experiencing this dichotomy in the major changes to the practice of information security as the commercial Internet grew in the mid 1990’s. Security shifted from an operational part of IT, where purchases were motivated by fear of loss rather than ROI, to a source of enabling technology for new ways of doing business. Within startups and large existing enterprise, small teams tried to figure out how to build online businesses. Along the way, they pushed the nascent Internet security product companies into building the right pieces to enable and protect the new ecommerce ventures.

Today, it seems like information security has largely returned to the operational state: anti-malware technology is a cost of doing business online, regulatory requirements drive new security spending, and fear of public outcry and regulatory enforcement prompts increased scrutiny on the handling of customer data.

It is likely that large organizations will miss much of the benefit of web 2.0 technologies as well, as they wait for incumbent software vendors to deliver later in the adoption cycle, when they will buy out of fear of being left behind by competitors. Most of the startup companies I see trying to sell innovative technologies into the enterprise today through the IT organization haven’t really figured this out.

A few companies, however, are dealing with this really well. Most are SaaS plays, and Salesforce is among the first of the good examples. Salesforce established small, dedicated groups of customers who bought the service with company credit cards rather than purchase orders, and used it without the authorization of central IT. Companies like 37 Signals, Zoho, ConceptShare, and countless others are using roughly the same model.

Going back to the idea of hope vs. fear in the acquisition of technology, I think there are a few things these startups could be doing differently to scale sales to big organizations.

Enterprise Freemium

The freemium pricing plans offered by the three startups I mentioned above are structured in a way that makes sense for small teams, but breaks for very large ones. They all offer some kind of free trial, and then price their services based on the amount of use (number of users, amount of storage, etc). Within a large company, this means that a small number of initial users can evaluate the product, and probably pay for ongoing use on a credit card, but growth becomes more difficult at that point. After the trial period, new users typically can’t be added without moving up to a pricing plan that supports them. The team footing the bill, however, is only willing and able to pay for its own use, not the much higher prices that come with larger plans.

I think there could be an enterprise twist on the freemium model, with the following characteristics:

• Free trial for each additional user within a company
• Easy options for billing/payment by user or group, rather than for the whole company
• Premium options for IT

The last of these, ‘Premium options for IT,’ is the most important. Knowing that IT won’t make early technology buys to support their users’ hopes for opportunity and improvement, the startup should support broad grassroots adoption of their products at lower levels. When the motivators that drive IT purchasing, such as fear of losing central control over data, backups, users, access control, and management complexity, kick in due to the grassroots use, the startup needs to be there to directly support IT with purchase options.

For a SaaS product, these IT premiums might be things like onsite, appliance-based offerings of:

• Directory services integration for user accounts
• Enterprise backup integration
• Data integration with reporting, dashboard, data warehouse and other systems

There are plenty of examples of enterprise IT banning the emerging technologies that come onto their radar when they don’t have a way to mitigate their fears. The best way I can think of for the startup to deal with this is not the traditional attempt to convince IT that their fears are unfounded, but rather giving IT a way to purchase that mitigation in the way they are used to and comfortable with.

This isn’t a big shift for most startups. The model still provides early revenue and a short sales process, but also offers a level of scale previously available only to those selling to a central organization. From a product perspective, this approach requires some thinking about the needs of IT and perhaps some new development; chances are that the thinking and planning will have benefits for internal SaaS operations if done early, and the development can be done at the right time to fit in with the adoption and growth of the product. If startups continue to deliver these innovative SaaS products with direct application in the enterprise, there may even be a Feedburner or Mashery model here: a company could focus on providing the IT premium layer for SaaS offerings.

As promised, here are the slides from today’s presentation. We talked so much about each point that I’m not sure how much value these have to folks who weren’t in the room… maybe we can get the organizers to do audio or video next time.

Whether building a new company from scratch, or keeping a big company competitive, emerging technologies have changed the rules. Open source software, web services, mashups, AJAX, Ruby, Rails, and RSS… only a few of a seemingly endless list of technologies that have redefined what is possible for small teams. This talk will focus on startup experiences, lessons learned about technology choices and tradeoffs, and on building, funding and running a technology startup in the new environment.

The Emerging Technologies for the Enterprise folks are also putting on a pre-conference breakfast for CxO’s and executives on the 15th. I’ll be the keynote speaker for that event, talking about Tiger Team Innovation:

Startup companies use small teams beginning with a blank slate and the latest emerging technologies to build incredible value overnight. This talk will focus on using the same techniques, with a few twists, to deliver measurable value to the enterprise in new ways.

The main conference is open to everyone and seems to be quite reasonably priced compared to most such events; registration is here. I believe the breakfast is by invitation, so if you’d like to attend leave a comment or send me email and I’ll ask the organizers to include you.

Looking at the technically innovative startup pitches I’ve heard from this perspective, I can break them down into two basic categories.

Horse before the cart: we have built this really incredible technology. Here’s what it is and how it works. Take a look at our demo, which proves that we have built this technology. Here’s a list of amazing things we can do better with this new technology.

Cart before the horse: we are doing this amazing thing. it wasn’t possible before, and doing this thing enables an awesome new business. Take a look at our demo, which proves that are doing this amazing thing. It works because of this really incredible technology we have built.

Yahoo, and other big companies, can afford to occasionally build and launch a new horse without putting a clear, focused application of the technology out in front. In fact, doing so can help them maintain their influence and claim leadership in new areas. Some successful startup companies have built technology first without a narrow application guiding the business, but I’d argue that these are the exception rather than the rule.

From the founder perspective, I think that focusing on a technology, however cool, can lead to some problems. When the technology comes first in my thinking, I can fall into a trap of not diligently evaluating even one of the many potential market opportunities. Focusing on one little application of the cool new technology means thinking about things like who, exactly, will buy it… what will they pay for it… how will they use it… how will it change their lives. Cool technology is really exciting to a few people, but the thing it does is what makes it exciting to lots of people.

Looking at companies from the outside, as an investor or otherwise, I find the technology/application focus question to be even more important. Founders may have a grand vision for an eventual application of the technology, but if they are focused on building a business around a focused, narrow application first then they will make better decisions about how much money to raise, how much to build before launching, and how to measure success. The focus on an initial application makes business decisions, external and internal, quite a bit easier. It also turns the technology into a key asset and competitive advantage, rather than the company’s raison d’être.

Funding or starting this type of company means that the initial, focused application stands on its own as a business that should be built. If that business is successful, the company can leverage its technology assets in tackling larger opportunities.

So, next time you are trying to convince a VC about the merits of your firm, show them how they can make 10x capital on a realistic exit scenario (not how to get a 40% IRR).

reminds me of the importance of the differences in risk model between VCs and entrepreneurs, something I’m going to explore a bit here. One example of a VC model is described in the post, so I’ll use those numbers for the comparison.

Bases loaded

The VC risk model is based on a portfolio of investments, and the VC should choose each investment on the basis that a 40% risk of negative return is justified by a 10% chance of 10x+ return and a 50% chance of a zero to 5x return. This model, along with its countless variations, is designed to accomodate the high risk of failure of startup companies. VC Confidential has this to say on the subject:

In the early stage world, if you target, say a 40% IRR, through assuming a number of 5x wins in a compressed period of time, you will likely be out of the business. Your 5x wins, while possibly generating high IRR’s, don’t return enough multiple to pay for the 4 tube shots and 2 break-even deals.

So, VC-funded startups fail at a high enough rate that the target outcome for each investment needs to be a 10x return in order to pay for the investments necessary to deliver that one return with confidence. In fact, even a high confidence investment in a company targeting a 5x return is a hedge: overall, it decreases the chances of a very low rate of return for the fund but also decreases the chances of an on-target rate of return.

To stick with my tenuous baseball analogy, as a VC you start with no outs and no strikes, so while each swing is unlikely to yield a home run, over all of the swings you will probably have at least one. Also, you only swing for the fences with runners on base, because the value of a successful home run needs to more than cover the outs and strikes used.

Two outs, two strikes

Unlike the VC, the entrepreneur runs one company at a time. This means that the entrepreneur can’t use the same risk model to achieve a high confidence level in a given rate of return. All other things being equal, the entrepreneur can’t target the 10x return desired by the VC risk model without having a lower confidence in the outcome.

From this, it seems like the entrepreneur is incented to target lower returns in order to achieve a higher confidence. Of course, entrepreneurs have a much larger range in their tolerance of risk than VCs. Some entrepreneurs will target a 100x return with a small chance of success, while those at the other end of the spectrum are happy to run lifestyle businesses.

Focusing on businesses that need institutional funding, how does the entrepreneur, with only one swing at the ball, manage risk and still target a return that works in the VC model? One approach is to look for businesses that have a real swing at the fences, but can be turned into triples or doubles along the way. Not every business can work this way: many startups are based on predictions about the future and won’t have exit opportunities until the core assumptions or predictions are validated; at the other end of the spectrum many are really trying for a single or double and could get very lucky with a triple. The ideal situation for this approach, which involves a real risk/reward decision between exit and growth at each stage of funding, doesn’t come along very often.

Wins vs. RBI’s

If a company has the opportunity to decide between exit and growth, the alignment of risk models comes to the center of attention. There has been a lot of discussion lately about founder liquidity as a means for aligning incentives between VCs and entrepreneurs, but in the context of this post, founder liquidity is a mechanism for aligning the risk models by hedging the founders’ risk at the expense of upside.

I think there is value in looking for companies that have a swing at the fences, but can be turned into triples or doubles. Hopefully, recognizing that as a target will help in choosing, and running, businesses that have a real addressable market from the start, can divide market risk over time while decreasing execution risk, and are able to validate their assumptions and predictions early. When it comes to decisions on exit vs. growth, the combination of discount/premium of the exit and alignment of risk models will come into play. Even if those decisions all favor growth, it seems to me that managing toward exit opportunities makes as much sense as managing every startup toward eventual IPO.

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.