Google, Facebook Connect and the New Old Generation of Web Apps

Many web brands from Bessemer’s portfolio companies Yelp and LinkedIn, to up and coming companies like Milo and Fixya, have built their brands by acquiring a large percentage of traffic for free thanks to high and broad organic ranking in Google. Now, whereas the first generation of web 2.0 apps relied on Google for user traffic, a new generation of web apps is emerging that leverage Facebook Connect and Twitter’s “sign in with Twitter” to provide a large percentage of the initial user experience. Though this shift is in its early infancy, I believe increasingly we will come to expect our social graph to be embedded in our web apps. Those that resist this shift may risk being left behind.

To understand the implications of this shift, it helps to look at Google. There are two parallels worth making:

1. Many companies that existed pre-Google did not adjust to a Google world fast enough. The Yellow Pages has become a classic example of this. Web savvy startups like Bessemer's own Yelp and Yodle took advantage of the new Google paradigm and in doing so, have been able to eat Yellow Page's lunch.
2. In the beginning of most web company’s lifecycle, the company’s ranking in Google’s organic results is a key component of the company’s visitor acquisition strategy. For example, take Milo. For those who don’t know Milo, Milo “searches the shelves of your local stores in real-time to find the best price and availability for the products you want to have - right now.” According to Compete, it is growing like a weed and 71% of its traffic comes from Google (likely people entering a product+location search query). Eventually, if Milo is able to build a product that gets users coming back to the site, it will start to build a brand and get direct type-in traffic; with this, its reliance on Google for free traffic will decrease and a lot of the existential risk of the company will be behind it. In the meantime, Milo is largely reliant on Google and at the mercy of the algorithm gods.

Facebook has also been a platform on which applications rely for traffic. In the first generation of applications, it was the Slide’s and RockYou’s of the world. These companies were built to exist entirely within Facebook’s closed platform and they had even more existential risk than companies that rely on Google; when Facebook completed its redesign, many were all but wiped out. But some, like Zynga and Playfish, survived and thrived. Unlike Slide and RockYou which were largely Facebook profile add-ons, Zynga and Playfish were about games that leveraged the Facebook social graph. In a way, Zynga and Playfish are a hybrid between the first generation of Facebook apps, and what I'll call the second generation. These are the apps that are beginning to crop up outside of Facebook (not unlike Zynga's farmville.com) but leverage Facebook Connect to create a large part of the initial user experience.

Companies like Plancast and TheHotlist are thought provoking examples of this. But now, rather than risk having a majority of their traffic come from a single source (although that may still be the case), they risk having a majority of their user experience come from a single source. Is this as dangerous? It's unclear to me. Companies that effectively leverage Facebook Connect should end up going through the same process that I described Milo as going through. Eventually, I would think TheHotlists of this world will have only a small part of the user experience coming from Facebook's rich data.

This is obviously an exciting shift and I believe parallels the early stages of Google. Companies like the Yellow Pages did not adjust to a Google world fast enough, and were left behind by web savvy startups like Yelp and Yodle. Facebook Connect is going to create a new generation of apps, and by doing so, create a new old generation of apps that didn't jump onto the social graph bandwagon fast enough.

Random Thought: Venture Capital's Freemium Model

Recently, Bessemer published an update to our well known “Ten Rules to Being SaaSy” (this time entitled, “Bessemer’s Top 10 Laws of Cloud Computing and SaaS"). If you haven’t already read it, check it out. It's really a great read.

I sent the white paper to an early stage SaaS portfolio company of ours that I work with, and laughed when I got the following response: “This is great. Why are you giving away all the secrets?!”

My answer: It's our freemium model (or rather, venture capital's freemium model). The difference is, we’re trying to give you a taste of what we've got so you take some of our money.

Don't you think that fits? All our VC blogs and tweets are the 2.5GB equivalent of Dropbox. Fred Wilson is our Marc Benioff (disrupter of software, although if you know who pioneered the freemium model in software, that might be a more fitting comparison).

