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.
Sunday, December 13, 2009
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.
Monday, November 23, 2009
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.
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. :)
Tuesday, November 10, 2009
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.
Monday, September 28, 2009
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:
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?
Thursday, September 17, 2009
- Adobe Reader
- Bunch of browser plug ins (Java, etc)
- Canon Utilities (actually five installs for this)
- Citrix Metaframe
- Google Chrome
- IE (not by choice)
- Microsoft Office
- Norton Antivirus (came for free w/ my PC, otherwise I would have installed AVG)
Wednesday, September 9, 2009
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?
Monday, July 6, 2009
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.
Thursday, May 28, 2009
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)
Wednesday, May 20, 2009
Sunday, April 19, 2009
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:
- 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.
- 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.
- 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.
- 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.
Thursday, April 16, 2009
Wednesday, April 15, 2009
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...)
Friday, April 3, 2009
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.
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?
Sunday, February 22, 2009
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.
I love blogging. Xenocode is my new bff: http://www.xenocode.com/start?a=TweetDeck
Friday, January 23, 2009
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
If you have any troubles with the embedded powerpoint, you can also reference the pdf below:
Saturday, January 10, 2009
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.]
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:
- 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.
- 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.
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.