Estd 4.22.2023
.png)
Selecting your key pricing variable is perhaps the most consequential decision you will make in your entire pricing and packaging exercise.
If you get it right, almost every other piece of your pricing model and operations can be fine tuned. If you get it wrong, you may not only waste the time taken in conducting this project but can significantly slow down sales velocity and introduce completely unneeded friction in the sales engine.
At the end of the day the goal for pricing is to find a way to charge your customer based on a heuristic that allows a) You to obtain revenue for your product that maximizes the return from the market (i.e. larger companies are able to pay more) b) Your client to pay a price that is proportional to the value perceived to be derived by them.
There are many ways to think about this variable, including pricing on usage, license, seat, cost, and so on. As mentioned by Zuora’s CEO Tien Tzuo in his book Subscribed, I’ve found it very clarifying to look at two main approaches at the highest level as Capability and Consumption based pricing (see Figure 1). (The simplifying caveat here is we assume subscription based pricing models.)
Includes both traditional per seat based pricing models, as well as usage-based pricing models that are prevalent in newer SaaS products in the market today.
Refers to pricing a product as a lump-sum amount for the capability offered. This could be a fixed price or a price that scales based on the size of the customer. Since it is a lump-sum model, this approach doesn’t really allow for usage growth over time and is more akin to paying for a fixed piece of hardware or set capability. While it would definitely play well in a hardware setting, it also tends to work well for add-on modules that sit on top of a base platform that utilizes a consumption-based pricing model.
Given this information, how do you decide on your main pricing metric/variable?
Here is a proposed checklist:
3.1. Tie to client value: Is the metric proportional to client value? And to what extent?
3.2. Fits for clients: Will clients perceive it to fit with the value they derive?
3.3. Measurable: Can you instrument your product so that the metric is easily measurable?
3.4. Predictable: Can clients estimate how much they will spend with this metric? If the metric isn’t predictable then clients could be hit by unexpected bills that could take them by surprise.
3.5. Diminishing or Scaled Costs: As your metric increases, do your costs level out, or do they scale with usage? Sometimes there may not be much choice in the matter but this is important to note as the subsequent decisions on pricing structure, price point, and discounting will be critical in case costs increase steadily with consumption.
3.6. Deal Economics: Does this model help you create a workable sales engine? There can always be two different metrics that check all the above boxes but differ considerably in the resulting revenue and margin you accrue for each deal. Everything else being equal, you’d want to maximize revenue capture.
Now let me illustrate how this decision can have a meaningful impact with a few real-life examples:
Helpshift, a customer service software platform, originally focused on supporting mobile app experiences. Early in its journey, the team had to make a critical pricing metric decision. If they had followed the industry-standard approach of charging per seat, it would have severely limited their growth. This is because many mobile app companies don’t have large support teams, typically fewer than 20 agents, even though the apps themselves serve tens of millions of users.
Instead, Helpshift chose to price based on monthly active users (MAU). This aligned more closely with how product managers, the primary buyers, were already measuring their success, and made the pricing feel more value-based.
Impact:
Result: A 10x increase in revenue capture due to a smarter, usage-aligned pricing metric. Helpshift’s early-stage pricing innovation directly contributed to its commercial success.
Kustomer, also a customer service platform, made a different choice. It opted to retain a seat-based pricing model, similar to incumbents like Zendesk. Kustomer’s CEO Brad Birnbaum, in a SaaStr podcast, reflected on this decision:
“So pricing’s a really difficult thing, right? It’s something that we wrestled with in the earliest days of Kustomer. We wanted to be innovative. We quickly learned as we started talking to customers that they didn’t want innovative pricing. They wanted repeatable, consistent pricing that mapped to the budget they already had in place.
Now as we are going mid-market and above, we’re mostly replacing existing solutions, whether it be Zendesk or Salesforce. So they (customers) already had a budget in place, so they just said, “Hey, we have X amount allocated for a solution. Our solution is better, it’s robust, it does more, but this is the budget that we have.”
So they wanted a pricing model that, frankly, mapped to the way they’re accustomed to doing business It was highly predictable. So while we wanted to think about doing a consumption model here at Kustomer, because we thought that was innovative, we realized our customers didn’t want a consumption model.”
As Kustomer moved upmarket and began replacing tools like Zendesk and Salesforce, their buyers already had allocated budgets based on per-seat pricing. Despite their intention to adopt a more modern, consumption-based model, the team realized that predictability and alignment with procurement expectations mattered more to their customers than pricing innovation.
Impact: Though we don’t have direct data linking their pricing model to acquisition, Kustomer's strategy helped it capture a large share of mid-market customers by offering a superior product within a familiar pricing framework.
In 2020, Kustomer was acquired by Facebook for $1 billion, signaling strong market validation of their approach.
In 2019, Mixpanel changed its key pricing metric to Monthly Tracked Users (MTUs) whereas earlier they had used the concept of Events for a long period of their existence as an analytics software provider.
They made the decision to change their pricing metric because the older metric of ‘Events’ while being very measurable was no longer fitting with client perception of value as the company grew across use cases and industries. Some customers’ usage-based bills increased substantially but they didn’t feel they received proportionate value. On the other hand, their sales team found it was hard to size up new prospects and had to do more work to translate from a prospect’s actual value to the company’s ‘event’ based pricing.
They landed upon Monthly Tracked Users (MTUs) (very similar to MAUs in the last example) that checked many of the criteria I alluded to earlier: tied to value, measurable, predictable, and so on.
Impact:
While we don’t have hard publicly available metrics on impact, this change had a bunch of cascading benefits for the company:
Though the company has not published exact revenue impact, the internal benefits, both commercial and operational, were significant and well-recognized.
HubSpot, the company that popularized “inbound marketing,” began with a pricing model based on the number of contacts in the Marketing Hub. As the company evolved into a multi-product platform, including CRM, Sales Hub, and Service Hub, it became clear that contact-based pricing was creating friction.
For example, while CRM and Sales Hub activities often added new contacts, these weren’t necessarily marketing contacts. Yet customers were being charged more for just having them in the system, regardless of marketing relevance.
In 2020, HubSpot redesigned its pricing around Marketing Contacts, charging only for those contacts that customers actively wanted to market to via email or ads.
This medium post by its CTO Dharmesh Shah explains the evolution of its pricing model:
“In 2006, we were a single-product company selling what we now call Marketing Hub... Since then, we have added HubSpot CRM, Sales Hub, Service Hub, and CMS Hub to our portfolio....Marketing Hub was billed on a base price with included contacts, and database size, i.e. how many contacts were in the database, which we felt reflected the value they got from our software.
When we transitioned into a multi-product world, the interaction between our products started creating pricing issues. HubSpot CRM is free and Sales Hub is priced on a per-seat basis. Not only did our pricing philosophy differ across Hubs, sales activity would often generate additional contacts that would then raise the subscription price of Marketing Hub, whether or not those contacts were valuable from a marketing perspective. This created friction and confusion for customers. Our approach had not been designed for a multi-product world. As we entered a new phase of growth, it became apparent that we needed a new strategy.
When we went back to the drawing board on contact pricing…
A customer’s measure of success isn’t just how much they can grow their database, but how many leads in that database are worthy of nurturing. Thus, the idea of splitting marketing contacts out from non-marketing contacts, and only charging customers for the contacts they needed to interact with - was born.
Our marketing contacts pricing model allows customers to only pay for the contacts they want to market to via email or ads.”
Impact:
Hubspot’s pricing change is too recent to know what the impact is, but it's CFO’s comment in its recent quarterly earnings report indicates that the company expects a change in its customer mix due to the pricing change.
Kate Bueker A Chief Financial Officer, HubSpot, Inc.
“And then over the course of Q3 and Q4, what we saw is a much more balanced set of customer additions, which is what sort of leads me to the comments that from one quarter to the next, there's going to be some difference in the kinds of customers we add, as we introduce different functionality and make pricing and packaging changes.”
Outside of these, you will find a lot more examples in the case study section of the book. In my personal experience, it is the case studies that truly help illustrate the tradeoffs involved and the sizable impact of this decision. In particular, I recommend you read about how:
Once you have a hypothesis of your main pricing variable, you can move on to setting the core pricing structure.
I will first discuss pricing structures for consumption based models (which are far more complex) and then touch upon capability based models.
Roughly, you have three options to set the pricing structure:
Here are some pros/cons that will help you select between these options:
Pros:
Cons:
(Typically: a base fee + a variable usage component)
Pros:
Cons:
(Typically: a fixed fee, usage allowance, and overage charge)
Pros:
Cons:
Taking this concept further, how do we think about our pricing structure for a particular plan, “Pro”?
Let’s do this step-by-step. First, we will create basic strawmen of the three pricing structures.
The following table is a hypothetical example.
Now let’s visualize side-by-side the resulting revenue chart (Figure 2) obtained by deploying these three models.
The linear model certainly looks fair on a plot. In reality, the revenue is subject to consumption in any given time period and if a customer reduces their consumption for any reason, so will your overall revenue. While this can still work for a new entrant to a market by providing no upfront fee and “pay only for what you use”, bigger companies will want more predictable revenue. (See Nosto case study later in the book).
Now let’s analyze the 2-Part and 3-Part models in relation to the linear model.
Therefore, for all three models, what we need are sub-levels (known in industry parlance as “blocks/block pricing”) within our models. Here is what they could look like:
When we plot out the price chart for the models above we see the chart in Figure 16. With our fix we now have better looking price-volume curves that can capture increasing value for the two and three part models as the price increases.
Note the jagged saw-tooth edges at the unit range breakpoints for both the linear and 2-part models, that is expected and is a feature of these models. When implemented in the real world we usually try to optimize the numbers to reduce these edges but some of the price jumps or increases at these breakpoints will remain.
Note that we are able to model our Two-part price curve to be very similar to the Linear model while retaining the advantages of guaranteed revenue through the platform fee. The price at every new unit volume range in the two-part model is actually the minimum price at that range, providing us more predictability overall.
Finally, the Three-part model does not suffer from the sawtooth problem at all. The price curve in this model is the lowest price possible while including overage payments such that there will be a point at which it will make more economic sense for a prospect to select a higher tier/bundle. This is what we want. It gives us even higher predictability and more revenue as per academic research.
The counter consideration to predictable revenue is client adoption. If your product is newer then clients are less likely to opt for a 3-part model and much more likely to adopt a linear model.
At the end of the day, it is your decision on which structure to implement. But my hope is that this gives you a sense of the pros and cons involved in this decision.
So where are we now?
We have understood the selection of the key pricing variable and a supporting pricing structure for a consumption based pricing model, the predominant approach for base pricing in SaaS.
Before we move on, let’s take a look at capability pricing models.
Capability price is as defined, charging a set amount for a piece of software capability. A great example is Basecamp’s pricing at a flat $99/month independent of usage. Now I would argue that in general, this pricing approach isn’t the best for the base software, since you are more likely not only to leave money on the table but actively dissuade enterprise adoption. (The reason for the latter is best described on Tom Tonguz’s blog)
Where it does make a lot of sense, and where capability pricing shows up a lot is for add-on pricing. Let’s say you want to add a specific piece of higher-end capability to your existing packages. Now for pricing these add-on features, you really don’t want to create a whole other pricing variable for consumption pricing. In my experience, it would make your sales and sales operations teams go crazy with the complexity. This is where a capability pricing approach really helps (see Figure 4).
Now even though it is a lump-sum amount it still need not be a fixed price. Some add-ons can be priced as a percentage of the base fee (this enables the add-on price to scale with the size of the customer) and others can be a fixed fee (see Figure 5).
Taking this forward, capability pricing for add-ons can basically be done in three ways:
At this point you should have enough information to decide on your hypothesis of a) your key pricing variable(s) and b) a pricing structure for each of your product tiers, and would be ready for the rate setting.