I suppose that means this blog (and my tweets) are my freemium product; I've been lucky to meet a lot of great entrepreneurs and members of the tech community through conversations that have jumped from my (poorly implemented) comments section to a phone call or meeting. (Though what might have started as a freemium product has become personally fulfilling; I'd do it regardless of whether or not it translated into "vc leadgen.")

Overall, a very positive evolution to an industry with a closed and clubby legacy. And of course, if you like what I'm offering, drop me a line! I'll gladly give you the 10GB upgrade for free. :)

Measuring churn for recurring revenue businesses

For any recurring revenue company, churn is almost always one of the key metrics the company (and their board) tracks. Why work hard to get new customers if you can’t keep the ones you’ve got? Moreover, low churn means you have a stronger recurring revenue base and therefore more money to spend acquiring new customers. Thus, having low churn creates a virtuous cycle for the company in more ways than one.

While churn may seem like a straight forward concept, I’ve found that recurring revenue companies often only measure monthly or annual churn in terms of customer count. While this is certainly an important measure, I’m not a fan of measuring churn just on a customer basis for the simple reason that not all customers are created equal. To take an extreme example, imagine an early stage company doing $200k in Monthly Recurring Revenue (MRR) with 200 customers ($1k MRR ASP). If the company had one flagship customer that was actually generating $5k in MRR and that customer churned, that does a lot more damage to the company than the .5% monthly customer churn would indicate.

Analyzing churn on a MRR basis lets you see other gradients as well. Notably, the recurring revenue base you have from one customer might grow or shrink over time, even if the customer never churns. If on average you lose more MRR on a monthly basis due to your existing customers downgrading their contract than you gain from your existing customer base upgrading their contract, your business would be bleeding recurring revenue and your customer churn number would be silent on the subject. It's difficult to fix what you don't track.

Measuring MRR churn can have some surprising insights too. What we’ve found is that while companies might target 10% customer number churn, those companies might have negative churn from a MRR basis. This means that on average, the company is adding MRR from their existing customer base above and beyond what they lose from customers churning or downgrading. For those companies, it’s worthwhile to try to look at which customers are churning early in their contracts and which customers are expanding their recurring revenue base; you may notice some patterns. For example, there might be some marketing activities that are picking up more of the former which you can eschew in favor of those that attract more of the latter.

You can read more about recurring revenue metrics on Bessemer's website at www.bvp.com/SaaS.

What Twitter has meant for FourSquare, and what I think Twitter should learn from Four$quare

That FourSquare has benefited tremendously from Twitter is obvious. I can’t sign into my twitter account without finding out so-and-so got some badge or became the mayor of some place. In fact, I first learned of FourSquare thanks to Twitter and to seeing these announcements, and I would be willing to bet that a huge majority of FourSquare’s current users also found out about FourSquare thanks to Twitter.

Sites like Twitter and Facebook are fantastic word of mouth conduits. Whereas FourSquare once would have had to grow by asking users to email their friends and sign up, Twitter provides a means of having friends do the equivalent of passively inviting their friends over and over again. Repeatedly. Consistently. FourSquare's effective leveraging of Twitter is part of its brilliance.

It reminds me of a famous Mary Meeker chart which I can’t find on Google so I’m recreating here:

Thanks to the Twitter and Facebooks of the world, web apps will be able to grow even faster than they once were. The growth of web apps in general will become increasingly dynamic – both in terms of picking up early momentum and growing much faster than previously, but also fizzling out (like oh so many facebook applications). While I don’t think there will be a higher frequency of 50m-user applications, I believe there will be a higher frequency of 1m-user apps than ever before.

