Pricing and packaging are among the more critical decisions a company makes, directly impacting growth, top line, and margins. And as board members of early B2B companies, one of the most common questions we get asked is: how should a bottom up company think about (and get started with) pricing and packaging?
While bottom up has become the dominant GTM motion across the B2B landscape, most of what has been written about B2B pricing and packaging is not directly useful for a bottom up company. Unlike traditional B2B businesses that have lengthy pricing discovery with the buyers during the sales motion, bottom up companies often don’t have a buyer or a sales team at the beginning, but rather a user journey centered around the product.
Pricing and packaging is a complex topic that is heavily product and market dependent, and unfortunately, there are no easy answers. But there are some principles and mental frameworks that can make it easier and faster to get to the optimal pricing and packaging. In this post, we pull from our experiences working with bottom up companies across open source, infrastructure, and SaaS applications to provide guideposts for understanding and mapping the user journey to figure out the right product tiers, how to differentiate them, and how to price them.
OK, so where to start?
It is critical to be clear what the user journey is for your product before thinking about pricing and packaging because the optimum pricing and packaging is derived from and maps to the user journey.
The user journey refers to the stages from first touching the product (typically without paying for it) to that product being used across the user’s organization. Unlike direct sales, where the customer journey begins with the buyer, bottom up companies are often product-led and start with a user, who is typically the first step to reaching a buyer (which may or may not be the user).
There are many variants of a bottom up user journey, but a surprising number of products can be mapped to the following stages.
TIER 1: Casual organic use (freemium/base tier): The base tier is often a “freemium” offering geared at a broad swath of users, including students, hobbyists, and the tech-curious as well as professionals. The purpose is to create awareness, a community, market education, or a wide user base from which to further refine qualified candidates for deeper product engagement.
TIER 2: Individual professional use (prosumer tier): From casual use, some users will mature into professional use of a product. For product-led companies where most of the value accrues to professional users (e.g., prosumers) this tier is often the primary monetization channel. For example, Superhuman is maniacally focused on providing a lot of value to a small group of busy professionals and monetizes mainly through this tier.
However, for most B2B enterprise companies, this layer is more about qualifying the customer for the following tiers, than providing a primary revenue stream. For example, even though Airtable has a lot of value for professional users, this tier mainly serves to qualify team and enterprise customers who will want additional features, like “custom-branded forms” or “domain-restricted sharing.”
TIER 3: Team use (small business/team tier): Teams of users tend to have more advanced “multiplayer” feature requirements than individual users, often around real-time collaboration, shared storage, dashboarding, version control and access control. The team tier can have a dual purpose of monetizing SMBs, and generating or qualifying leads for large organizations.
For instance, design teams are often the first to buy group licenses of Figma to manage a shared design system and component library. Over time, however, usage expands to adjacent product, engineering, and marketing teams for review, hand off, copy editing, and approvals. For these customers, it is often necessary to overlay a direct sales/customer success organization to sell and service the next tier.
TIER 4: Organizational use (enterprise tier): Enterprise customers have unique requirements around security, compliance, third party integrations, user management, SLA etc. This tier is where you monetize larger organizations, generally via direct sales. For many bottom up companies, this tier eventually produces the bulk of revenue. Often, this tier is a “call us” tier and priced to justify the use of a direct sales team.
While not all companies follow this model, we’ve been surprised at the consistency with which pricing plans tend to converge to some combination of these tiers over time. Notion, whose pricing plans are shown below, directly maps to this model. That said, most products end up with a subset. “Prosumer” tiers rarely make sense for open source, for example. And many products don’t have a meaningful distinction between “team” and “enterprise”.
We’ve mapped the pricing plans of 50 bottom up companies (a selection of which are shown in the graphic below) for reference so you can get a sense for how companies in various sectors and various stages tier their offerings.
The goal of the user journey is to track and cultivate product usage from casual users to buyers. Often the initial user of the product is not the ultimate buyer. This is the case for a number of products where developers are the initial target, but ultimately, the budget comes from elsewhere in the organization, such as IT, security, VP eng, ops, etc.
Deciding what tiers to have, and which to charge for, depends largely on where you expect the bulk of the money to come from. If it’ll ultimately be the enterprise, then lower tiers are generally free, or priced to aid qualification. On the other hand, a company focused on the prosumer should think very clearly about how it prices its professional tier because that’ll directly impact top line and margin.
Prosumer companies often start at tiers 1 and 2, with 2 as the sole method of monetization focused on the professional. Some prosumer companies never create a significant motion in the enterprise, and as a result, may not have team and/or enterprise packages. Dropbox, for example, has “advanced” tiers, but the tiering is clearly weighted at prosumer and self-serve business plans.
In contrast, open source infrastructure companies rarely have a prosumer tier, and the early packages may just be tier 1 and 4 — “free open source” and “call us.” With the launch of a hosted SaaS product, an open source company may add a tier 3 package to monetize team value. We have seen this pattern across horizontal platforms, like Hashicorp, Pulumi, Sentry, and Fishtown Analytics (shown below).
It’s important to note that where the bulk of a company’s revenue comes from, as well as the speed of top line growth, often shifts from lower tiers to the enterprise tier as the enterprise go-to-market engine matures. Where that transition point occurs varies by industry, product maturity, and buyers’ buying behavior. At one popular web infrastructure company, for the first 2 years, self-service was most of the revenue and grew consistently at 7% MoM. At around $10M ARR, enterprise revenue surpassed self-service, and grew to 70% of the total revenue by the time the company reached $15M ARR. At another popular open source data tooling company, this shift happened at $2M ARR.
Many companies want to have tiers that address all constituencies — freemium, prosumer, SMB, mid-market, enterprise — from day 1. However, it’s nearly impossible for a single R&D team, and GTM team to pull this off. It is far better to start with a simple model and fewer tiers (e.g. free and call us, or free and pro) and watch user engagement, what features are being used, what organizations are adopting the product, where the budget is coming from, before adding additional tiers. You can always add tiers as you learn more about the user journey, but it is difficult to remove tiers without stranding users.
A very important corollary to understand: the user journey is as much something to discover as it is something to shape. There will be an organic evolution of how users use your product, and the more you can map your tiers to that organic behavior, the easier your life will be.
The failure to map to organic user behavior can lead to a discontinuous journey, one of the most common pitfalls of bottom up pricing and packaging. Generally, this is how it happens: A startup has a vibrant community of users, but bottom up monetization is early and anemic. To “learn from the market,” the startup spins up a direct enterprise sales effort. After some initial success, they decide to invest more into that motion.
While on the surface this sounds like a good idea, too often it creates two entirely separate GTM motions — one to the buyer, the other to the user. The power of the bottom up GTM model is that the bottom up motion reduces customer acquisition cost (CAC) and provides a qualified funnel for a sales team. But this requires that the bottom up motion actually bridge the user/buyer gap. Spinning up direct sales will find the buyer, but rarely provides any insight into how to direct the user journey to the buyer. In the worst case scenario, the top down motion erodes the organic adoption and causes pushback from the users.
In our experience, you’re far better off working to grow the bottom up base, and apply sales to qualified users within it, rather than building a separate direct sales motion that’s largely independent of it.
While this can be controversial at board meetings, we lean towards growing the user base over early monetization. If you have a strong bottom up engine, you’ll have many shots on goal. If you spoil that, you’ve forfeited the company. And charging aggressively early is a good way to stifle user growth.
Many successful bottom up companies wait years before monetizing. Databricks, for instance, didn’t charge users for three years, and instead focused on growing an active Spark community that paid off when they did monetize. It’s important to remember that you can still create prosumer or team packages through registration, rather than charging users from day one.
So, when do you monetize? We recommend turning on monetization when you see repeatable usage patterns among a core customer group through concrete data gathering, or when there is a clear delineation of free product features that customers are willing to pay for, and iterate from there. In some cases, startups are pushed into monetization by the customers who want a relationship with the company for support, feature direction, improved SLAs, etc. Rather than rushing out a public pricing plan, negotiate a few custom contracts with these high-interest customers. Remember, one advantage of bottom up is that you can test your pricing and packaging, try charging a small subset of users to test how your pricing impacts churn, usage, and conversion.
We often think of pricing purely as monetization. But for a multi-stage user journey, pricing, especially in early stages, can actually be more useful as a qualifier. Minimally, it is a strong indicator of interest. More specifically, it can be used to generate a qualified list of accounts for an inside or direct sales team, establish a formal relationship with the user, and provide insight into what aspects of the product they are willing to pay for. In some cases, it can provide a rate limiting function.
How did GitHub arrive at charging $5000 for 20 developer seats when they started going after enterprises? It turns out that in the early days, they had so much inbound interest from the enterprise segment that they decided if they were to take on the distraction of building for that market at that time, it better be worth a lot of money. The price was effectively a rate limiter to qualify only those who were willing to pay large dollars. In the case of Salesforce Sales Cloud, the professional tier qualifies customers through permissions and workflows. Once the customers exceed a certain number of roles and custom apps, it shows enough momentum to have a direct sales team engage with customers for an enterprise deployment.
In the cloud era, ideally pricing is usage or seat based, and the value to the customer grows with usage. However, having value track usage isn’t always possible. And even if it is, there is a chance you’re in a market where the customer simply isn’t used to paying for it in that way.
In general, we suggest the following to determine the best unit of pricing:
The one thing to avoid is selecting a pricing unit that introduces friction when customers want to expand the usage of the product, such as “do I really need to add another seat if that user only visits the product once a month?”
There is a lot more to say here, as this is one of the more complicated and significant topics in pricing. It is significant enough that we believe it deserves addressing in a future dedicated post, so be on the lookout for that.
Bottom up doesn’t change the basics to actually setting the unit price. Since a lot has been written about setting the right price, and it isn’t the focus of this post, we’ll just provide some cursory comments.
For existing markets, normally the price anchoring is already set by adjacent companies, and the bottom-up wins over incumbents purely through ease-of-use and lower barrier of adoption.
In new markets, price is driven by value to the customer (obviously) and the cost needed to sell it — a topic covered well by Jerry Chen’s unit of value. The desired state is to achieve a “nonlinearity of value” that balances customer perceived value, cost of sales and the unit price so that as units grow linearly, you can charge more per unit. As the company grows, your cost of sales will go up, and the baseline pricing needs to cover the growing sales expense. In the ideal outcome, as you build more platform or collaboration features, per unit price grows too, which creates a superlinear curve of value.
With bottom up, you have a high velocity, relatively low impact method for testing and iterating to determine the right tiering and pricing model. Talk to different segments of your customer base to understand how they perceive the product value and the alternatives. A/B test if you have a large enough user base to get statistically significant results on different price points. If not, show your customers hypothetical pricing plans and gather qualitative feedback.
If you already have a pricing plan, updating it can be a real pain, especially when you’re changing the unit of value or pricing model. For example, companies often go from simple tiered pricing to more granular usage-based pricing as they mature. In that transition, it is necessary to back test your new pricing plan on existing customers’ usage data to make sure the incentives align and the new plan won’t price shock customers.
The user journey is a critical guide for thinking through pricing and packaging for a bottom up B2B product. Still, there are no simple or right answers, and unfortunately, many ways to get it wrong. Generally startups struggle for months, and through multiple iterations before getting it right. With this post, we hope it becomes a little easier to get to the right pricing and packages. Be on the lookout for more to come on this topic in future posts!