Ulrik Lehrskov-Schmidt: The Pricing Roadmap: How to Design B2B SaaS Pricing Models That Your Customers Will Love

Why Pricing Is Hard

I find it truly awe-inspiring what kind of change happens in the world when a billion-dollar enterprise really decides to kick the ball and move something.

When we create a great product that brings some value into the world, we go and ask our customers what they are willing to pay for that — or we simply stick a price on it, ask them to pay, and then see what happens.

Pricing often seems like a catch-22: if you raise prices, you lose customers but gain more from the ones who stay on. If you lower prices, you gain more customers but lose out on the money (and margin) you make on each one.

I’ve seen this question — let’s call it “the Price Optimization Problem” — drive SaaS executives to the brink of insanity.

SaaS Is like a Train: It Costs a Fortune to Build but Nothing to Run.

The world’s first inter – city passenger railroad line sprung up between Manchester and Liverpool in 1830, and it was soon obvious to anyone and everyone that railroads would be the key factor between which countries made it and which didn’t. The US jumped on that wagon big time.

So, the price to move from east to west for the average 1860s American was basically all of their money, six months of strenuous marching, and perhaps their life! To the railroad companies, that was their “use case.” They knew that by building a “transcontinental railroad,” they could bring the price for a one-way ticket from Philadelphia in the east to Sacramento in the west down to about $ 6.4.

If it costs Starbucks 10 ¢ to make a cup of coffee plus another 85 ¢ in barista salaries and rent, then charging $ 1.90 for that cup of coffee is simply a 100 percent markup. In other words, they just double the unit’s cost base, which leaves 95 ¢ in gross profit to pay for general advertising, back-office administration, stock options, taxes, and all the rest. That is how literally 90 percent of businesses do pricing.

But that doesn’t work for SaaS companies. Pricing for the poor and building products for the rich is the wrong solution, but it’s also the solution I see 90 percent of SaaS companies go for. Especially the venture-backed ones, although even corporates can fall for this as well.

A land-and-expand strategy is incredibly hard to execute, and it requires boatloads of suicidal capital and more than a little luck.

Your customer is trying to get something done. And that “something” isn’t the same for all customers.

Instead of trying to price your product, you should price your customer. The solution is to charge different prices for different customers. You know, first-class vs. second-class vs. third-class tickets. So 99 percent of all SaaS businesses get pricing wrong because they are trying to “find the right price for their product,” when what they should be doing is looking at their potential customer base and asking, “How do I build a pricing structure that will properly price all these customers?”

The money is not in the price point. It’s in the price structure.

Pricing your customer and not your product implies that you have set up a structure that allows you to discriminate between different customers. The structure has two main components or tools: product packaging and pricing metrics.

• At the top, you have your capability: what your solution and organization can technically do for your customer.
• The structure is built by first separating your market into fences. Then, for each fence, you decide what is actually for sale. That is your packaging.
• Then comes the pricing model: how do you charge?
• Then, and only then, you can start building price points.
• Once you are this far, you have to validate your new pricing with your customers.
• Discounts, we talk about price execution and how to add discount model layers to your pricing architecture.
• Raising Prices, focuses on how you work with your prices over time as your product develops and how you keep track of which customers are closed on what pricing.

Scale Economics

The costs sit at the overall product level — not at the unit level delivered to the customer. For that reason, it scales.

“Strategy” is “the plan you have to gain competitive advantage, defined as a sustainable way to keep profits above the cost of capital.”

So how do you set up a superior profit formula? Well, you get scale at one of the stages of that formula:

• Units sold: lower customer acquisition cost (CAC) than anyone else.
• Unit price: higher product value than anyone else.
• Unit cost: lower cost of delivering that product than anyone else.

They translate to:

• Unit Cost — Economies of Scale
• Unit Price — Network Effects
• Units Sold — Distribution Effects and Virality

If you can combine types of scale, you have something really good.

The financial metric I use as the core yardstick of profitability is the CLTV/CAC ratio.

The components of CLTV are average revenue per account (ARPA), development and delivery costs (DDC), churn rate, and customer acquisition cost (CAC).

At its core, the CLTV/CAC formula tells you how many dollars of net revenue you get for every one dollar you spend on sales and marketing. Net revenue, obviously, is the revenue that’s left after your immediate costs are taken out.

• Cost scaling targets development and delivery costs (DDC).
• Product scaling is more universal. Since it simply increases product value, you get to decide how this applies in your case. Do you raise prices but then remain at a similar CAC? Or do you keep your pricing but then enjoy lower CAC as your offering is now a better value?
• Distribution scaling, of course, targets your CAC, lowering it for each additional customer your product gets on board.

So, cost scaling targets the numerator, distribution scaling targets the denominator, and product scaling can target either of the two, depending on how you apply it to your business model.

Critical mass scaling is the tough scenario where nothing happens until everything happens all at once.

Another scaling dynamic is the one where initial scaling is linear but then drops off at a certain level — like a reverse critical mass.

If your product is complementary to other products, customers can enjoy it and the similar offerings of your competitors.

A substitute product, however, is one where it only makes sense to have one.

The CUPID model of SaaS strategy. CUPID is an acronym for:

• Customers
• Users
• Product
• Iteration
• Distribution

The key question the CUPID model forces you to answer is “What is the value path from user to customer?”

Your users are never “just users.” They are either users who pay you (called customers), users who bring other types of users to you, who then pay you (making them distributors), or users who, by their use, become something you can repackage and sell to someone else (making them the product).

If your users are your customers, that’s straightforward.

I call that a “straight-arrow CUPID” because there is a direct relationship between the primary value your software delivers and what your customers are willing to pay for. That’s iteration. If you run the “script” of your business multiple times.

