A Framework for Freemium

With a touch of open-source

Despite being commonplace in the startup vernacular, the freemium business model is a relatively new phenomenon. This is thanks to the expansion of buyer personas (end users, developers, line of business managers, etc.) and the transition to SaaS from self-hosted software. According to our friends at Investopedia:

A combination of the words “free” and “premium,” the term freemium is a type of business model that involves offering customers both complementary and extra-cost services. A company provides simple and basic services for free for the user to try; it also offers more advanced services or additional features at a premium.

Freemium business models reflect the idea that an individual or team can adopt a free version of a product and transition into a paid version to access additional features. Some of the most prominent software companies found their success on the back of freemium strategies: Slack, Confluent, Hashicorp, Databricks, Dropbox, etc.

The decentralization of software purchases in the enterprise means that more decisions about where money is spent happen on the front-lines where the software is consumed. With so many products to choose from, the easiest place to start when considering a major software investment is within the shadows of IT: what are my users already using inside of my company?

As a founder, you can gain leverage on a market with a well-crafted freemium business model that is tightly coupled with your product development. Determining how specific features will amplify your business model helps you design a more impactful product roadmap. Freemium can take many forms. The rising star of the free-to-paid trend is the commercial open source business model. In this post, we’ll explore all things freemium: why this approach is strategic, how to design your pricing plans, how to think about product-led vs. sales-led sales growth, free trials, and the emerging trend of commercial open source.

The strategic value of freemium business models

In the context of business models, freemium serves two primary functions: qualification and virality.

Qualification

If a prospective customer is already using a limited version of your product in an enterprise setting, there is a better chance that they’d qualify for a paid version of your product. This effect becomes even more pronounced when the “free” version of your software is open-source.

My first job in the tech industry was at Box, where I started as an inside sales rep. My primary source of leads was Box’s large database of companies using our software for free. If I could convince them that premium features would better serve their business use cases, I’d have a better chance to convert them to paid customers. Since they were already using our product regularly, it was apparent that Box had addressed some existing business needs.

For startup founders/CEOs, a major goal is to achieve sustainable unit economics. One variable for sustainable unit economics is the cost of customer acquisition relative to what you earn from customers. If your sales reps spend too much time speaking with poorly qualified customers, the revenue resulting from these efforts may not compensate for the time spent trying to acquire them. A specific example:

Every 10 conversations with customer prospects results in one $10k sale. If my sales rep salary is $15k per month and they can only achieve 10 customer conversations per month (e.g. earning $10k per month), then this doesn’t represent an economically viable model.

If instead, the salesperson sources these conversations from customer prospects already using your product for free, then these leads are more likely qualified. Maybe that same sales rep can convert a $10k deal from every 5 conversations. Of course, there are other variables like potential deal-size and the cost of serving users for free, but you get the point.

Virality

One of the promises of a freemium business model is that prospective customers can prove that your software addresses some of their needs independently. The business case as to why a prospective customer should pay for your software expands as does the number of people using it on their own.

As a word of caution, “free” does not guarantee adoption; you still have to achieve product-market fit. The rate of virality depends on how useful your product becomes in a team setting and the presence of network effects. If either of these two variables is present, then a freemium business model is incredibly powerful. For example, Slack is primarily useful in a team setting and becomes more useful as more people within a company use it since knowledge expressed through dialogue accrues in the platform. Did Slack thrive on the back of a freemium business model? You bet.

Freemium business model design

Business-model-fit

You first need to consider your product’s value proposition and whether your users can perceive this value independent of organization or enterprise-wide adoption. Since a successful freemium model starts with convincing the individual or small team that the product is useful, here are two questions you can ask to qualify the value to an individual:

1. Is there a “singleplayer mode” for this product? Kevin Systrom, the co-founder and former CEO of Instagram describes the “single-player mode” product experience as being one where no one else needs to use the product for it to be useful.
2. Does this product require an organizational adaptation? Many times software requires new or evolved existing processes in order for the value to be realized. Depending on the level of organization buy-in required, it may be hard to compel the individual or small team to adopt.

Security products come to mind where some combination of newly formed organizational processes and enterprise-wide adoption is required for the value to be realized. For example, an access control tool (e.g., Okta, Duo Security, StrongDM) would deliver more confusion than value if not implemented across an organization alongside updated processes. The same could be said for an incident reporting tool if it were adopted by a subset of developers without a process for triaging incidents.

Conversely, a task management tool like Asana would be useful to an individual looking to organize her work, a team coordinating a project, or a company to organize strategic initiatives.

Consider the buyer and end-user personas

It’s rare that your buyer is also your end-user so consider the path from one to the other. If your end-user is who you expect to discover your product in a freemium setting, think about how she typically encounters new products. Developers usually prefer to discover new products themselves without any assistance from salespeople. The same can be said for collaboration and productivity tools users.