But the natural evolution of this is that Twitter will be increasingly abused by new web apps hoping to leverage Twitter’s effortless word-of-mouth. There is no mechanism in Twitter that I know of to limit what I’ll call web app Twitter “spitter”, and so there is no reason for web app companies not to push their app-specific messages to Twitter. And while conceivably there should be a natural mechanism of Tweeters not wanting to annoy their followers by allowing too much “spitter”, that mechanism is just not that efficient. I’m willing to put up with my friends’ spitter in much the same way that you put up with a friend’s occasional bad jokes or body sounds. But that’s not to say that spitter doesn’t degrade my experience on Twitter. As more applications look to FourSquare as an example of how to leverage Twitter, Twitter is going to increasingly become a jungle of 3rd party tweets.

That’s why I wonder how Twitter, with all its open API principles, will manage this inevitability. The one idea I have is for Twitter to actually charge applications a small amount for each “push” to Twitter, much like an email marketing company charges per email delivery. This will force developers to limit their use of Twitter, and therefore create a better Twitter user experience.

What do you think?

"Installed applications are going away in five years"?

Recently, I got into a heated argument with someone at a cloud computing-related meeting where a person I was speaking to swore up and down that within five years people would no longer install applications besides their browser.

I swore up and down that that’s not happening any time soon in mainstream USA.

I may feel like a dummy in five years, but I have to say, I recently received a new PC and I’m amazed by how many applications I’ve installed so far (not including what was pre-installed on my computer -- thank you HP bloatware!).

My list so far (day #2 of computer):

1. Adobe Reader
2. Bunch of browser plug ins (Java, etc)
3. Canon Utilities (actually five installs for this)
4. Citrix Metaframe
5. Dropbox
6. Evernote
7. Firefox
8. Google Chrome
9. IE (not by choice)
10. iTunes
11. Microsoft Office
12. Mozy
13. Norton Antivirus (came for free w/ my PC, otherwise I would have installed AVG)
14. Picasa
15. Skype
16. TweetDeck

So what do you think? Are installed apps going away within five years?

My "ista" take on Larry Cheng's VC Blog Ranking

Larry Cheng updated his popular VC Blog Ranking and included some fun analysis, particularly on how Fred Wilson continues to lead the VC blogging show. If you haven't already, take a look.

Because I initially started my blog with the intention of blogging from the perspective of a female, junior professional (hence the “ista” in Adventurista), I’ve created two sub-sets of Larry’s: 1) Junior (i.e. non-dealmaker) professionals and 2) females.

#dos is pretty straight forward, but I might need some user generated editing for #uno. My rule of thumb was that if a person didn’t have the words “Partner” or “Managing” in their LinkedIn or website bio, I included them in my junior professional list. I'll admit some are on this list by a hair, but they make the rest of us look good!

Junior Professionals (woot woot!)
1. Christine Herron, First Round Capital, Christine.net (354)
2. Philippe Botteri, Bessemer Venture Partners, Cracking the Code (263)
3. Andrew Parker, Union Square Ventures, The Gong Show (257)
4. Mark Peter Davis, DFJ Gotham Ventures, Venture Made Transparent (237)
5. Rob Finn, Edison Venture, Ventureblogalist (236)
6. Sagi Rubin, Virgin Green Fund, The Grass is Greener (182)
7. Sarah Tavel, Bessemer Venture Partners, Adventurista (156)
8. Rob Go, Spark Capital, Rob Go Blog (148)
9. Matt Winn, Chrysalis Ventures, Punctuative! (148)
10. Kent Goldman, First Round Capital, The Cornice (144)
11. Rachel Strate, EPIC Ventures, Wasatch Girl (129)
12. Mo Koyfman, Spark Capital, Mo Koyfman (127)
13. Lee Hower, Point Judith Capital, Venturesome (118)
14. David Dufresne, Desjardins Venture Capital, Dav-Generated Content (101)
15. Jon Seeber, Updata Partners, Jon’s Ventures (96)
16. Josh Sookman, RBC Ventures, Ubiquitous Startups and the VC (6)
17. Vishy Venugopalan, Longworth Venture Partners, Longworth Venture Partners Blog (2)