Sometimes your users are not your customers; sometimes they are your product. You ask yourself the iteration question: “What will happen over time if we keep doing this?” If we keep adding these users-who-are-not-customers, then what product is created that gives us a clear path to our real customers?

Sometimes, your users are neither your customers nor your product. That happens when it’s not immediately clear that you can aggregate them into something valuable. However, you might be able to use them as a distribution channel to get to another type of customer, who you can charge for a solution. The users-as-distributors model requires two elements to work: a push and a pull. First, the push. The structure of your use case for the basic user has to somehow reach your real customer. Second, the pull. The solution you’ve built offers some benefits to the customer above and beyond what the primary user needs. For the users-as-distributor model to work, you need both a push and a pull factor. You need a reason for the users to tell the customer they need to buy and a bonus for the customer if they do so. Which brings us to iteration. What happens if you “run the script” of your user-case multiple times?

Well, your strategic options open up. You get to pursue new paths to either existing or new customers — perhaps even with stronger distribution (i.e., lower acquisition costs) or stronger product (i.e., higher value and pricing power).

A distribution loop works similarly to a product loop, but instead of a network effect of increased product value and future pricing power, a distribution loop lowers your acquisition cost, making the next users or customers cheaper to acquire.

For the dynamics of the CUPID model to work, you need the iteration steps (i.e., each connector arrow) to be supported by both the product model and the pricing model.

Here are the guidelines for pricing in the CUPID model:

• User-as-customer: charge for value delivered.
• User-as-product: give it away for free.
• User-as-distribution: pay them.

One of the most frequent pricing mistakes I see is SaaS businesses trying to charge their distributors — essentially demanding to get paid to get customers.

Every straight arrow (users as customers) produces economies of scale through increasingly better unit economics for every new customer. Every “up-arrow” (users as product) produces product-value-scaling opportunities that increase product value and are, therefore, essentially free development costs you can convert into revenue with a straight arrow. Every “down-arrow” (users as distribution) produces distribution scaling and reduces the cost of acquiring new customers and users.

Product Model

Your product model is what you decide to sell to whom. It’s what your customers buy from you in the broadest possible sense.

All these things have to support each other in such a way as to build more value than your costs of delivery and development would warrant — or create distribution mechanisms to reduce your customer acquisition costs. Or both.

This is exactly the “eco” part of “product ecosystem.” It’s the interplay and “larger-than-the-sum-of-its-parts” that should work, not some particular feature or subset. At the more granular level of your product model, you have your specific use cases and value propositions.

I usually work with two overarching design principles to help tech businesses design their product models at this level: Fencing: the separation of your customers into overall different categories (e.g., train passengers vs. freight transportation). Laddering: the product structure within a fence that guides the customers’ purchase, usage, expansion of that purchase, usage over time, and finally the price they pay (e.g., first-, second-, and third-class ticket structure for passengers).

If you have fenced B2C and B2B separately, for instance, then you can deliver one product to consumers and charge them in a particular way and do something completely different for businesses — without either one of these fences likely worrying about this too much.

“Is there an obvious way to separate our customers into distinct categories that will make all subsequent packaging and pricing easier?”

The rules of fencing are that each fence should be:

• Discreet: must be clearly definable by both you and your customers.
• Stable: must be “unjumpable.”
• Fair: should, in most cases, be seen as fair enough to be publicly available.
• Obvious: if it feels awkward, it probably is.
• Valuable: should provide a minimum + 30 percent CLTV / CAC contrast to be worth it.

It’s the discreetness and stability of fences that make them different from what you might call marketing segmentation. They are not the same thing. Marketing segmentation is an optimization component of your acquisition model.

The rule of thumb is that each additional fence you create should add 30 percent of CLTV/CAC (e.g., going from 5.0x to 6.5x) as compared to not having that fence in place.

Fences I’ve Used More than Once Vertical:

• Company type (subvertical)
• Distribution chain
• B2X
• Sector
• Cloud platform
• Regulatory category
• Core systems

Top-down packaging is essentially how most SaaS businesses approach their packaging. They try to create packages that revolve around a particular theme, use case, or technology.

I call this a product ladder because the packaging shows a particular theory about who the customers are and how their use will rise over time.

To work commercially, a product package should have its own source of demand. Or, put simply, your customers should be looking to buy this already.

Intentionality is an absolutely necessary component of what we call “demand” for a product or service. The customer has to have some idea of an “end state” they want to arrive at — not just a situation they don’t want to be in. It turns out that to have an effective call to action, the action has to be already there for you to call.

This is the core issue with the traditional good-better-best approach used to create the three-tiered SaaS packaging that you find everywhere in the form of basic, advanced, enterprise tiers or silver, gold, platinum, etc. It focuses on the functionality of your product, essentially spreading it out over three tiers. If you are lucky, the best tier is actually focused on a job the customer is looking to get done. But, more often than not, it just confuses the message and sells inadequate good versions of your solution to customers who really ought to buy best.

Every package should have a clearly defined problem that it solves, with clear and present demand from customers to solve that problem. Every feature and service you have that helps solve that particular problem gets into that package — even if that means putting your new, shiny advanced feature into your most basic package.

When you flip the packaging to reflect your customers’ jobs to be done, instead of the capabilities of your solution, several good things happen immediately.

• First, your customer instantly understands what she is buying.
• Second, you can actually price these packages because the customer’s job to be done has a clear value associated with it.
• Third, packaging that is driven by jobs to be done is just easier to sell. Not only because your customer gets what you’re selling and can clearly connect it to their own economics, but also because it clearly shows that you — the solution provider — know what the job is!

Once you are clear on what packages you have for sale in your product model, you have to decide how each of them can be selected through a structure of tiers, modules, or add-ons. This is what is called a product’s choice architecture. First, you should determine if parts of your product are a mandatory purchase. The decision about whether to make something a module or an add-on. If the customer buys this after the purchase of the base package, then this is a module. Make the package only available to purchase once the customer has already bought some other level of product, and then it’s an add-on.