If you’re selling the next best developer tool, think about what would cause the Head/VP of DevOps, CTO, or VP of Engineering to consider converting the internal unpaid usage of your product to a paid plan. Typically, this consideration requires some measurable improvement of metrics that these leaders care about. Are developers shipping products quicker with fewer bugs? Does your product reduce infrastructure costs? Is there a fragile organizational process that you can automate or provide structure to? The answer can’t simply be “our user interface is better” or “you don’t get the secure version without paying,” because then you’ll likely only convert them into an unhappy prospective buyer. This is relevant for freemium business models because you want the unpaid usage to support the value metrics that would motivate a company to buy at an organizational level.

Where to insert the paywalls

In executing a freemium business model, the most important decision might be where to insert the paywalls. The tight relationship between your product roadmap and your go-to-market model should become apparent. If your goal is to attract users to a free plan and then upgrade them to a paid plan, which features are necessary to deliver quick value in an unpaid setting and which would help them realize more value in a team setting? If we know that there is a standard set of features required for enterprise deployments, when should we build those such that we can support these deals?

To drive home the importance of where to draw the line for monetization, I’ll offer a cautionary tale. Evernote is an example of a company that didn’t find a balance between free and paid plans. Phil Libin, co-founder and CEO, famously said:

I don’t need to squeeze money out of you. I’ll have the rest of your life to take your money. It’s my long-term greedy strategy. Our slogan is, ‘We’d rather you stay than pay.’

…and ‘stay’ users did. The problem was not enough of them converted to paid plans because Evernote’s collaborative features (“multiplayer mode”) and other premium features did not provide enough incentives for users to upgrade. When a software company resorts to selling branded goods, it is likely their business model is poorly calibrated. With a poorly calibrated freemium model, Evernote has struggled to turn the corner to generate the majority of its revenue from enterprise customers.

If we start with the assumption that a freemium business model serves qualification and virality, we must craft the paywall such that you’re not obstructing either of these two variables. The following segmentation provides a useful framework for paywalls (I’ll use my experience at Box as an example of monetizing freemium):

Individual — free forever unless this person can unreasonably drive up your costs. This individual should be able to adopt your product with a reasonable expectation that it will be free as long as she uses it. Where there are marginal cost considerations, you might layer on a paywall to hedge the risk of unprofitable users for whom you have no reasonable expectation of future profits. At Box, our software was free up to a certain threshold of storage.

Teams — paid for additional features and/or usage. This is where the principle of virality is important (“multiplayer mode”). You want your product to spread within an organization but with some friction. If Box had charged users to share a file with anyone inside of their company, this would have impeded virality. You want several instances of adoption since multiple users of your product better support a business case for a paid plan in an organization. On the other hand, you want to introduce some friction to broader team adoption such that the features available in your paid plans make the product more useful in a team setting. In the case of Box, this was more robust collaboration and sharing features.

This is also the place where multiplayer mode matters. You want your product to become increasingly useful as more people use it within an organization. Let’s look at the pricing plans of Figma, a popular collaborative interface design tool as a case study:

Source: https://www.figma.com/pricing/ as of Aug 2020

An individual can still perceive the value of Figma in “singleplayer mode” for free. If she chose to share design projects with people on her team in a private setting, then she would need to consider a paid plan. Figma becomes more valuable in a shared setting (shareable team libraries, invite-only projects, custom file/user permissions, etc) meaning the enhanced “multiplayer mode” would not only incentivize a paid plan but also support virality.

Enterprise-wide — premium pricing to reflect the premium value. This tends to be the most obvious place to charge for your product, and enterprises are usually explicit about the features they require to pay for your product in a scaled setting: SSO, logging, user permissions, admin capabilities, customized service agreements, etc. This is also the tier where purchasing the software becomes a multi-stakeholder process. For example, if a user needs to connect your software to another enterprise system that relies on other people in the enterprise to get involved, this typically requires organizational buy-in and should warrant placing these types of features on a premium enterprise plan. Slack released the enterprise version of its product 8 years after the founding date in response to enterprise requirements.

In the Figma example, notice how SSO + advanced security and Plugin administration are available in the enterprise plan. The former represents a “check-the-box” feature and the latter suggests a feature that requires other teams to buy-in.

Intermission: Product-led growth

Go-to-market models that are “product-led” describe those where companies adopt software independent of any interaction with a salesperson. This selling motion contrasts with sales-led, where a salesperson supports the transaction. Product-led business models are a trendy topic and justifiably so because they tend to have lower customer acquisition costs. A freemium pricing strategy usually complements product-led growth, so it’s worth introducing a framework to decipher if this sales model fits your product. The decision to go product-led or hire a sales team depends on whether an individual can purchase your product or if a purchase requires organizational input. If someone can swipe a credit card and go, then perhaps a product-led model will work or at least serve as a starting point for an eventual sales-led enterprise sale. Otherwise, it takes a salesperson to shepherd the purchase decision through the relevant stakeholders. As the shepherd says, “sheep don’t herd themselves.”

Free trials and mattresses

Where does the “free trial” fit into this equation? Aren’t users pumped to try something free for two weeks before they start paying for it? Perhaps but probably not. If a mattress salesperson allowed you to test a mattress but told you they were going to wake you up in 15 minutes, do you think you’d actually fall asleep?