The Ladies (oh yeah!)
1. Christine Herron, First Round Capital, Christine.net (354) (again!)
2. Sarah Tavel, Bessemer Venture Partners, Adventurista (156)
3. Rachel Strate, EPIC Ventures, Wasatch Girl (129)

I have to say I've had the pleasure of meeting quite a few of the people on this list and it's a great one (and a shout out to my BVP colleague, Philippe Botteri. I’ve had the pleasure of working with Philippe for almost three years and let me tell you: if you work in a SaaS company, if your business has any recurring revenue, heck, if the letter “a” or “s” appears in your name or the name of your company, you should be following his blog). Hope to meet the rest of you soon!

Anyone I'm missing?

Is the OS the new QWERTY keyboard?

It never ceases to amuse me that the layout of the QWERTY keyboard was first designed to slow down typists. Although we no longer type on typewriters and a more efficient keyboard layout has since been designed, we are still (and probably always will be) stuck with good ole, inefficient QWERTY. The QWERTY is reinforced by hardware (keyboards), software (the default setting in Windows and other OSs), but mostly, it is reinforced by habit: people around the world have grown up typing on a QWERTY keyboard, and we continue to train people today on the layout of the QWERTY. Habits (and cultural norms) are hard to break.

I wonder whether the same analogy holds true for the OS in cloud computing. As I wrote about in an earlier post, in my mind, cloud computing is all about eliminating the low-level tasks that do nothing to differentiate a company’s product – managing physical hardware, testing software patches, deploying new security patches, testing for security vulnerabilities, mounting file systems, etc. Something like 60% of developer time is spent tweaking these things. In a perfect cloud computing world, developers can move up the stack and focus 100% of their energies on differentiating their product at the application level.

That’s what platform as a service offerings like Microsoft Azure, Google App Engine, Salesfore.com Force, and others are all about. Even so, I would guess that a huge percentage of developers adopting EC2 and other infrastructure as a service offerings are dragging their QWERTY with them and choosing to build their web apps on a particular OS.

Fast forward a few years, has the OS become increasingly irrelevant or will old habits die hard? Theoretically, the former should be true, but habits (and cultural norms) sure are hard to break. Even so, the early traction of startups like Heroku, Joyent, Engine Yard and others looks promising.

Bessemer is the bloggiest VC

Larry Cheng of Fidelity Ventures has started curating a list of the best VC blog posts on a bi-weekly basis on his great blog, Thinking About Thinking. This week's list features another blog post from Adam Fisher - Clouds with Silver Linings.

