I’ve been speaking to a lot of founders lately about SaaS pricing models & pricing strategy in general, and was inspired to try to tackle this topic in an EarlyGTM post.
Like everything else in life, pricing is challenge that requires first principles problem solving. Nothing I say here will apply equally to everyone, all the time. But here are a few “rules” to consider when creating SaaS pricing.
Rule #1: Take an honest assessment of your GTM DNA (bottom up vs. top down)
First, you have to figure out who can actually use, evaluate, champion and purchase your product, because pricing is heavily reliant on buyer psychology and how they think about purchasing decisions. Let’s just say there are two main flavors of SaaS: bottom up SaaS, and top down SaaS.
Bottom up SaaS usually has a bigger population of end users who can adopt and champion your product. Bottom up SaaS is typically conducive to self serve pricing, and per seat pricing. Pricing is usually reasonable (ie, not crazy expensive) per seat, but really adds up as you add more seats.
Top down SaaS has a smaller, more specialized population of people (usually decisionmakers or admins) who can adopt your product. Usually [massive overgeneralization incoming] top down SaaS must be more expensive than bottom up SaaS. Why? Because it takes longer to sell these deals, usually to a slightly smaller TAM, so you need to generate more from a sales-led, human-led effort than you’d need to get out of a self serve deal.
Top down SaaS usually works best with usage based pricing. It’s hard to sell top down SaaS based on licenses, because only a few people use the product in a hands on way, so you try to figure out a way to charge more and more over time as product usage increases. Avoid static pricing that is designed to stay the same year after year, or pricing that is difficult to increase, more on that next.
Rule #2: Deals must be set up to expand (and renew) over time
If you look at enough sets of SaaS metrics (shoutout to Ethan Ruby and SaaSGrid) you start to realize the importance of deals religiously renewing and expanding over time. This is a key SaaS metric, and the best companies have strong NDR fueled by both of these things happening in conjunction.
Renewals happen because customers feel like they’re getting 10x the value of the product compared to what they’re paying- the product is delivering on its promise, high DAU/WAU/MAU metrics, high NPS scores, etc.
Upsells & contract expansions happen because contracts are structured correctly- meaning, they’re structured in a way where renewal is a fait accompli, it’s essentially guaranteed to happen as time goes on.
I’ve seen a lot of top down contracts structured in a way where upsell/expansion language is unclear, and teams are all too happy to get a flat renewal as long as it means avoiding churn. This is a massive mistake and will harm your NDR. It’s vitally important to bake in a natural expansion reason (seat expansion, usage expansion, etc. etc.) where the customer is fully aware of the rules, and the rules for upsell/expansion appear on page one of the order form.
It’s also important for CSM teams to communicate and socialize the price increase well ahead of renewal. No matter what your pricing model, you have to set yourself up for natural expansion. If you don’t set up your SaaS company to continuously generate new revenue from upsell or expansion, you’re putting a ton of pressure on yourself to constantly generate all new growth from net new deals, which is much more difficult.
PS- it doesn’t matter when you collect your upsell or expansion, as long as you’re set up to recognize it with some frequency. It’s better of course to get paid the MOMENT a customer uses more of your product (ie, adds another license) but as long as you true up quarterly, semi-annually, or annually, you’re in good shape. You really want to avoid going several years without your customer needing to pay more, as that’s a signal that your SaaS pricing model isn’t optimized properly.
Rule #3: Price is a function of the value you provide to your end user
At the end of the day, you justify price based on where you land on the “how easily could I live without this?” scale, and this is a function of collective buyer psychology.
This is based on a few different factors: which population does your product serve, how valuable is that population, what competitors exist, how do you compare to them, and how are they priced. Products with moats have a lot of pricing power because it’s hard to walk across the street to a competitor.
If you’re a tiny startup, and you try to sell your first deal for $1M/year, it probably won’t work. Why? You’re unproven, you haven’t substantiated your value with any customers, there’s no social proof, and you probably have a competitor that’s cheaper than you.
You start to figure out where to price based on comparable analysis, and more often, trial and error. You float a number that’s probably too big, get a customer reaction, adjust based on where it “needs to be to get the deal done” and soon, you have a sense for where pricing needs to be. As you become more established, you slowly work price up over time as your product becomes more trustworthy and established, as you out-product your competition, etc.
From there, you start to figure out what vectors make sense to base your pricing on. You’re essentially working backwards: you get a gut feel for where pricing should land based on prospect reaction, and THEN you figure out the rules that make sense to justify it. That’s because, again, you can’t trick customers. They’re going to pay what feels fair, they’re not going to agree to something crazy just because you’ve created an equation that deems it so.
Which brings us to rule #4…
Rule #4: Figure out your natural pricing vectors
Try to answer the following question for your SaaS product: “when a huge customer uses our product, what is true compared to a small customer using out product?”
The answer could be:
-big customers use more seats/licenses.
-they need more advanced features.
-they require more API calls.
-they send more messages.
-they use more storage.
Whatever they are in your business, these things become your natural pricing vectors.
They work well as pricing anchors because as your customers grow (use the product more, add more seats, etc.) you get paid more with the proper pricing structure. It also creates natural barriers- if huge customers blow through their limits on any of these vectors quickly based on their more aggressive or advanced needs, those are great places to enforce pricing rules.
You want prospects to feel a light sense of pain (from not having access to the premium features) when they hit a limitation like this, and make them feel like “ok, it makes sense that I need to pay now based on my need to use more of X.”
Rule #5: You might as well anchor too high, as opposed to anchoring too low
Both bottom up SaaS and top down SaaS have the following in common: for the enterprise version of the product, SaaS companies typically don’t show pricing directly on the website, you have to talk to sales for that.
People may find exceptions to this rule, but it’s generally true, and for good reason. TLDR: pricing only goes one way (down) as you negotiate.
So you have to anchor high. The challenge at play: if you publish your enterprise pricing publicly, and it’s too high, you’ll probably scare prospects away. So the general rule of thumb is hide ENT pricing behind a “talk to sales” screen.
When sales presents pricing for the first time, you might as well anchor high and gauge a prospect’s reaction. When you’re a small startup, you can afford to meet the customer where they need to be with discounting. When you’re well established, your product has established a market price and you need to stick close to it, otherwise customers will find out that some orgs are getting a better deal and will cry foul.
No matter who you are, no matter the stage, it’s better to anchor too high (and discount if you have to) than to anchor too low.
Rule #6: Market dynamics always apply (ie- competition, moats, and buyer psychology matter)
You’ll always be compared to competitive products. Ideally, you want/need your product to be the best vs. competition, that’s almost an assumption here. If you aren’t the best product, you probably won’t have pricing power, unfortunately.
Assuming you are the best, it’s still difficult to be priced WAY higher than competitors unless you have a meaningful moat, or some X factor that renders a competitor as an unrealistic alternative. But you are still beholden to comparable analysis, otherwise you’ll upset the buyer, and they’ll perceive your pricing to be unfair.
Driving that last point home, pricing rules must make sense to a buyer and feel fair, otherwise they won’t purchase, won’t be able to plan their budget properly, and won’t renew even if you do get them to buy. Related: it’s better to undersell with proper upsell mechanisms in place, than to oversell and risk downsell or churn. The latter kills your SaaS metrics and makes your business look less exciting to new investors. It also makes it harder to grow smoothly and predictably over time.
Rule #7: Tiered pricing is your friend
I’m a fan of pricing tiers- and tiers typically work well whether you’re selling a bottom up or top down product.
For bottom up products, tiers are usually: free / pro / team / enterprise. They’re set up so that a free user can get key features in a limited way, pay with their own credit card to get key power ups, get their admin to pay with a corporate card to get key manager benefits, or get their VP to pay with a purchase order to get key org wide or leadership benefits.
At every stage, figure out who your decision maker is and feature gate based on the features that appeal to that decision maker.
For top down SaaS, tiered pricing can help you charge more per unit of your product by supercharging the feature set. Tiered pricing is also a good negotiating chip- it helps you establish and anchor a lower price so that the higher price (associated with more features and functionality) has some sort of defensible reference point. Tiered pricing slowly establishes reference points for customers, and give them a range of options where they can start to associate a dollar value with different features and functionalities.
Rule #8: Figure out your feature gates from first principles (and listen to your sales team)
Figuring out good feature gates (and proper pricing tiers) is a first principles exercise. Generally, you want to give enough features on the lowest tier that end up getting the user population hooked. Then you limit the usage of key features so that users organically run into limitations, and realize they’re not on a plan that supports their intended use case, and they feel naturally compelled to either upsell, or talk to a salesperson.
This is true of both bottom up and top down tiers, and bottom up tiering/feature gating probably requires its own article (…coming soon!)
Last but not least- it’s really hard to get tiers perfectly right out of the gate, so you need to listen to the sales team and figure out where your tiers or where your pricing in general is broken.
How do you know? What usually happens is this: sellers get frustrated in the middle of a deal cycle because they realize their proposals are not compelling to their buyer audience, and they don’t have proper leverage to motivate a customer to the highest tier. The features they’re dangling for the higher price don’t inspire or motivate prospects, and prospects are becoming upset that the seller is asking them to pay way more for additional features.
This is a clue that you haven’t optimized your tiering rules properly, and that the prospect doesn’t think the upsell featureset is valuable enough to justify the higher price point. When you design your tiers correctly, customers should feel like they have reached a natural point at which they HAVE to upsell, or the product literally won’t work for their intended use case.
Another common mistake here is that SaaS companies only dangle admin features as a reason to upgrade- SSO! Activity logs! Admin visibility! Etc. etc. You need to make sure that you hold back core end user features too. The end user functionality differential between tier 2 and tier 3 (or whatever) needs to feel substantial, and it must also feel like there’s no sneaky way to game the system and avoid paying for the higher tier.
Some companies emphasize “enterprise support” as a justification for an enterprise tier, but be careful here. You don’t want to promise the continuous involvement of human beings as a major reason to pay more, it’s not as compelling as features that can be delivered continuously and around the clock through software and starts to feel like a rip off if you aren’t getting enough out of the humans supporting you.
Final thoughts
When in doubt, your contracts must renew continuously (so customers must feel like the structure is fair) and expand continuously (so the right mechanisms for upsell/expansion must be in place.)
Because you’re tethered to this concept of a customer needing to feel like pricing is fair, you must figure out what natural vectors exist to make your customers feel like they’re getting a logically structured contract, and if you ask them to pay more year after year, they understand why.
The next rule is to charge as much as you realistically can without (a) negatively impacting win rate by a substantial amount, or (b) putting your renewals at risk.
Customers have to feel happy, basically forever, in SaaS, or your business model is broken. So pricing has to be tied to a customer feeling satisfied with the contract they have, and not motivated to check out your competition for better pricing.
Finally: moats are key (because they render competitors as less realistic alternatives) and having the best product vs. competitors is also key (for the same reason.)
When all these things are true, you’re in the driver’s seat to create a pricing model that customers feel is fair, and sets them up to ride with you for the long haul.
Thanks for reading EarlyGTM post #13!
Mike Marg, Partner, Craft Ventures
(for more thoughts on go to market, @mikemarg_ on Twitter)