Risk Discounts and Usage-Based Pricing
You’re probably not aware of it, but the price of your product includes a risk discount.
Let’s use an example that’s based on a real case: You’re the CEO of a document-processing app that was able to demonstrate $290 of economic value per document, but you found that the market was only willing to pay $8 per document.
Yikes. What happened?
Buyers weren’t sure that the risk reduction was real, so they discounted most of it away. This lowered the value from $270 to $81. And then, by applying the rule of thumb that you want a 10X return on a new innovation in order to consider switching, the price got pushed all the way down to $8.
Without the risk discount, the price would have been closer to $270/10, or $27 per document. So the risk discount took the price from $27 to $8. If the vendor had a way to take on the risk itself, they could get a much higher price.
The analytical framework used here is known as Economic Value Estimation (EVE) and was developed by Dr. Tom Nagle.
People buy software—especially business software—because they expect to get some sort of benefit. There are six main types of value drivers, but what they all have in common is a promise to improve the buyer’s business.
The six types of economic value drivers
- Enhance revenue
- Reduce costs
- Reduce operating capital
- Reduce capital investment
- Improve optionality
- Manage risk
The problem is that the buyer can’t be sure that the promised benefits will be realized. As a result, the buyer tries to reduce this uncertainty in many ways: taking analysts, getting references, taking advantage of free trials, running pilot projects and proof of value studies. These are all meant to reduce uncertainty and manage risk.
There’s always some residual risk. And the more innovative and differentiated your product is, the greater the perceived risk.
One of the main ways people manage this risk is by discounting the price. You’ve probably heard the old adage that a new innovation has to be 10X better than what it’s trying to replace.
But this doesn’t make any sense. If the innovation is even 1% better, it should eventually prevail. For example, think about what happens in highly competitive environments like professional sports. But early on, there’s a good deal of uncertainty about if, when, and how value will be realized. So there must be a risk discount to drive adoption.
Behavioral economics reinforces this conclusion. One of the basic findings of prospect theory (see this explanation) is that most people would rather avoid a risk than win a benefit. I suspect that many of the people who work in early-stage innovation are actually the opposite and would rather take a chance on winning than avoid losses.
This basic psychological difference is why innovators and early adopters can struggle to understand the psychology of people in mainstream markets. These mainstream buyers determine pricing.
Consider how you make choices. If you’re reading this article, you may prefer to take a risk rather than play it safe to avoid losing.
Benefits are anchored on the current solution and not some absolute calculation of value. Gains are relative to the current solution and are measured relative to them. To overcome this risk aversion and inertia, we discount the new solution. Even if the evidence is in favor of the new alternative, it’s still operating at a disadvantage.
Usage-based pricing is a solution
Signals that you may be suffering a risk discount show up in questions and comments from your customers, such as:
- “How do I know people will use it?”
- “Will it really work in our environment?”
- “We may get different results.”
- “It isn’t your solution that will drive the benefit, it’s how our people adopt it.”
- “Our team already knows how to use what we’re using now.”
There’s no easy way to respond to these questions. You’re arguing against experience and loss aversion—that’s a tough sale.
With usage-based pricing, there’s a direct response. The price paid will, at least in part, be based on actual usage. Ideally, it will be on the type of usage that most closely tracks value. (I’ve previously written about how to introduce usage-based pricing.)
This gives you a direct response to objections around usage and adoption. You don’t have to argue—you just point out that you (the seller) are willing to accept the risk.
Related: Get the Usage-Based Pricing Playbook
In its essence, usage-based pricing transfers risk from the buyer to the seller. By taking on execution risk, the seller can reduce the risk discount and win higher prices.
Usage-based pricing is best for both parties when it:
- Connects the price to value
- Lowers adoption risk for the buyer
- Removes objections for the seller
The results can be an expanded pipeline, higher conversion rates, and better pipeline velocity. But this doesn’t make usage-based pricing a slam dunk. The historical objection still holds.
“It’s up to our customer if they use our software properly, and they are the ones who determine if they get a benefit or not.” If you’re going to make usage-based pricing part of your pricing model, you must take on more responsibility for your customers’ success.
If you’re a SaaS business, you’ve probably started down this road—and if you’re following best practices you may have shifted from user support to customer success. Usage-based pricing makes the customer success function even more important. Under a conventional subscription model, customer success sees its main payoff at renewal. Under usage-based pricing, customer success sees its reward every billing cycle.
As a first step towards moving to usage-based pricing, go to your customer success team and ask them these key questions:
- “When do our customers use our software?” Is use mandated? Is it seasonal? Is use in response to a trigger that we can identify or even predict?
- “What uses lead them to use our software more?” Can you measure predictive engagement? (To read more about the types of engagement that lead to future engagement, check out the future of engagement metrics.)
- “What paths through our software need to complete for the user to get value?” In most cases, it’s not a single action that creates value—it’s a series of actions leading to an insight, action, or outcome. These paths are the most powerful way to design usage-based pricing.
Caution: Usage-based pricing doesn’t make sense for everyone
Don’t use usage-based software when your product has the properties of an insurance policy. Some products are only used in exceptional circumstances, but they have to be in place before the circumstances arise. A lot of security software works this way.
In an uncertain world, there are lots of opportunities to create protective solutions for low probability and high-risk situations. These aren’t a good candidate for usage-based pricing.
If you’re able to influence the use of your product, and if use contributes to value, then consider moving to usage-based pricing.
One of the easiest ways to increase prices is to take on more risk. The company that takes the risk gets the reward.
We know a lot of folks are considering the switch, so we’ve curated a list of some of our favorite articles and guides.
Given the consumption-based success stories of similar open-source software products like Elastic and MongoDB, Cypress will be one to watch.