Selling Open Source 101: The sales funnel and its variables

Since I joined MongoDB it seems I have mostly been doing technical blogs. Yesterday I had a conversation with a long time friend from the open source database scene, which inspired me to jot down some observations on my long time favorite topic: open source business strategy.

In fact, this will be very much a Selling Open Source 101 blog. I've come to realize that while what I'm about to write is well known to open source oldtimers, those of us who were lucky to work at Red Hat and MySQL and other first generation open source companies, these ideas are not necessarily well known to many executives and sales managers working in open source today.

The reason is the outright explosion in commercial open source software. We live in the golden age of open source. Yay! Today pretty much every new company selling any kind of software is open source. As a result of this, a lot of people who used to work for closed source software companies have now ended up working in open source instead. And many of them have never heard about what I'm about to write about. Often because their boss doesn't know about these ideas either.

So this post is dedicated to all of you business types who are now in your first open source job. I hope this will be useful in formulating your business strategies and goals.

Your sales funnel

The sales funnel is the process of how prospective customers to the left move to paying customers to the right. Each step is a subset of the previous step to its left. This is what the funnel should look like for an open source business:

  1. Awareness.
    ...is often what your marketing department produces. The first step leading to someone using your software, is that they are aware of it existing. While great marketing certainly helps, it's actually not always an absolute requirement. Sometimes it happens that some open source software spreads and becomes popular simply by word of mouth, because the software fills some useful role. Linux, Apache, PHP... all started this way, getting commercial backing only many years into their lives (in the case of Apache and PHP, maybe they never had much of marketing?)
  2. Adoption.
    ...is that someone becoming a user of your software. This is an important step! Maybe your product was competing against other alternative software solutions, yet the user has now chosen to use yours. Most importantly, this is of course a pre-requisite for someone to eventually pay for it too.
  3. Lead.
    ...is the inverse of the first step. A lead means that you are aware of the existence of someone who could be a prospective customer. (And in the strict interpretation of this funnel, is already using or at least trying out your product.) A lead is still a "raw" lead. You might have just someone's email address or phone number, but you have some contact information of a person who you can now try to contact and discuss their willingness to buy your "Enterprise version".
  4. Qualified Lead
    ...is the subset of leads which we can say with some certainty have a likelihood of really becoming customers. In companies I've interacted with I've mostly seen BANT leads being used. This means we have confirmed that we are in contact with someone (or someones) who has (have) a BUDGET, the AUTHORITY to make a purchase decision, a NEED to use your product and an actual TIMELINE when they will need it. (...for example at the start of a project, or when going into production).
    In my job as a pre-sales architect, this is the point where I become involved in a customer project. As BANT leads are identifie as likely to become paying customers, we now have an interest in investing some effort to make sure the evaluation, PoC, etc... is successful and we can get the prospect happily to the next step:
  5. Customer
    ...is the subset of all open source users of your product, who we've successfully converted to paying customers!

Now that we have a model of our business, we can apply a bit more scientific rigor to managing the business too. For each of the above stages we can collect some statistics to follow:

  1. Awareness metrics: Press mentions, Google trends, Twitter followers, how many people clicked a link in your marketing email, etc... In the database industry many people track the DB Engines Ranking which mostly measures variables that are in this category.
  2. Adoption metrics: Downloads, open jobs, user group memberships, course participants, etc... In following the NoSQL market I personally like the so called "Linkedin index" produced by my favorite analyst team.
  3. Lead metrics: From this point on this becomes easier, as by definition this information is just the number of contacts you have in your CRM or marketing databases.
  4. Qualified lead metrics: same
  5. Customers: Note that at this point companies are usually more interested in the revenue rather than number of customers. For the purposes of this blog post we are interested in both.

Out of these I find the Adoption and Customer stages the most important. It turns out there is a commonly agreed magic number that states that an open source business can expect to convert roughly 1 out of every 1000 users into paying customers. Of course this ratio is just a round number - as an open source business we only have a vague idea of how many users we might have anyway. But nevertheless, this is a very commonly accepted ratio - almost like a law of nature.

This understanding is the key to formulating your open source go-to-market strategy: Your sales revenue (and its growth) is a function of your number of users, and the conversion rate from users to customers.