A similar effect applies to software: I may not fully engage your product if I know there is a chance you might take it away. Free trials ask users to consider procurement before they’ve determined if it’s useful. Users have to think about budget, the authority to buy, whether it will be worth the hassle, and more before they’ve even had a chance to qualify the initial problem — that which they assigned your product to do.

Sometimes users who are a better fit for a free plan end up converting to a paid plan when a trial expires. This unintentional conversion is a guaranteed way to attract unhappy/unqualified customers. It also disappoints sales teams who call on these people in search of future upsell opportunities (not to mention the billing overhead that goes into offboarding these customers). My advice with free trials: approach with caution.

Open-source: the ultimate freemium model

Perhaps the most optimal business models in the context of freemium are those of open-source software (OSS). Returning to our friends at Investopedia:

Open-source refers to a software program or platform with source code that is readily accessible and which can be modified or enhanced by anyone.

Typically, OSS business models work like this: developers test out the source code to establish proof of concept and then pay a vendor to help them utilize the software in production. Because the source code usually lacks many of the features or capabilities they’d require to use in a production setting, the primary trade-off the enterprise considers is “build vs. buy” where reliability is a major consideration.

In this context, reliability refers to scale and security among other things. Increasingly, enterprises fall on the “buy” side of the equation because software vendors can demonstrate these requirements at a level that would be hard for buyers to achieve themselves. Scale and security are hard to deliver via open-source because they require an opinion about the underlying infrastructure and configuration. Companies built around OSS projects are well-suited to form these opinions given their proximity to the projects.

It’s worth noting that open-source software doesn’t belong to anyone. Whether a company donates the source code to a non-profit foundation to manage governance and help with community building or chooses to do these activities themselves, the code belongs to the public. A vendor is not actually giving something away as part of the go-to-market motion and, therefore, this is not technically a freemium business model but rather one built around a product that is already free for everyone.

In the same way that freemium business models support driving awareness and consideration, commercial OSS (COSS) business models benefit from similar effects. COSS business models have a few flavors of freemium:

1. Support & services — assist with deployment on a company’s private infrastructure, integrations, training, and maintenance (👋 RedHat). Since companies are increasingly choosing the cloud vs. managing their own infrastructure, this model is becoming less common. This model is also hard to scale.
2. Hosting — offering a fully-managed version of the open-source project (👋 Databricks, MongoDB Atlas). The wild card with this approach is big cloud: Amazon Web Services, Microsoft Azure, & Google Cloud Platform. If your project achieves prominence, there is a chance that the cloud giants will fork the open-source and commoditize your business model. Just ask our friends at Confluent, Elastic, MongoDB, RedisLabs, and others. 😬
3. Open-core — give away the source code but then charge for a software layer and/or the enterprise requirements like those mentioned previously (👋 Confluent, Elastic). The primary decision here is balancing which features are released in open-source with those that are paid/part of the software.

If an enterprises pay for an application layer and/or an opinion about how the OSS code is configured in an open-source model anyways, it begs the question: why do open-source at all? One reason has to do with the product consumption mode. Using Slack as an example, the consumption mode is generally the same for nearly every company: users log in and communicate with their colleagues. If we contrast this to infrastructure software, the consumption mode varies widely because this software connects to other systems that rarely mirror those of other companies. The need for a high degree of extensibility benefits from the modularity of open-source software. OSS also tends to be more trustworthy since there is a community ledger of improvements and visibility of the underlying source code.

In some sense, COSS business models provide the ultimate qualification: if a company is serious enough to dedicate resources toward testing the source code, they are likely to become qualified prospects. In that sense, open-source business models provide the ultimate paywall in that if they want to use your software in a production setting, they need to pay you to do so. Otherwise, they’ll need to build additional features and trust that the software will be more reliable by their own hand. COSS businesses also benefit from the ultimate viral loop: as more developers adopt the source code, others will discover the project. COSS represents inclusiveness and community-building, which can help extend its reach.

The open-core approach lends itself to a hybrid SaaS and open-source model. Essentially, it’s the SaaS features that companies pay for to use the product in production. With this hybrid approach, some customers may only ever experience your product as a SaaS solution without ever testing the open-source version. For those customers whose requirements are less rigid, they’re perfectly happy to adopt the SaaS product. This implies that you could have two branches to your freemium model by promoting a free version of the SaaS product alongside an open-core. It’s not uncommon for companies to monetize via hosting and an open-core approach. Want it fully managed? We got you. Want a software layer on top of the open-core? We can do that too. Want to go straight to SaaS? Hold my beer.

Bringing it all home

Too often founders build their products without fully considering their go-to-market model. Those who are wise consider the symbiotic relationship between product and sales and design the two with this understanding. Whether you choose to pursue a commercial open-source model, hire a sales team, build a self-service business, or some combination of all of these, intentionally drawing the lines between free and paid will help you maximize your chances of success.

Special thanks to Marie Gassée, Henry Hsu, and Sandeep Bhadra for their meaningful contributions to this post.