Differentiation — the primary cause of ‘weird’ SaaS pricing models

Wait a minute — isn’t differentiation a good thing? Especially with pricing? Isn’t that the point of pricing — to reinforce your positioning and differentiation relative to your competitive alternative?

Yes and no.

When setting actual pricing, differentiation is critical. It’s a complex process involving art and science and begins with determining value. Dan Balcauski of Product Tranquility has written a series of excellent posts on how to define and assess value as a first step in thinking about pricing, including “What the Hell is Value Anyway?” and more recently, “Six Steps to Calculating Your SaaS Economic Value.” In the latter, Dan provides a framework with tactical steps on how to calculate value differentiation relative to next best competitive alternatives.

At XaaS Pricing, we think differentiation breeds weirdness once you move beyond value analysis and into “the price world,” as Dan puts it. When you are setting up packaging and pricing models for your offering, that’s where the opportunities for weirdness creep in.

In the first of Dan’s posts, he uses the example of selling lemonade to articulate the concept of economic value. He writes, “If you’re selling lemonade for $10 and your neighbor across the street is selling it for $5, then there better be some real differentiated value on offer — is your lemonade made from the finest fruits plucked from Italy’s Amalfi Coast? Or chock full of special vitamins?”

Completely true. In this context, differentiation as a concept makes a ton of sense in that context and isn’t weird at all. But what if we look at this same example through the lens of pricing and packaging?

Let’s say that one of those lemonade stands is pricing their lemonade per cup, just like every other lemonade stand you’ve ever seen, and the other is pricing it per ounce, or per the amount of lemon or teaspoons of sugar used per glass. That would start to feel, dare we say, weird.

Where to think twice about SaaS pricing differentiation

As Dan discusses throughout his posts, there is always a “next best competitive alternative,” or NBCA, that is the foundation for determining the economic value of a product or service. This could be a direct competitor or an indirect competitive offering. For example, you might be competing with another direct SaaS provider, a different SaaS category, or maybe even with Excel. It’s important to establish your NBCAs in the context of each of your products and editions and the customer segmentation that those editions serve, as NBCAs are likely different for each.

Your chosen NBCA becomes a critical starting point for quantifying your product’s economic value, which then takes you down the road of ultimately establishing pricing. We believe the NBCAs in your market also create a critical frame of reference for expected packaging and pricing models. Unlike with the value process, however, often these NBCAs guide you not on how to differentiate, but conversely, where it makes sense to not differentiate.

What do we mean?

The point of establishing value using the process that Dan outlines is to define differentiation relative to alternatives, which leads to positioning of pricing relative to alternatives. If you undertake this process, but then establish a packaging and/or pricing model that makes it difficult for you to articulate the price differentiation of your offering relative to alternatives, then your process was all for naught.

Instead of lemonade, let’s use a SaaS example to illustrate this dynamic. Let’s say you offer a CRM solution. Your chosen NBCA for a given package is priced per user, per month with monthly and annual subscription terms. Your NBCA prices at $5 per user, per month for a monthly term option for this particular product.

If you choose to price your product per user, per month with a monthly term, and your pricing exercise resulted in a set price of $10 per user, per month, you have some work to do to explain why your product is 2x the price. But if you did your homework on value, you have some great starting points around which to build a message and you are talking apples-to-apples, users versus users.

Alternatively, if you choose to price your product per active market contact engaged per year plus an additional per GB storage fee, then you have another set of hurdles to jump to help your customers understand your product’s pricing versus the differently priced alternative.

This isn’t a one-size-fits-all approach, and we aren’t saying you shouldn’t differentiate your pricing model at all. There are really good reasons to do so. But you should pick your spots and consider the customer in every step of the process.

There are generally accepted aspects of SaaS pricing models where we think differentiation in nearly all cases will just lead to weirdness. These include:

• Price Meters: 94% of the companies we track in XaaS Pricing express pricing in monthly terms (per user, per month, for example), even if they require a minimum term of one year. Anything else confuses customers. GitLab is a good case study on this point. GitLab requires an annual subscription and use to express pricing in “per-year” terms, but it shifted to “per month, billed annually” as annual pricing was confusing customers and making them think GitLab was more expensive than alternatives.
• Metering Models: There are really only a few options in metering models. You can offer SaaS in a subscription model, a pay-as-you-go model, or a hybrid of the two. If you aim to get innovative with the overall subscription construct that is used, you will likely confuse customers and create a perception of pricing model weirdness.
• Subscription Terms: If you choose a subscription construct for your product, your published pricing should likely include monthly, annual, or monthly and annual options. Anything else (e.g., quarterly, semiannually) will likely confuse how your pricing is perceived by customers (see Price Meters above). This doesn’t preclude offering these terms to specific customers, and certainly not to offering multiyear terms. But it’s typically best to position those in conversation with customers versus as self-service plans on your site.

There is another category of SaaS packaging and pricing model decisions where there is some opportunity for differentiation and some degree of limited weirdness. These include:

• Packaging Models: You have basic guardrails to follow with packaging, and the vast majority of SaaS vendors follow them. You can offer a single product with a single tier, multiple tiers of a product, or a more modular strategy with a platform fee and add-ons. Without dipping into weirdness, you have flexibility to adjust the packaging strategy and the number of tiers of your product to best suit how your product serves the target customers that you serve. Yes, most companies use a tiered strategy with between three and five tiers, but that’s not a requirement, and having a few more or a few less won’t confuse customers about our pricing strategy.
• Packaging Strategy: Similarly, there are rules of thumb and norms in how you define your product offerings and tiers, but there is also room for flexibility. Most SaaS companies have usage-based tiering models where tiers are defined by a combination of features and usage entitlement limits. Usage is governed by up to five key usage factors that define the limits of a given tier. Your product may or may not have limits by tier for usage. You may use more or less usage factors for a given tier. The general constructs are in place, but there is flexibility in how they are adapted to your specific offering.
• Pricing Models: As we’ve talked about before, while there are only a few main categories of pricing models for SaaS products, there is an unlimited number of implementations of these models. For example, there are many ways that companies define users in the broad category of per user pricing. There’s flat-fee pricing, but an unlimited number of ways the product or tier that is priced with flat-fee pricing can be defined. Usage-based pricing is perhaps even broader; usage can be defined based on anything you choose. These types of combinations provide great flexibility in how pricing models can be set for your SaaS. The catch here is that we think it’s really important to take cues from the pricing models that are being used in your category, or in ancillary categories that are relevant to your product. If your alternatives are all pricing per user, and you choose to price with a flat fee, that’s OK. That alone doesn’t beget weirdness. But it puts you one step closer to having a “weird” SaaS pricing model. It means you’ll need to set up tools and systems to normalize your pricing for comparison to those alternatives, such that you can articulate your price messaging to customers. Many use pricing calculators that focus on total cost of the SaaS (versus unit costs) for this purpose.
• Pricing and Usage Metrics: This goes hand in hand with choosing a pricing model. If you use per- user pricing, that’s your pricing metric. If you use a usage-based pricing model, the choice of pricing metric (e.g., per marketing contact, per GB) follows the same decision tree as described in the pricing models above. If you choose a pricing metric that is unfamiliar to buyers relative to your product’s next-best alternatives, then you’ll have to set up systems and processes to help customers draw those comparisons. If you choose to price per GB and your alternatives price per database record, you’ll need to factor in how to compare pricing for those options. Usage metrics work the same way. If you use a per-user or flat-fee pricing model and a given product tier entitles the customer to “up to 500 marketing contacts,” and an alternative does not impose limits on marketing contacts, you’ll need a way to reconcile the comparisons.

There is one category of SaaS packaging and pricing models where there is definite opportunity for differentiation.