The other stages are of course not unimportant either, as each one is a step toward the goal of converting the prospect into a customer. A great marketing team can certainly boost adoption. Still, sometimes it does happen that some open source software is so useful, revolutionary and cool that it spreads simply by word of mouth without any professional marketing. (In fact, the first years of many open source softwares had exactly such an experience.) The opposite observation is even more important: No amount of marketing dollars can save you if the product itself is not strong. Hence, while it is important for the marketing team to track their own performance, these metrics are not variables that will strongly predict your future revenue. Issuing a press release may or may not improve your future sales. But real user adoption almost certainly will.

Similarly the Lead and Qualified Lead steps are important, but personally I see them more as a measure of the efficiency of your sales process, rather than measures of true growth of the business or the potential out there. The metrics on these last stages, in my opinion, simply measures whether your sales force is spending their time wisely. But ultimately the number of leads is still bounded by the total population of users. Hence the potential growth of your business, once again, is vested in the growth of your user base. Everything between is merely mechanics.

Note by the way the unfortunate challenge you have here: the metrics following Adoption are the most important to us, but that is also the one stage that is really difficult to measure. Even download numbers may be meaningless, if users mostly download your software from somewhere else. At best we can hope to find some metrics that are a proxy indicator for how the userbase is growing in relative terms, but we will never find out the absolute number of users. Perhaps this is one reason why more people don't use this funnel as a model of their business? It's much easier to focus on managing the metrics that are easy to measure, even if they are less important.

The formula for growing your open source business

Accepting the above conclusion, there are really just 2 variables we can influence to grow our open source business: grow the user base, or improve the conversion ratio.

Interestingly, many choose to focus on the latter variable. It might be that they get some kind of negative reaction to the inherent fact of being in an open source business: since we have millions of users, but only 900 customers, clearly we should find a way to force more users to pay for our software!

There are many things we can do to improve the conversion ratio:

  • Increase efforts to connect with more users, ie find more leads.
  • Improve the lead qualification process (ie. the selectivity of it) so that the sales force uses its time as efficiently as possible.
  • Sometimes simply hiring more sales people helps increase the top line, even if not always the bottom line.
  • We can add some closed source features into the product, hoping that this will force more users to pay for access to those.
  • One proven way of increasing your revenues is simply to increase the prices of the product! This always has a risk of churn, ie you double the price but lose half of the customers and gained nothing. In open source the risk of churn is even bigger, since customers can simply choose the option of using the product without paying the higher price.
  • We can hope to increase the number of units sold to existing customers. For example in the database world the amount of data is always growing, so the same user will soon need more servers in his database cluster. (Note however that I count new projects at existing accounts as more adoption, not conversion rate.)

So given a constant userbase, and having done all of the above to improve the conversion ratio, how much can we expect sales to increase? Maybe 2x? If we can get away with a decent price hike, maybe even more, like 4-5x? So instead of 900 customers we would have 1000-2000 customers, each of which would also be paying more than before. But note that this is a one time optimization we can achieve. If the user base remains constant, you can grow 2-5x and that's it. I've sometimes heard people thinking they should aim for monetizing more than 1%, maybe even 10% of their user base. That is folly, and not supported by historical experience of any existing open source company.

On the other hand, hopefully the product (and the marketing department!) is so great, that the userbase keeps growing. Maybe even explosively. If you're a young startup with 10k users, its easy to see a good product growing into millions of users. When you're in the millions, it's not impossible to grow into tens of millions of users. For most enterprise / infrastructure software, that's probably reaching a limit - certainly you cannot get to a billion users like Facebook or other consumer software.

So depending on your lifecycle it's easy to imagine, even natural to expect, for example 2x growth year-over-year, and 10x growth over a couple of years. For a successful product of course. Clearly the potential available in growing the userbase is much bigger than the potential gains from optimizing the conversion ratio. In practice you will do both, but remember that the real winner is from multiplying your userbase 100-fold or 1000-fold.

How this differs from selling closed source

Finally, let me briefly compare the above funnel to the typical funnel for selling closed source enterprise software:

Basically, we've flipped the Leads to the left and Adoption to the right, immediately before becoming a Customer. Comparing this to the open source sales cycle we get:

  • In the closed source sales cycle we spend sales effort in convincing the prospect to become a user. Once he is committed to being a user, he will have to pay.
  • In the open source sales cycle we hope to find the existing users who can benefit from our commercial service offering. In the simplest case someone might already be in production with your software, and are calling you to get urgent help, and you sign a small deal the same day!
  • In other words, the closed source sales cycle is much heavier, longer and more expensive. The open source sales cycle, when the lead qualification is well optimized, is much shorter and more efficient.
  • The obvious drawback - purely from a sales point of view - of the open source funnel is the 1000:1 conversion ratio from users to paying customers. (1:1 for closed source.) Hence in open source you must first win the prospect into a user, which will be comparably easier. But then you still need to work hard on converting the userbase to customers, and this is harder and you will fail many times.
  • In closed source, as long as someone remains a user, he will be paying you. Hence you seek an optimum between your pricing and the migration cost.
  • In open source otoh the user can always just choose not to pay. Hence your pricing must mostly reflect what the customer thinks is reasonable to pay for the value added service offering. In other words, open source software must be cheaper, otherwise you lose deals. In practice Oracle can sell truck loads of Exadata Machines for a 7-figure price tag (per unit), while in open source even just talking about 7 figures happens, but is rare.
    Note: In open source migrations always never happen due to price reasons. If people are migrating away, it means you have a product problem, period.
  • The 1000:1 conversion ratio in open source, and the cheaper pricing, must be offset by
    1) strong user adoption (that's the whole point of being open source!) and
    2) a much more efficient sales cycle.

A closing story

In conclusion then, while I have argued that you should focus on growing Adoption more than anything else, it also turns out you want to focus on your lead generation process. However, the goal of the lead generation process is not to find as many leads as possible, rather to be as selective as possible so that we can keep the sales cycle short and efficient. Ideally, and it does happen, the prospect will find and evaluate the software all by himself, and choose to become a user because the product and the community are so great, and then will contact you or be contacted by you towards the end of the evaluation, quickly leading to a closed deal!

But you need to become good at lead qualification to master that, and you need to look out for different things than you do in the closed source funnel.

Late into 2013 I was already an experienced MongoDB Solution Architect, and was spending a week in another country where we had recently hired two new Account Managers and one Solution Architect, to work together with them as they got started in their territory. We went to a meeting together and talked with the prospect. They were already on their way migrating from SQL Server Express to MongoDB, becuase they had hit some of the limits built into SQL Server Express. They would probably distribute dozens, maybe hundreds of units of this new release, including MongoDB, to their customers.

When we got out of the meeting, my colleague was optimistic. The meeting went well, they are clearly going with MongoDB, will ditribute lots of units, looks like a good opportunity!

"Yeah, but they will never pay anything", I said. I made this conclusion 5 minutes into the meeting when they had told that they had used the free version of SQL Server, and the main motivation to upgrade to an open source database was to avoid upgrading to the commercial versions of SQL Server. Surely if they spent so much effort on not paying Microsoft anything, it was quite clear they weren't planning on paying for MongoDB either. Especially as it was also clear they had absolutely no use for our closed source monitoring and backup tools either.

Footnote: I actually haven't followed up whether this company became a customer. The above was just my conclusion based on what was said in the meeting. The point being, you must listen to the right clues in your lead qualification process, and that is what I heard and thought.

Next: Selling Open Source 101: Why it makes a difference to understand what you're doing

About the bookAbout this siteAcademicAccordAmazonAppleBeginnersBooksBuildBotBusiness modelsbzrCassandraCloudcloud computingclsCommunitycommunityleadershipsummitConsistencycoodiaryCopyrightCreative CommonscssDatabasesdataminingDatastaxDevOpsDistributed ConsensusDrizzleDrupalEconomyelectronEthicsEurovisionFacebookFrosconFunnyGaleraGISgithubGnomeGovernanceHandlerSocketHigh AvailabilityimpressionistimpressjsInkscapeInternetJavaScriptjsonKDEKubuntuLicensingLinuxMaidanMaker cultureMariaDBmarkdownMEAN stackMepSQLMicrosoftMobileMongoDBMontyProgramMusicMySQLMySQL ClusterNerdsNodeNoSQLNyrkiöodbaOpen ContentOpen SourceOpenSQLCampOracleOSConPAMPParkinsonPatentsPerconaperformancePersonalPhilosophyPHPPiratesPlanetDrupalPoliticsPostgreSQLPresalespresentationsPress releasesProgrammingRed HatReplicationSeveralninesSillySkySQLSolonStartupsSunSybaseSymbiansysbenchtalksTechnicalTechnologyThe making ofTransactionsTungstenTwitterUbuntuvolcanoWeb2.0WikipediaWork from HomexmlYouTube