Larry also included a little tidbit I was surprised to see: By his count, Bessemer is the bloggiest (I bet you didn't know that was a word) VC with six BVP-ers blogging:

• Bessemer Venture Partners (6)
• First Round Capital (5)
• Spark Capital (4)
• Foundry Group (4)
• Flybridge Capital Partners (3)
• Ignition Partners (3)

Of course, I can't help but mention that Larry is a former BVP Associate. Must be in our DNA!

I have clever friends

Why specialty clouds will need to hustle to stay competitive with AWS

Last week, I blogged about the advantages of specialty clouds over Amazon’s generic AWS. Now, I'll tell the other side of the story: why specialty clouds will need to hustle to stay competitive with Amazon.

I think Amazon’s competitive advantage breaks down into four buckets that are all work together to reinforce Amazon’s competitive advantage:

1. Customer Acquisition: No matter what search queries I try, I can’t find a single keyword Amazon has bid on to promote EC2. Meanwhile, GoGrid, Rackspace, Joyent and others are forced to bid on cloud computing keywords, even on Amazon’s trademarks (e.g. check out who is bidding on “EC2”), in order to try to establish their brands. Amazon’s clear market leadership drives down their customer acquisition costs, while Amazon’s competitors must invest in online marketing to try to chip away at Amazon’s dominating market share.
   


2. The new “You won’t get fired for hiring IBM”: While cloud computing is the hot topic on everyone’s mind, it is still perceived as risky, and there is a lot of fear, uncertainty and doubt when it comes to deploying applications in the cloud. This FUD and risk is compounded when you consider placing your bet on a private company startup that might have to shutter its doors in twelve months. Coghead’s unfortunate recent closing illustrates this risk. But Amazon is a $33B market cap, publicly listed company. It ain’t going anywhere anytime soon. This makes Amazon’s EC2 the safe bet, even if it’s not necessarily the best choice for a particular use case.
   


3. The growing Amazon Web Service 3rd party tools ecosystem: There is a growing and vibrant list of startups emerging in the cloud computing ecosystem. Many of these aim to alleviate the management and plumbing overhead necessary to maintain an infrastructure deployed in Amazon’s EC2 cloud. These companies aren’t going to focus on integrating their technologies with other cloud computing providers for a while, much like startups that emerged in the virtualization management space haven’t focused on integrating their technologies with any hypervisor other than VMWare’s ESX. RightScale is a great example of this phenomenon. The same is true for more traditional network management companies that have historically focused on on-premise infrastructures but are now integrating with Amazon’s API to enable seamless monitoring between Amazon AMIs and captive applications hosted in internal data centers. As Amazon’s ecosystem gets richer, competitive cloud computing offerings will have a steeper wall to climb to compete.
   


4. Amazon’s benefits from two network effects: Amazon benefits from what I’ll call an internal and an external network effect:
   
   • Internal: Once you’ve launched one application in EC2, even if you have a Ruby on Rails website that probably would be a much better fit for Engine Yard’s specialty cloud, it’s just a lot easier to have all of your applications in one place. So Amazon benefits from a sort of network effect within a customer’s application portfolio. Until companies like RightScale integrate with other cloud computing providers, Engine Yard has a slightly higher bar to meet in order to justify the additional overhead involved in logging in to another console when a company already has all of their other applications hosted in EC2.
   • External: As more and more customers move their applications and therefore their data to Amazon, other applications that use the same data source can benefit from having the data stored in S3. For example, Nasdaq now stores terabytes of Nasdaq, NYSE and Amex data in Amazon's S3, and is adding 30 to 80GB of data to S3 every workday. If I am a SF-based company that has built an application that pulls in this data, I can minimize latency by hosting my application in EC2 in the same region as Nasdaq's data. As more data piles into S3, Amazon benefits from an increasing network effect. It's worth noting that specialty clouds can benefit from the same network effect, but Amazon has the head start.
     

In the end, despite Amazon's strong home field advantage, I expect that a few specialty clouds will effectively carve out their own niche. What do you think? Is Amazon going to become the dominant force?

This video made me miss my rugby days

(The "try" starts at second 40.)

I can't believe I played for four years...

Why Amazon’s AWS Won’t Be the Only Game in Town

The shift that is clearly taking place, however gradually, from on premise data centers to centrally-run cloud computing utilities, is enough to capture any IT geek's imagination. The trend is so massive and at the same time so logical, analogies are drawn between the shift to cloud computing and the shift to the electrical grid.

At a high level, the analogy makes sense: Before the advent of the electrical grid, most companies had to generate their own electricity onsite. This meant having employees on staff to manage the electrical generators, and because most onsite generators only produced a small amount of electricity, the cost per megawatt was very high. When the electrical grid matured, companies were suddenly able to turn off their onsite generators, fire their electrical engineers, plug into the electrical grid and benefit from vast economies of scale and skill. This drove down the effective cost of electricity, and freed companies up to focus on their core competencies (which definitely was not generating electricity).

At first glance, Amazon’s EC2 and S3 web services seem to perform the same function. Now a company can tap into the Amazon Web Services (AWS) API and launch an Amazon Machine Image (AMI) instead of having to run their own servers in house. In much the same way that companies in the late 1800’s could benefit from the economies of scale and skill thanks to ConEdison, companies can now benefit from those same economies thanks to Amazon. If this were true, then Amazon’s clear market leadership would seem to indicate that if you’re going to go to the cloud, Amazon is the only game in town worth considering. Moreover, as Amazon continues to grow, its own economies of scale and skill will grow, and the competition just won’t be able to keep up.

But computing resources, unlike electricity, are not fungible. As companies experiment with Amazon and other hosting providers, I think this will increasingly come into focus. Even with the low level building blocks Amazon provides, AWS is not a one-size-fits-all cloud. For example, some hardware intensive applications will slow down and become inefficient because of the generic algorithm EC2 uses to assign AMI processes to its underlying hardware. Just as importantly (if not more so), unlike with electricity, you can’t just “plug” your application into Amazon and have it work automagically. Instead, Amazon AWS is more analogous to renting out a piece of a ConEdison power plant, but having to constantly monitor your slice of the power plant, call into the plant to ask the operator to turn certain knobs dials, clean the pipes, adjust the gauges, etc..

When it comes to the IT plumbing (deploying new software releases, configuring your web server’s IP address, testing software patches, deploying new security patches, testing for security vulnerabilities, mounting a file system, etc), you don’t actually benefit from any of Amazon’s economies of scale or skill: you still need to do these things yourself. And that's a lot of work!

That’s why non-proprietary specialty clouds like Engine Yard, Cloudera, AppNexus and Joyent, and hosting providers like RackSpace, can still thrive despite Amazon’s massive size. Taking Engine Yard as an example, their stack is customized from the ground up for Ruby on Rails web applications, and they’ve built proprietary tools to automate any plumbing. The same goes for using Cloudera over Amazon’s Elastic MapReduce. There are many other areas that could benefit from custom-built clouds. For example, PCI or HIPAA compliant clouds, I/O intensive clouds, high-end clouds that allow for scaling up databases and servers, etc..

What do you think? Do you agree?

(P.S. fingers crossed Disqus will work on this post...)

Who do you Tweet to?

Twitter is a blunt communication tool, not just because you are limited to the number of characters you can type.  It’s blunt because, unless you want to manage multiple Twitter handles (which of course is possible and I’m sure tons of people do it), you have one voice to communicate to a random assortment of people subscribed to your feed. 

So when you tweet, who do you tweet to?  Who is your Twitter muse? 

For me, I would like to think it's a personification of something close to the average of how I subconsciously conceptualize my followers. In an ideal world, that would look something like this distribution:

In actuality (as we all know), it ends up looking more like this:

But at least when I tweet, I don’t think about the spammers who have subscribed to my Twitter feed.  They never had any intention of reading my tweets when they subscribed, so good night and good luck to them.  

And as far as I’m concerned, the few random-os I have probably aren’t much different.  Maybe they subscribed to me on a whim, or saw something I said that they liked, and now, those lucky devils, they get my tweets in their feed.  Problem is, I don’t actually know whether they are reading my tweets; there is no feedback loop in Twitter.  So as far as I’m concerned, those people aren’t, and for the minority of the random people who do: thank you and have fun. 

Then there is the other side of the curve: the people who I [would like to] think are reading my tweets.  I don’t know about you, but that’s who I think I’m writing to… to some imaginary person in the middle of that subsection of the curve.  

But this means that for everyone to the left of that point, my tweets skew towards being more intimate than they should be.  In a way, a majority of Twitter followers are free-riding off the intimacy I have with a small group of my Twitter followers.  This must be one of the things that’s so enticing about Twitter.  At the same time, I can’t help but feel a little uncomfortable every once in a while when I see someone else's tweet that’s clearly intended for people a standard deviation or so away from me!

What do you think?  Who do you Tweet to?

Software taking another page out of consumer internet's playbook: FREE

A couple of years ago, after attending SaaSCon 2007, I blogged about how many of the speakers at the conference, from Marc Benioff of Salesforce to Steve Lucas of Business Objects, tipped their hats to the consumer internet world for inspiring the usability and design of their SaaS applications.

Now, it seems like software companies aren't far behind in taking another page out of consumer internet's playbook: Free.

Everywhere I look, software companies are giving away free products. Just last week, Bessemer portfolio company Tripwire released a free utility to help companies manage VMware vMotion. Solarwinds has an entire page on their website dedicated to free utilities and recently acquired a company to expand it's free tool offerings. Veeam made a name for itself with its FastSCP product (hence the nomenclature "Veeaming VMs"). And today I came across Xenocode's free virtualized browsers (I'm writing this blog post on a virtualized instance of Chrome thanks to Xenocode despite having a locked-down laptop).

For anyone familiar with the software business model (i.e., charging), this trend might sound like a crazy idea. But free isn't a trend du jour for software. It's actually a fantastic lead gen mechanism.

If you put yourself in the shoes of an inside sales rep, it's not hard to imagine why this trend has taken off. If I were an inside sales rep, I would much rather call someone who has downloaded one of my company's free tools and has been using it for a couple of weeks, than someone who I pulled off of a list, or even someone who downloaded a white paper from my company's site.

If they've downloaded the app, they'll recognize my company's name, they'll have a sense of whether they like the app's design / usability / ease of installation, and frankly, somewhere deep down inside, they might even feel like they owe me five minutes because my company gave them something for free. Moreover, in some cases, they've already gone through the trouble of installing the product; giving them access to the full paid version of the product could just be a credit card number and a software license key away (think Mozy's online backup).

The wide availability of free utility apps now flooding the market (not to mention existing and new open source projects) is going to put even more pressure on software vendors to differentiate the core products they are delivering. Many vendors won't survive: one company's Free will be another company's bread and butter. But for customers willing to pick and choose from multiple free point solutions in order to cut costs, this is just what the doctor ordered to help assuage 2009 budget blues.

Addendum:
I love blogging. Xenocode is my new bff: http://www.xenocode.com/start?a=TweetDeck

True Cost of Venture Debt Part II

First of all, I’ve gotten a lot of great feedback on the venture debt post I posted a couple of weeks ago and have had a lot of great conversations, so thank you to everyone who commented (either on my blog or via email) and keep them coming!

From these conversations and conversations I’ve had with my Bessemer colleagues, I’ve put together a presentation that discusses the venture debt analysis I described before in more detail. I’ve also included a copy of the venture debt model to this blog post so everyone can play around with the model, plug in their own numbers, and reach their own conclusions.

Venture Debt Presentation BLOG v2

Publish at Scribd or explore others: Presentations & Slid venture debt

If you have any troubles with the embedded powerpoint, you can also reference the pdf below:

The True Cost of Venture Debt

Given the current financing environment, it’s not surprising that many startups are thinking about raising venture debt for working capital. With venture dollars so few, interest rates so low, and venture debt providers so many, venture debt seems like a no-brainer decision to extend a company’s runway. Why not raise $10m now at a 14% interest rate, rather than raise $10m in equity at today’s valuations and dilute existing shareholders by 25+%? 14% sure does seem like a low cost of capital.

But it’s not always correct to equate the cost of capital for venture debt with the debt’s interest rate. In fact, sometimes the true cost of capital for venture debt can be a multiple of the interest rate. I’ll try to explain why here, and will also try to illustrate which terms you should push hardest for in your negotiation to get the best venture debt deal. (Disclosure: I work in VC, so ostensibly I’m incented to criticize venture debt and elevate equity.)

Most venture debt loans have only a handful of terms:

• The loan amount
• The interest rate (and occasionally, an interest only period)
• The drawdown period (how long you have before you need to drawdown the loan)
• The repayment period (how long the company has to pay back the principal)
• Warrant coverageAny transaction costs (i.e. lawyer fees for the company and the bank)
• [For later stage companies, a bank might mandate that the company maintain a “quick ratio” of (cash + short term AR) / loan amount, or a minimum cash balance, but let’s put these terms aside for now.]

Now let’s take an example company: let’s say Company XYZ has $6.5m in cash on their balance sheet and is burning $500k per month right now (13 months of runway). XYZ wants to keep spending money on marketing, head count, etc, so they expect their burn over the next 18 months to average around that $500k mark, after which they expect to quickly turn cash flow positive (CFP) in 6 months. Given these assumptions, XYZ will need $10.25m to turn CFP. Because their existing cash will only last for another 13 months, they start looking into their financing options.

The company talks to a few investors and venture debt providers and decides that venture debt is the cheapest cost of capital and chooses the following debt deal:

Ceteris paribus, this looks like a great deal. Eager to have the cash in their bank account, XYZ draws down the $5m, bringing XYZ’s cash balance to $11.5m. The $5m should give XYZ more than a $1m buffer to reach the CFP Promised Land with only a little dilution to shareholders and a low, 14% cost of capital.

But in this conclusion, XYZ makes a critical mistake: you can’t evaluate the cost of capital of venture debt without an eye to your company’s cash balance and burn.

XYZ has an ample cash balance to begin with, so although they drew down the debt in the first month, they won't actually need the cash from the debt until the 14th month. But by the 14th month, XYZ would have already paid back $1.8m of the debt in monthly principal payments! So when they get to the 14th month, they actually only have about $3.2m available from the $5m they borrowed. Because seeing is believing, we put together a model to show this:


You may have noticed that the “Cash Available with Debt EoM” row shows that the company’s cash is actually lower than the debt balance. This is because by January 2010, XYZ has already paid the bank more than $600k in interest! With the next month’s principal payment, interest payment, and the original transaction fees, XYZ really only gets the benefit of $2.35m in cash flow from the debt, not $5m. To make matters worse, because the company has been paying down the debt all along, the debt extends XYZ’s runway only four months. When you do the math of the cost of capital (XIRR equation in Excel), the cost of capital for the loan is a surprising 57%, not 14%, and this doesn’t even take into account the dilution from the warrants. Moreover, XYZ will run out of cash when they still have $2m of venture debt to pay off. They’ll either have to go out of business, or raise a new equity round to pay off the debt.

You may believe I did a bit of voodoo with the numbers I presented here in order to make the cost of capital so high, and you would be right if you suspected it had to do with when the company draws down the debt. If XYZ drew down the money in the 6th month instead of right away, their cost of capital would have gone down to 32% and they would have gotten an extra month of runway from the debt. This is because the XYZ would have paid back less of the debt (in this case $700k less) before they actually needed the money. XYZ could have made the debt deal even sweeter by negotiating a later drawdown period, or by negotiating an interest-only bubble. For example, if XYZ had negotiated a 6 month interest-only bubble (in addition to drawing down the debt in the 6th month), they would have extended their runway 8 months, and lowered their cost of capital to 24%. Quite the improvement from 57%.

I’ll admit all I’ve done in this post is pour a lot of cold water on venture debt, and a reader could probably still argue that even a 57% cost of capital is still cheap compared to the dilution from equity. But for what it's worth, here are two cases in which venture debt earns its reputation of having a low cost of capital:

1. Your company is already cash flow positive, or you have a high degree of certainty that your company will turn CFP with your current cash, and thus you will be able to service and repay your debt from your own cash flow.
2. The additional runway from the venture debt, even if only a few months, enables your company to reach a major new milestone that will in turn allow your company to raise equity to repay the debt on much more attractive terms.

Good luck!

Addendum:
You can find a copy of the Excel model I put together, and an accompanying powerpoint that explains the model at my blog post here. As always, if you have any questions, drop me a comment and I'll make sure to respond.