The relative non-risk of startups

Based on recent events I suspect an investment axiom might exist that says: The further an investor is abstracted away from the underlying asset they’re investing in, the greater the risk.

This has been shown recently to be true with Mortgage backed securities, credit default swaps, the black box that is the hedge fund industry and even sovereign debt may qualify.

When you are shielded from your investment by layers of structure, marketing, repackaging and sales teams, you are too far away to hear the alarm bells when they’re ringing.

That got me thinking about the relative risk of being an angel investor in young companies. Angel investors meet with the founders, use the product and in many cases craft the investment terms themselves. Spending a few weeks negotiating a deal with an entrepreneur is itself a revealing process. The investor is exposed to a mountain of data on the underlying asset they’re investing in.

The recent excellent Bloomberg article on the under performance of commodity ETF’s brought this difference home for me. Suited and booted bankers sell commodity ETF’s daily with a prospectus that tells you you’re investing in gold or oil or copper. The impression created is that you’re investing in the underlying asset when in fact you’re investing in a fund that is trading monthly futures contracts for the commodity. Two years later you’re left wondering why your investment has lost 20% while the underlying commodity has gained.

The complexity of financial products and the distance between the average investor and the underlying assets they’re investing in has, I believe, peaked. As the financial crisis that was started in 2008 continues to play out, during next decade I strongly suspect there will be a return to less complexity and a desire to know, touch and meet with the assets that underlie each investment.

While the likelihood of failure in young businesses is high, as an angel investor you know exactly what you’re getting and you have the ability to influence the performance of your asset. Try finding that on Wall Street.

Are you building an R&D lab or a business

Take Twitter in a parallel universe. The team builds a great useful and viral product. They start growing like crazy and hit their first million members. The growth machine keeps pumping and everyone is watching the hot Alexa and Compete graphs cranking away.

They start getting their first acquisition offers. But the smart folks know the second differential of their graphs is still wildly positive (it’s curving up). They decide to hold off on a sale because they figure that even though they have to raise another round to buy infrastructure, their equity will still be worth more net net.

They keep growing and that second differential gets a little smaller as the curve starts flattening out into a line. Then right before the line turns into the other half of an S they hire Allen and Company, line up all the acquirors and sell for $3Bn to Google.

What just happened is a kick ass group of product guys teamed up with a kick ass group of financiers to create an R&D lab. The lab came up with a hit product and was acquired. Make no mistake, this is a very very good thing! In this parallel universe the amazing product that is Twitter is combined with a company with the business infrastructure and knowledge to turn it into a money printing machine. That creates jobs, brings foreign currency back into the US through exported services and of course the wealth creation event for the founders has a trickle-down effect if you’re a fan of supply side economics.

Now lets step back into our Universe (capital U because I don’t really believe in this parallel universe stuff). Another group of kick-ass product guys called Larry and Sergei teamed up with a group of kick-ass financiers called Sequoia in 1999. A guy called Eric Schmidt who is a battle hardened CEO from a profit making company that got their ass handed to them by Microsoft joins the party.

In 2000 Google launched AdWords and the rest is business model history. A history that you will never hear because once the company started printing money they went dark. There are tales of Bill Gross having invented AdWords, legal action, a possible out of court settlement – but no one will ever know the full details of these early days and we have almost zero visibility into the later story of how Google turned that product into a money printing business.

The stories of successful transitions from product to business are never told. Even if they were they would bore most of us  because they are not fun garage-to-zillionare stories. They are stories where the star actors are cash-flow plans, old guys with experience and teams of suit-wearing sales people.

The thing that attracts most geeks (also called Product Guys) to startups is the garage to zillionare story through an exit. And that’s OK provided you get your head screwed on straight and understand that you are an R&D lab who’s goal is to get acquired. So go and make yourself a credible threat. Make yourself strategically interesting. Go and build the kinds of relationships that demonstrate your worth to potential acquirors, get them addicted to your data and result in an exit.

[Quick aside: I spent the day skiing a while back with a great guy who heads up a certain lab at Stanford. They came up with an amazing product that you now use every day. They teamed up with an A list VC with the specific intent of selling to Google. That’s exactly what they did and it has improved our lives and Google’s business model. So again, the R&D lab approach is very very OK.]

The other smaller group of founders are business geeks. I’m friends with a handful of company founders and CEO’s in Seattle who absolutely personify this group. Everyone of them was a VP in a larger company. They all have MBA’s from top schools. And every one of them is focused on generating cash in their business. The road they’ve chosen is a longer, harder road with a lower chance of success but a much higher reward (think Michael Dell, Bill Gates, Larry Ellison) if they succeed.

Both paths are morally and strategically OK. You just need to know which you’re on and make sure your investors and the rest of the team are using the same playbook.

temet nosce (“thine own self thou must know”)

Bandwidth providers: Please follow Google’s lead in helping startups, the environment and yourselves

There’s a post on Hacker News today pointing to a few open source javascript libraries that Google is hosting on their content distribution network. ScriptSrc.net has a great UI that gives you an easy way to link to the libs from your web pages. Developers and companies can link to these scripts from their own websites and gain the following benefits:

  • Your visitor may have already cached the script on another website so your page will load faster
  • The script is hosted on a different domain which allows your browser to create more concurrent connections while fetching your content – another speed increase.
  • It saves you the bandwidth of having to serve that content up yourself which can result in massive cost savings if you’re a high traffic site.
  • Just like your visitor already cached the content, their workstation or local DNS server may also have the CDN’s IP address cached which further speeds load time.

While providing a service like this does cost Google or the providing company more in hosting, it provides an overall efficiency gain. Less bandwidth and CPU is used on the Web as a whole by Google providing this service. That means less cooling is required in data centers, less networking hardware needs to be manufactured to support the traffic on the web and so on.

The environment benefits as a whole by Google or another large provider hosting these frequently loaded scripts for us.

The savings are passed on to lone developers and startups who are using the scripts. For smaller companies who are trying to minimize costs while dealing with massive growth this can result in a huge cost savings that helps them to continue to innovate.

The savings are also passed on to bandwidth providers like NTT, AT&T, Comcast, Time Warner, Qwest and other bandwidth providers who’s customers consume less bandwidth as a result.

So my suggestion is that Google and bandwidth providers collaborate to come up with a package of the most used open source components online and keep the list up to date. Then provide local mirrors of each of these packages with a fallback mechanism if the package isn’t available. Google should define an IP address similar to their easy to remember DNS ip address 8.8.8.8 that hosts these scripts. Participating ISP’s route traffic destined for that IP address to a local mirror using a system similar to IP Anycast. An alternative URL is provided via a query string. e.g.

http://9.9.9.9/js/prototype.1.5.0.js?fallback=http://mysite.com/myjs/myprototype.1.5.0.js

If the local ISP isn’t participating the request is simply routed to Google’s 9.9.9.9 server as per normal.

If the local ISP (or Google) doesn’t have a copy of the script in their mirror it just returns a 302 redirect to the fallback URL which the webmaster has provided and which usually points to the webmaster’s own site. A mechanism for multiple fallbacks can easily be created e.g. fallback1, fallback2, etc.

Common scripts, icon libraries and flash components can be hosted this way. There may even be scenarios where a company (like Google) is used by such a large percentage of the Net population that it makes sense to put them on the 9.9.9.9 mirror system so that local bandwidth providers can serve up commonly used components rather than have to fetch them from via their upstream providers. Google’s logo for example.