Services have several key functions for the growth of your SaaS business. They are not the product itself, but they help customers get value out of the product. Onboarding and migration services help them get started. Support, training, and professional services help them get value out of the day-to-day use of the product. Same with bespoke development, configuration, managed services, and so on. Services are easy to monetize because there is such an obvious cost element on your side when delivering them.

From a choice architecture perspective, most services should function as either base offerings — i.e., something the customer simply has to buy — or as an add – on that is purely optional as long as any other product is purchased.

Sometimes, if you have quite distinct use cases but not many potential jobs within each one, it’s better to use a tiered product model for price discrimination across customer segments. This is called implicit fencing, and it creates a structure where every potential customer has one — and only one — package they should buy, and you have plans to upsell them to a more expensive package. Using your tiered model to price discriminate across customer types is essentially an implicit form of fencing executed at the feature level.

The other use of a tiered model is to design it to power a land-and-expand strategy. This is what I call “laddering,” as the product is designed in stages to take the customer from A to B.

One key question to get right in a laddered, tiered model is what step to put at the beginning of the ladder. The simple answer is that whichever of your potential jobs is easiest to sell goes at the bottom of the ladder. I call this the “point of first demand,” which is simply the job around which you have the most articulated and accessible demand stream to tap into.

There can, of course, also be technical reasons why one package must structurally come before another. Once you have the bottom step of the ladder — your “land” package — you have to determine the second tier. I see a tendency to try to make the second tier what the customer ought to want to buy — rather than focusing on what the customer actually wants to buy. Usually, the customer wins that argument.

“By solving this first job for my customer, which job emerges next as the most pressing to solve?” Often, this second job is one that it is now possible to do because of something you solved in the first package.

If you want your customers to upgrade from “advanced” to “enterprise” in your product ladder, you better have designed “enterprise” to appear to be the perfect solution to whatever job your “advanced” customer is trying to get done. If it’s a ladder, design for the transitions and the journey. If it’s implicit fencing, design for the underlying segments.

The axis or theme of the ladder in a tiered model is a conceptualization that you use to understand your market and to which you fit your product. It’s not something that is just out there in the world waiting for you to discover.

When we are doing top-down packaging, we’re in design-thinking mode. We’re trying to create something that works, not something that’s “right.”

This point is crucial: the high end of the product ladder helps sell the low end — the starting point. I might not be ready for “management” because I need to solve “maintenance” right now, but I like the prospect that your product can take me there when I’m ready.

The top-down approach to product packaging:

• Fence your customers.
• Implicit fencing or product ladder.
• Each package has to solve a job, not a problem.
• Start with the point of first demand.
• Organize your product ladder on an axis.
• Have Product and Sales align on the story.

Pricing Model

There are zero instances of profitable, publicly traded B2B SaaS businesses with simple pricing structures, but there’s this unwavering belief that simple pricing equals growth, despite all the contrary evidence in the world.

What you really want is for your pricing to be easy to sell, and that is not the same thing as making it simple. You have to balance the two core elements of what a pricing model is to get this right: A pricing model is the mechanism by which what your customer buys determines what they pay. A pricing model structures how that price is different from customer to customer.

That’s the problem with simple pricing: it overvalues the first element of what a pricing model is — calculating the price for the individual customer — and undervalues the second element — the discrimination between different customers.

Willingness to pay is affected by what that hundred-user customer can see the five-user customer is paying, even though in principle, they should be totally unrelated.

Complexity is a tool you use to price discriminate between different customers. The rule of thumb is that the larger the ACV, the more complexity you need.

There are three basic elements, each of which has three sub-elements.

• Transactional Nonrecurring Fees. This is any charge that you put on your customer that isn’t perpetual or recurring in nature but is, instead, transactional. In a SaaS context, there are three sub-elements to this, which are organized before, during, and after the core as-a-service relationship with a customer:
  • Setup fees: Any and all fees you charge as part of onboarding the customer.
  • Ad-hoc one-offs: All the transactional fees you charge the customer during their lifetime with you.
  • Exit fees: All charges you put on the customer as parting gifts.
• Flat Fees. These are charges that do not change or fluctuate depending on a metric. There are three basic sub-elements to flat fees, ordered according to how dependent they are upon customer choice:
  • Flat base fees: These are fees that occur as a consequence of a customer’s core product choice.
  • Flat add-on fees: These are flat, recurring add-ons that you charge your customer as the consequence of some product choice but do not feel are suitable to be tied to a metric.
  • Flat non-optional fees: Recurring flat fees that are not the result of some particular customer choice but are added regardless of what your customer chooses to buy. These fees do not fluctuate by any metric.
• Metric-Based Fees. These are perpetually recurring charges that are dependent on some metric. From a pricing-architecture point of view, metric-based fees are structured just as flat fees with three basic sub-elements, ordered based on how dependent they are upon customer choice:
  • Metric-based license fees: A license is a right to use something; the classic SaaS example being a user license.
  • Consumption and usage-based metrics: Consumption-based metrics are all metrics that are charged based on the behavior of your customer (or your customers’ customers), but where the volume or amount purchased is not determined prior to the charge but rather post-fact as a measurement of interaction with your solution.
  • Credit-based metrics: Credit systems are a hybrid model between licenses and consumption-based metrics. Credits are a right to consume or use something at a later stage, but the usage is estimated and paid for upfront.

Importantly, the type of metric-based fees shifts as the ACV goes up. For low ACVs, expect a large proportion of metric-based revenue from base subscription fees. For large ACVs, expect a relatively large proportion to be based on consumption-based metrics.

What is a good pricing metric? I use the following four parameters to evaluate pricing metrics:

• Operational viability
• Demand and value-chain position
• Expectation to pay and fairness
• Metric density and monetization

Operational Viability. The first parameter is whether a pricing metric is practically usable. This usually comes down to a binary yes/no answer to the following two questions: Can we measure it nonarbitrarily, and can we execute our financial process to invoice based on this? You can only price based on something you can reliably and nonarbitrarily measure and present in a timely manner to the customer who has to pay for that measure.

This is the first intuition that most SaaS companies try and execute in their pricing models: to have metrics track value generated, based on the premise that higher value should equal higher willingness to pay, all else being equal. The only drawback is that it’s a false premise. At least in some instances, which is enough to create major problems in your pricing model. Even if metric tracks value perfectly, that doesn’t necessarily mean that there is demand for it; sometimes customers actually want to buy as little of it as possible! Often, high use of discounts is a clear sign that you have an issue with your packaging or pricing.

If you attach your pricing at the beginning of your customer’s value chain, your expansion sales cycle takes as long as it takes the customer to execute their value chain.

A good principle for designing pricing in SaaS is for your value chain to be aligned and intertwined with that of your customer: you support them at the beginning, and throughout, with your product and share value at the end through pricing. Value chains are like rainbows: the gold is at the end.

Value isn’t the only determining factor in willingness to pay. Your customer has to have an expectation to pay as well. Value determines if they want what you have, but expectation to pay (ETP) determines if they think it’s fair for you to get paid for it.

Expectation to pay is determined by three things:

• Habit: Is this how you’re used to paying for something like this?
• Cost transparency: You have a high expectancy to cover the costs associated with what you buy — if you understand them.
• Similarity: Especially when it comes to a new domain or purchase, we tend to accept it as fair if we’re introduced to a pricing model that is very similar to something we already know.

For simple pricing models and lower ACVs, it is by far the best approach to find a “fair value pricing metric” that hits that sweet spot combination of value and expectation to pay for your product.

However, for larger ACVs, which usually have more complex product structures and larger customers, a fair value metric might not do it on its own.

Lyfegen is a Swiss insurtech company that handles repayment flows between insurance and pharma companies. Repayments are a specific form of discount that pharma companies give in the form of repaying parts of the original price at a later point in time, depending on how well a drug or treatment performs in a clinical setting.

Low density of a pricing metric is created by one of two scenarios, depending on how the value that it is tracking is distributed across the metric: fat-tailed bell curves and power law distributions.

Power law distributed value happens when most of the value of a given metric is lodged in a few units of that value. The rule of thumb is this: the median value of your pricing metric should be as close to the average value as possible.

In principle, a fat-tailed distribution of value should create the same issues as a power law distributed value metric: many unit instances are going to be below your price point, so customers should argue for lower prices and — post – sale — try to only send through those units that are clearly worth more than your price point.

If you have a low – density pricing metric in place, you can do one of two things: find another metric altogether, or try to define your current metric to more closely fit the customer’s value.

There are several ways to gauge and measure “value” and “expectation to pay,” as well as metric density (see the sidebar on this one). Usually, the core team who has to decide on pricing can get the job done with a simple one-to-five Likert scale for value, fairness, and density, while a few yes/no type questions will sort out the operational viability.

The density of a pricing metric can be quantified as follows: median value divided by average value multiplied by the share of metric units that has a value at or above the median value.

Generally, This Pattern Holds True for Metric Density:

• Density 0 – 0.25: poor monetization of value created, with several critical issues in both the sales process and product adoption.
• Density 0.25 – 0.50: subpar monetization with some issues in the sales process and product adoption, often with heavy discounting and sales cycles extended by negotiation.
• Density 0.50 – 0.75: strong monetization with only minor issues.
• Density 0.75 – 1.0: excellent monetization.

If you have a packaging model that allows it, covering several modules, add-ons, etc., you can use different pricing metrics for different packages as they apply to functionality and the job to be done.

This is also a matter of managing the right level of complexity and balancing it against the monetization potential of your pricing architecture. Ultimately, it has to be communicable in a sales situation.

If the pricing model clearly communicates that a portion of the charge you are asking your customer to pay is simply covering your costs, then those parts will be left alone in 90 percent of negotiations.

Simple is good only if you are selling primarily to one type and size of customer. If you cover a range of differences in your market across type, need, and size of customer, you need to add complexity to your pricing architecture to structure the sales properly.

Wallet Structuring

I call this committee of buyers “the Wallet.” Because — just like an actual wallet — the Wallet of an organization consists of various compartments, each with its own distinct function, some of which hold money.

If you are selling a multimillion-a-year solution to a global organization, you can bet you are going to have to meet with everyone.

The sale itself is a project with Gantt charts, several stages of co-creation, bespoke development, and, finally, eventually, maybe, the signing of documents.

If you understand it well and adapt your pricing structure to it correctly, the Wallet can be used to your distinct advantage. Because the customer’s budget structure usually follows its organizational chart pretty closely, each of the stakeholders involved also has a budget. So that gives you a budget structure onto which you can map your pricing structure.

The rationale is simple: make everyone pay. That means that every stakeholder whose part of the organization your solution touches, and who participates in the committee that decides whether to buy it or not, should (or at least could) be asked to pick up part of the bill.

Compliance is used to paying for reports, audits, and security measures. IT is used to paying for storage, cloud computing, API calls, developer hours, and so forth. The COO of an industrial cleaning company is used to paying for staff, floor scrubbers, and leases on cars.

The core principle, which is illustrated in the Pricing Perception Matrix is that your primary buyer is the one who pays for the value, while all the auxiliary buyers pay primarily because of expectation to pay.

The honest-to-God truth is that it’s extremely difficult to truly evaluate the real value of any piece of enterprise software.

The process of fitting your pricing structure to your customer’s budget structure to maximize the “co-pay” from budgets that are ancillary to your primary target budget is what I call “Wallet structuring.”