• Value Metrics: There’s a longer conversation to be had about value, pricing and usage metrics (which we will cover in our next post). We think about value metrics as the unit economics that define the value of your product, not necessarily the unit economics of how your product is priced, as others commonly define the term. But for the purposes of this blog, suffice it to say that value metrics are one category where you have great latitude to establish pricing model differentiation versus peers (assuming you’ve done your value and pricing research). If you’ve set a pricing model and pricing metrics that make sense to your target customers, your value metric can be whatever makes sense for your offering (again, based on your research). Let’s say that your market is aligned on per user pricing. Users are the pricing metric used for the category. As discussed above, you can choose to price by users or use another model that considers users as part of comparative price positioning (e.g., flat-fee pricing where users are a usage metric, not a pricing metric). Your value metric can be whatever makes sense, maybe it’s contacts reached, records added, emails opened. Some may choose to set a usage-based pricing model directly on the value metric, or a usage limit based on that value metric. But setting the value metric is completely independent of how your peers are defining value (since you’re defining your product’s value, not the value of your alternative’s product).

Examples of weird SaaS pricing models in the wild

To summarize, weirdness in SaaS pricing stems from (1) differentiating on things related to pricing models that don’t require differentiation, and (2) differentiating on elements that can be differentiated but not establishing clear comparisons to alternatives. The former is weird for weirdness’ sake, while the latter is the type of weirdness that stems from a complex, confusing pricing model.

For the first type of weirdness, I must agree with the crowdsourced results from Arvid’s Twitter thread — AWS is the ultimate case study. (It’s worth noting AWS is also probably a case study for our second type of weird, given the complexity of its pricing models.)

Let’s take AWS EBS storage, which is perhaps the company’s most straightforward offering. EBS has charges that are metered per GB-month and per IOPS-month. What does that mean, you ask? Here’s AWS’ explanation:

“Volume storage for General Purpose SSD (gp3) volumes is charged by the amount you provision in GB per month until you release the storage. All gp3 volumes include a free baseline performance of 3,000 provisioned IOPS (input/output operations per second) and 125 provisioned MB/s throughput. Additional IOPS and throughput can be provisioned independently and are charged by the amount you provision in IOPS per month and MB/s per month until you release the IOPS or throughput. Provisioned storage, provisioned IOPS, and provisioned throughput for gp3 volumes will be billed in per-second increments, with a 60-second minimum.”

More confused than before you read that? Us too. Basically, because EBS can be consumed via a pay-as-you-go model, you are being metered for usage by the second, which requires a math equation to get to a per GB, per month (not per GB-month) price.

My favorite example of the second type of weirdness is probably Databricks, and more broadly, the category Databricks plays in, which includes companies like Qubole, Snowflake, Dremio and Cloudera. Databricks prices by something called a Databricks Unit (DBU), which, according to Databricks, is:

“A Databricks Unit (DBU) is a normalized unit of processing power on the Databricks Lakehouse Platform used for measurement and pricing purposes. The number of DBUs a workload consumes is driven by processing metrics which may include the compute resources used and the amount of data processed. For example, 1 DBU is the equivalent of Databricks running on an i3.xlarge machine with the Databricks 8.1 standard runtime for an hour. “

Clear? Didn’t think so.

Databricks has created its own pricing unit (as have most of the others in this space). I’m not sure what Databricks considers its next best alternative, but let’s say, for the sake of argument, that it’s Qubole. Qubole prices per Qubole Compute Unit, per hour. When it comes time to articulate and position pricing, this makes it very difficult for customers to understand whether Databricks or Qubole makes sense for their requirements. The evaluation is probably done by the customer on the basis of total solution cost (i.e., Databricks is going to cost us $X for the same thing that Qubole charges $Y). This eliminates any unit price positioning that Databricks was aiming to articulate with its pricing model. This whole process creates complexity, confusion, and yes, you guessed it, weirdness in the eyes of customers and prospects.

If you would like us to rate your pricing weirdness, consider giving our free Grade My Pricing Page service a try. And shoot me a note at [email protected] with any questions, comments or feedback you may have.