Before you can answer the question, you must first define “weird” in SaaS pricing models
Author: Bryan Belanger
Author: Bryan Belanger
I recently saw a really interesting Tweet from SaaS founder, author, build-in-public evangelist and overall great follow Arvid Kahl. In this Tweet Arvid asked a seemingly simple question: “What’s the SaaS with the weirdest pricing model you’ve ever seen?”
I had a few thoughts immediately after reading this tweet.
In reading some of the replies and thinking deeply about the question in the context of our XaaS Pricing client experiences and data, I realized that even though we had a lot of experience with the topic of this question generally, I didn’t have a great answer to the actual question. That’s usually a signal to start exploring with some writing and analysis, and so, dear reader, that’s what we’re doing in the rest of today’s post!
Arvid’s tweet garnered varied, but equally interesting, responses. Many were quick to a name a vendor (or two or three) that they found to have a “weird” SaaS pricing model. Companies named included:
Tweeters cited all manner of reasoning for why they named a particular vendor as “weird.” Some had a bad experience as a buyer, some were trying to position against a competitor, and some wanted to emphasize the weirdness of their product or service as a differentiator. Others had a very specific preference related to pricing that turned them off to a particular competitor (for example, the individual that cited Chili Piper’s anti-discounting policy).
Across this wide spectrum of inputs, I saw a few major trendlines in how “weird” was defined: (1) complexity, (2) a lack of predictability stemming from complexity, and (3) bias toward certain types of “known” pricing models.
The more I thought about Arvid’s initial question, the more convinced I became that answering his question required an answer to a preceding question: What makes a SaaS pricing model weird?
To start, I turned directly to the source. I asked Arvid via Twitter what his motivations for this question were to understand the thesis statement behind the question. It turns out, he’s publishing a piece on that topic this Friday for his blog and newsletter The Bootstrapped Founder. I’ll be checking my inbox for when he shares his post, to compare notes and conclusions drawn, and you should do the same!
I suspect that many analyzing these questions may correlate “weirdness” in SaaS pricing most strongly to complexity. I wrote about the issues with SaaS pricing model complexity in a recent post for our blog. Complexity creates confusion and confusion can feel a lot like weirdness.
In thinking about this topic since Arvid’s original post, I’ve concluded I have a slightly different definition of “weird” than simply the model is complex.
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.
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:
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:
There is one category of SaaS packaging and pricing models where there is definite opportunity for differentiation.
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.
©2022 XaaS Pricing. All rights reserved. Terms of Service | Website Maintained by Tidal Media Group