This is a crucial point: the expectation to pay for a certain item usually carries with it some sort of reference price point from your customer’s side.

However, it is very important to understand that this does not mean that you can’t charge way above cost on those items. You just can’t charge way above perceived costs.

The process is as follows: List the things you are currently delivering. Group them into categories — each targeting a specific customer budget. Evaluate each budget owner’s expectation to pay for each line item in the category. If a reference price exists in the market, note it. If it doesn’t, estimate as well as you can. The rule of thumb (which definitely has exceptions) is that the budget of your primary buyer should carry about 50 – 80 percent of the total price load.

How do you ask customers to cover their own costs when it’s not straightforward just what costs to attribute to them? After all, they were all running on the same platform.

We simply need to find a metric that tracks the costs, not necessarily one that causes them.

Unlike the pure Wallet structuring exercise, where you simply list all the things you deliver, a cost-proxy exercise like this can come up with a metric (such as # EndClients) that isn’t really something you deliver but nevertheless can be good for pricing insofar as it can communicate some value you bring or be openly used as a measure of the costs you have.

If you’ve ever been in a discussion about whether to price according to the value you bring to the customer or simply do a markup of your costs in a “cost-plus” fashion, now you know the answer: do both.

The pricing structure design of a € 100M ARR insurtech product:

• Sales purpose: First, we decided how Sales should communicate around the category. The solution was where we knew we had demand, so that was where we communicated value. Conversely, for IT infrastructure and services, we communicated the costs we’d have, driven by deep operational processes and so forth. This, of course, also has value, but we realized the customer has a satisficing mindset around these issues; unlike the solution, they don’t drive demand.
• Target customer budget: Each of the three categories was assigned a target customer budget or budgets. We knew that the business line had to pay for the operational costs of not only the licenses of our SaaS platform but also many of the ongoing services.
• Profit principle: We used cost proxies to load costs onto IT infrastructure and services and decided to not mark these up but simply use the revenue generated here to break even — even if we priced the “solution” part at zero. In that way, we could then use the pricing of the “solution” category to determine the annual profits derived from the individual customer, since whatever we priced here would be pure profit as we’d already loaded all costs into the two other categories.
• Discounting: Finally, we guided Sales on how to negotiate pricing with customers to ensure that discounting supported the profit principles. Since IT and services were almost pure cost pass-through, it was easy to convince Sales to simply not give any discounts on these items. Conversely, Sales got more discounting power on the solution category, as well as a framework to calculate margins on the sale.

Price Points

Prices are not high or low on an absolute basis — only in relation to something else.

Anchoring, however, is not a pricing strategy because you often don’t get to determine what your customer is anchored to. They might be anchored to what they are paying now for the old solution you are bidding to replace. Or they might be anchored to the budget they set aside to solve this problem. Or to the market analysis that they’ve made of you and your competitors.

Prices are never “absolute.” They are always “relative.” And what they are relative to is driven by two primary factors: the presence of competition and the sophistication of your customer.

Sophistication, in this case, is an overall measure of how much information asymmetry exists between you and your customer. Customer sophistication is driven by four factors:

• Frequency: How often they buy what you are selling.
• Insight: How well they understand the value you can bring them.
• Data: How much data they have access to on competitors’ prices and products.
• Priority: This is a bit of a fudge factor, but it reflects the fact that some customers simply care less about how much they pay.

The Behavioural Pricing Matrix maps out the four basic price-anchoring scenarios you get when you combine information asymmetry with competitive pressure: cost-based, niche-based, perceived value, and fair value pricing.

• Cost-Based Pricing. With a sophisticated customer and plentiful competition, your customer’s price anchor will be your cost base. They will not try to press your prices to zero. They know that is impossible. But they will try to press your profits to zero.
• Niche-Based Pricing. This is the situation where you have lots of competitors offering a relatively similar product, but your customers just aren’t that sophisticated. Niche-based pricing is often found in larger markets with lower ACVs, such as accounting software, design software, productivity software (e.g., Asana, Trello, Monday.com), and so forth. Your best option in this quadrant is to carve out a niche by positioning your product to reduce acquisition costs and decrease your prospective customers’ sense that they can find a product that better fits their needs elsewhere. Anchor: the transaction costs of finding a better price.
• Perceived Value Pricing. The Cambridge Dictionary defines value pricing as “a way of deciding the price of a product, based on what customers think it is worth and on what they are willing to pay, rather than on what it costs to produce.” If you are selling something unique to unsophisticated customers. In that case — and only in that case — your customers will try to relate the price you are asking to their perceptions of its value. Perceived value pricing is, however, not necessarily the best quadrant to be in, as customers’ perceptions of value can be highly inaccurate and volatile. If they don’t immediately “get it,” you might be in deep trouble because they essentially undervalue your product. And I’m not a big fan of educating customers. Anchor: the customer’s perception of your product’s value — for better or worse.
• Fair Value Pricing This, I think, is the right place to be for most enterprise software with higher ACVs. You sell something unique to an informed buyer. In that situation, your customer already knows all about the alternatives available, what they cost, what value they bring (or don’t bring), and why they would prefer to buy from you. Anchor: a fair share of the value generated by the relationship.

Remember, the money is in the structure. If you’ve built the railroad, your monetization is going to be first dependent on your fencing of passenger vs. freight, to allow you to build different models for each. Next comes the packaging, which is then followed by the pricing architecture that maps on top of it. If you have gone that far, your structure is already doing all the heavy lifting to ensure you price the customer and not the product.

There are basically four methods you can use to determine price points:

• Internal expert judgment
• Price experimentation and discovery
• Customer surveys and interviews
• Statistical prediction models

Internal expert judgment is simply asking your own team what they think customers would be willing to pay and then having a discussion about it. Before you run this exercise, however, it helps to have a few things down: fencing, product packaging (i.e., “what jobs to be done” are we addressing), discount drivers, and Wallet structure.

I often use a Van Westendorp price sensitivity survey, which asks these four questions (in this order):

• At what price would you consider the product to be so expensive that you would not consider buying it? (Too expensive)
• At what price would you consider the product to be priced so low that you would feel the quality couldn’t be very good? (Too cheap)
• At what price would you consider the product starting to get expensive, so that it is not out of the question, but you would have to give some thought to buying it? (Expensive/High Side)
• At what price would you consider the product to be a bargain — a great buy for the money? (Cheap/Good Value)

The more internally consistent the answers from your various team members, the more you can assume that a real “signal” from the world is coming through, and you are actually getting useful information about what your customers would pay. But if the answers are all over the place, the “noise” is still far outweighing the useful information. You simply don’t know yet.

Price Experimentation and Discovery. The second option you have for setting price points is experimentation and discovery: setting some price points, seeing what happens, and then adjusting accordingly.

You want to set up experiments that establish the following, in the following order: Is the packaging right? Is the pricing model right? Are the price points right?

It’s crucial to understand that the key to running price experiments at high ACVs is being able to distinguish between two types of “no.” The first is a rejection of the structure, which essentially shows itself as a lack of demand. The second is a refusal to settle at a particular price point, despite the presence of demand.

When it comes to companies that are mainly dependent on inbound sales, I suggest testing at two levels: the pricing page of your website and the inbound sales conversation.

There are three main differences in price-point testing between inbound and outbound sales.

• First, inbound leads are already prequalified by your marketing, so assuming you have some form of public packaging and pricing the customer has already checked out, there should be a lower likelihood of being misaligned with the customer on structural issues related to packaging and the pricing model.
• Second, it’s way harder to tell if the customer is rejecting the structure of your packaging / pricing or the price point itself in inbound sales. You usually are not face-to-face with the customer; you will have fewer conversations; the conversations you do have will be more scripted; and the product is less configurable at mid-low ACVs, so there is less exploration of the use case by the sales rep.
• Finally, the ACV on inbound sales is likely to be significantly lower than on outbound, so the risk of losing any particular customer is probably bearable.

In my experience, most B2B SaaS products have significant unlocked pricing power if their packaging and pricing models are well designed.

Customer Surveys and Interviews. Customer surveys are great if you know how to use them — and how not to. The main issue is that it’s much harder to get quality respondents than you’d think.

Here are the segments I usually use in customer surveys: A Max-Diff ranking of twelve to fifteen select functional and service features, a few of which are roadmap features. A simple ranking of two to five commercial features. A simple ranking of potential pricing metrics. A Van Westendorp price sensitivity survey Lots of free text fields and open-ended questions.

Statistical Prediction Models. When I talk about statistical price modeling, I refer to the kind of predictions that tell you who will buy what at what price.

At its core, a statistical-pricing model should be able to tell you with reasonable precision the likelihood that a given customer will buy a given product at a given price. It’s a prediction game.

There are two major ways in which statistical modeling differs from basic Excel-based models. The first is the way it treats customers. The second is the way it works from an operational standpoint.

Statistical modeling differs from basic Excel-based exercises on a computational basis by treating each customer as just that: one customer, with all their individual qualities, preferences, history, etc. This is a massive breakaway from the traditional marketing-prediction methodology, which works with “segments” and “personas” to make sense of large and unwieldy data sets and problems.

Modeling preferences for sets of attributes and features is important, as some features can have more value together than they do individually.

These preferences can be generated through analysis of your sales and CRM data (known in pricing parlance as “revealed preferences”) or survey data (known as “stated preferences”). Good price-modeling software should integrate the two to create a strong, unified model of customer preferences across all available data sources.

Today’s most advanced statistical-price modeling looks at the prediction of conversion rates as an information problem and tries to solve it with Bayesian-inference modeling.

Price optimization happens when you run several predictions, compare them for outcomes, and implement the one you believe will best fulfill your objectives.

There are two bottlenecks to generating value from price modeling: the rate and quality of the data you put into the model and the operational implementation of the results and insights you get out of the model.

There is a deeper point to be made here, which is that the true value of price optimization doesn’t lie in the initial optimum being generated but rather in your newfound ability to generate optimums when you need them.

This iterative cycle of prediction — implementation — measurement — calibration — prediction is critical for generating value from your pricing over time.

Validation

There are generally four ways to build your confidence that you’ve got good pricing: It makes sense to you. Customers have told you it makes sense in interviews. You have good survey data to indicate that it makes sense. You have actually sold products at those prices in the market.

I actually think the term “product-market fit” is misleading because real traction only comes when you have a really good overall commercial model, which covers your acquisition model, your product model, your pricing model, and your service model.

Your focus, first and foremost, should actually be on the customers you, for some reason, don’t manage to serve — the ones who say no to your proposition — because the ones who say yes are now already served.

Look to the ones who say no because they hold the key to your improvement. Remember, they want to buy, and you are doing something to prevent that. Find out what it is and fix it.

So, seek out those who say no and ask them, “Why?” Then shut up and listen. Be genuinely curious. Listen for the quality of the no.

So, listen to the quality of the no. What kind of a no is it? Is it a “demand no?” Or a “structure no?” Or an “I-didn’t-understand-what-you-just-said-to-me-so-I’m-just-playing-along-to-be-nice no?” Try to use your framework to identify the issue: Bad capability? (e.g., the core solution is not good enough for the job to be done) Bad fencing? Bad packaging? Bad pricing model? Too expensive? Poor communication of any/all of the above?

If your pricing “sort of makes sense,” it’s probably not good enough. If your customers “should” or “ought to” understand and accept your pricing, it’s probably not good enough.

I usually advise my clients to book three to five interviews, of about thirty to forty-five minutes each, with current or prospective customers.

I then put together a five-to-twelve slide presentation with the following structure:

• Company presentation (if you must).
• The job you are trying to solve.
• The packaging of the product (including fencing).
• The packaging plus pricing model.
• The packaging plus pricing model plus price points.
• The packaging plus pricing model plus the price points of add-ons, services, etc.
• Any number of FAQ-type backup slides if you foresee certain tricky questions that might need attention (e.g., a visual showing a discount curve, information about how resellers are paid, the packaging for the fence that this customer is not part of, etc..

At each step in this process, you show them your slide, give them a minute to take it in (don’t talk), and then ask: Does it make sense to you? Do you see yourself fitting into this model? (e.g., “Which of these packages would be for you?” or “Does this pricing metric work for you?”)

Pull out the third question: What should we do instead, then, to create a [packaging/pricing model/price point] that you’d like?

Remember, no price is in itself high or low. Price is always evaluated in relation to something else. The interesting thing for you is what that “something else” is.

If you don’t come out of a round of customer interviews like this and feel elevated and pumped about your product and offering, chances are it’s not going to have the product-market fit you’re looking for.

For ACVs above $ 1,000, I believe interviews are much better at validating new packaging and pricing than surveys.

Market testing validates the whole, combined proposition of product and pricing as they are being executed in your customer-acquisition model. But just as it is hard to predict the interplay of all these moving parts in your new commercial model before the launch, it is equally hard to then pinpoint what parts of the process are at fault if the mojo just isn’t there.

Discounts

Discounts are a powerful tool, and for that reason, they can be powerfully misused. Good discounting can be achieved, however, when you reduce prices for some customers, some of the time, for some good reason. If you reduce prices for all customers, all of the time, for any old reason, you are probably aware you have a problem.

There are generally two types of discounts you should focus on getting right: Structural discounts and Sales discounts.

The general rule is that the more volume the customer is purchasing, the better the unit price they will expect.

Due to commission structures, the loss of a sale means far more to the individual sales rep than it does to the business as a whole.

Structural discounts are simply predetermined discounts that are often openly shown to customers in negotiations. They work to preempt the majority of the discount needed for higher volume sales, which in turn reduces the need for sales discounts.

There is a larger point behind this: discounts should not be owned by Sales. Discounts should be owned by either Senior Management or a designated Pricing Function in the organization, both of which have the economics of the product as a whole in mind.

The centralization of discounting — just like the centralization of pricing and packaging — forces you to create a joint understanding of the offering you are taking to market across Sales, Product, Marketing, and Senior Management. The economic unit now is the product (which can scale) and not the customer (which can’t).

If the customer reaches a new volume tranche, should you then apply the discounted price to all units the customer has? If you do, then you are using a “threshold model”, where the discount is universally applied once the customer passes through a certain threshold. The alternative is to only apply the discount to those units above a certain volume, creating a “waterfall model” where the first units have a higher price than the last units.

So, threshold dynamics are good if you want to drive adoption and volume expansion in your accounts. If that is not the case, you should go for waterfall dynamics.

One mistake I often see with structural discounts, and price lists generally, is that they are not big enough. Always build your pricing structure big enough so that your largest potential customer would only be about two-thirds into the model.

One of the key tenets of negotiation is that your counterpart is not going to accept an agreement if they think there is still a better deal to be had. The psychology behind this is that we’re hardwired to try and avoid regret.

In almost all cases, customers don’t bargain to get a better price. They bargain to make sure they’ve got the best price there is. The difference is key. Sales discounts mainly function as a communication tool to let the customer know that they have the best deal possible and will not regret buying at this price.

Again, sales discounts are a communication tool, and as with any communication, the delivery matters more than the message.

You should also always only offer discounts in a quid pro quo format, where you ask for something in return for the discount.

Essentially, there are five types of sales discounts. I usually advise my clients to offer them in the following order of priority, starting with the most preferred type at the top.

• Time-Limited, Short Duration. The benefit of the time-limited discount, besides actually helping to close customers, is that it leaves your run-rate ARR growth completely unscathed.
• Time-Limited, Long Duration. This means extending the time-limited discount for longer works as a compromise between full-on permanent discounts and no discounting at all.
• Terms and Conditions. Another form of sales discounts is to offer better terms and conditions. This can include better payment terms, better cancellation terms, guarantees of no price increases for three years, and so on.
• Upsell with a Permanent Discount. If you can’t offer a time-limited discount in some form or close the customer with better terms, then the last line of defense before you offer an outright discount on the purchase is to try and simply offer more of the product instead.
• Permanent Discount on Preferred Product. Finally, of course, you can also give a straight-up, permanent price reduction on the product preferred by the customer.

Your sales reps will only use the discounts you allow them to use. So, the most straightforward way to control discounts is to create standard operating procedures (SOPs) that determine who gets to use what discounts when.

The most basic form is escalation: above a certain level of discount, the rep has to go to Sales leadership for approval.

One special type of discounting remains to be discussed: the discounts you offer to customers who you’ve already closed. These post-sales discounts are used to prevent churn, and they can be done either by “grandfathering,” being proactive, or being reactive.

Grandfathering is the practice of not raising prices for some or all of your existing customers, even though your list prices overall are increasing.

In rare instances, you can offer to lower existing customers’ prices, either temporarily or permanently.

Sometimes, you lower prices simply because your existing customers want you to.

Raising Prices

You should probably raise your prices at least annually, if not quarterly. Here is why: you are selling a SaaS product. That implies you are going to keep developing the software over time, not only ensuring the continued function of existing use cases but also improving them and adding new functionality to power new use cases.

Contractually fixing prices indefinitely into the future with no easy mechanism to raise or update them without triggering a renegotiation is one of the most common mistakes I see B2B SaaS companies make.

The core problem isn’t keeping up with inflation but rather how to keep monetizing your own product roadmap over time. There are two immediate, intuitive solutions to that problem: spin out new products to sell, or keep new functionality in your core product and raise prices. I call the first approach hydra products and the second monoliths.

A hydra product is one that grows in complexity because every new functionality is introduced as a new module or add-on purchase — even when that makes no technical or commercial sense. So, by spinning out functionality into an add-on, you do get to monetize it. But all your core cost components go up: customer acquisition costs, cost to serve, and cost to develop. You see hydra products everywhere as “legacy tech” in the market.

If you’re not going down the hydra route, the second obvious solution involves building a monolith (i.e., continually adding functionality to your core product). In contrast to hydras, monolith products die from under-monetization. As the customer is unlikely to find uses for all the functionality in the monolith product, they are justified in feeling that they are paying for functionality they don’t want or need — unless they get a discount.

Perversely, the distance between Sales and Product grows with monolith products because it becomes less and less clear what the SaaS business is trying to achieve for customers.

First, you have to keep your packaging integrity at all times as you develop your product. Every package should be directed at a particular job that the customer has to do. When your new functionality solves a distinct new job for your customer, you should create a new offering around it. That is how you avoid becoming a monolith. But if your new functionality simply helps solve one of your existing jobs so it can be done better, it should be added to whatever offering you’ve already built around that job. That way, you don’t become a Hydra. Then, second, you should reassess price points often and change them accordingly, which in most cases means raising them.

Your SaaS contract should:

• Give you a perpetually recurring legal and commercial relationship with the customer (i.e., no fixed end date).
• Enable you to change prices and discounts, products, and operational terms and conditions without renegotiating the contract.
• Be the same for all customers to allow bulk handling and changes.

B2C SaaS businesses are, by and large, better at capturing product value by continually updating their offering and pricing. When it comes to B2B, though, it’s a different story.

If the contract isn’t perpetually recurring, you will have to renegotiate it on a recurring basis, which means recurring sales costs.

If your contract framework is unstable, and you end up with twenty different contracts for twenty different customers, it becomes operationally impossible to go back and change anything. This has a snowball effect as you grow.

The lack of flexibility in the network of legal agreements you have with your customers is actually a large contributing factor slowly pushing you into becoming a hydra or a monolith.

Here is the paraphrased version of a good B2B SaaS contract: [Customer] is a customer of [SaaS business] until [Customer] chooses to cancel this contract as per [cancellation terms]. This contract is governed by [general terms, definitions, legislation, etc.]. The [Customer]’s purchases at any time are given in [Appendix 1 — Overview of Selected Purchases], which will be replaced in full if purchases are updated. Prices and payment terms are listed in [Appendix 2 — Catalog of Products and Services] and are subject to change. For an overview of the current setup of our joint operational relationship, please refer to [Appendix 3 — Playbook], which is subject to change.

There are two key features of this setup. First, your prices and product descriptions actually sit outside of the framework itself, together with the operational features, in appendices that are subject to change whenever you decide they should change. The second key feature follows from the first: precisely because the content of the purchase is subject to change at your discretion, this contract framework never triggers a renegotiation, which puts you in a vastly better position.

To maintain integrity and standardization across contracts, you should ensure that a large block of the contract is simply never negotiated and never can be negotiated. The aspects of the contract that are negotiable (i.e., the catalog of what is for sale and some specific terms) should be determined by Sales management, not sales reps.

If the customer wants transactional purchases, like an implementation project or some other one-off, that should be put in a separate contract, which can be added to the core subscription contract as an appendix, if necessary.

Salesforce famously offered 90 percent discounts on the first year of their subscriptions, followed by 80 percent the following year, all the way down to a zero percent discount after ten years. By which point, whoever made the decision to buy was probably long gone.

There are two ways to raise prices for a SaaS business: you can raise prices for new customers only, or you can raise prices for both new and old customers.

Raising prices for all customers simultaneously is operationally easier as you only have to run one line of communication to everyone. On the downside, the risk of churn and serious customer satisfaction issues are considerable across your entire customer portfolio on your new pricing.

Maybe you don’t want to raise prices for all your customers all the time — enter the concept of “pricing cohorts.” A pricing cohort is simply any group of customers that is closed on a specific pricing and product scheme. If your pricing or packaging changes, any customers closed on this new model are now in a new cohort.

The pricing cohort overview makes it easy to see which customers have had which pricing at what point in time — something that can be surprisingly hard to keep track of. To run it properly, you need to be firm in your shifts from one pricing scheme to the next.

If you are afraid of churn when rolling out new pricing, you can create a time-limited grandfathering period for your existing customers.

A sidenote to time-limited grandfathering — if you are a VC-funded startup, you probably get to raise your next round on “run-rate ARR,” meaning the ARR when it has normalized after current signed customers are onboarded, time-limited discounts have run out, etc. This usually also includes price increases that are announced but not yet in effect.

How to Get It Done in the SaaS Organization

“How do we ‘do’ pricing on an ongoing basis?” They don’t want projects. They want pricing as a core capability. A commercial North Star that ties together Product, Sales, and Customer Success and keeps it tied together.

I tell these clients that pricing in an organizational context really boils down to being able to answer four questions consistently: What should we build next? How should we package that into sellable products? How should we price that? How much should we price that?

What you should build depends on what you ultimately can charge for it.

Consider who owns each of the four questions, what process they use to answer, and what tools and resources they need to do so, and you’re off to a good start. Then get those people in a room on a regular basis to make actual decisions. You can wrap it up nicely in your org chart, but that — in a nutshell — is your Pricing Function.

When we talk about Product, Sales, Customer Success, and pricing models, it’s all lined up toward creating one unified North Star for your entire organization: your customer. Price your customer.