Your Pricing Page Is Selling the Wrong Thing

In 2003, an IBM executive named Lou Gerstner made a pricing decision that the software industry spent the next two decades slowly copying without fully understanding why it worked.

IBM was selling server hardware and software to enterprise customers who were increasingly resistant to large upfront capital expenditures. The sales cycles were long. The procurement objections were consistent. The budgets were constrained. The product was genuinely valuable but the price was structured in a way that forced customers to justify a large purchase before they had experienced any of the value it would deliver.

Gerstner changed the question the pricing was answering.

Instead of asking customers to pay for the hardware and software they were acquiring, IBM began asking them to pay for the computing capacity they consumed and the business outcomes that capacity enabled. The price was no longer a reflection of what IBM had built. It was a reflection of what the customer got. Utilisation-based. Outcome-anchored. The customer paid more when they got more and less when they got less.

The revenue impact was not marginal. IBM’s services division became the fastest-growing part of a company that had been in structural decline. Not because the technology changed. Because the pricing architecture was rebuilt around the value the customer received rather than the product IBM delivered.

That shift, from charging for what you built to charging for what your customer achieves, is the highest-leverage pricing decision available to a SaaS founder at any stage. And most founders have never made it deliberately because their pricing page was built by copying a competitor rather than by measuring what their best customers are actually willing to pay for.

Feature-based pricing is a cost-recovery model dressed up as a value proposition.

When you price by seat count, by feature tier, or by storage allocation, you are charging customers for inputs. The number of people using the product. The range of capabilities they can access. The amount of data they can store. These are proxies for value, not value itself. And proxies for value always underprice the real thing because the real thing, the outcome the customer achieves, is always worth more than the inputs required to achieve it.

The founder who charges forty dollars per seat per month for a product that helps a five-person sales team close two additional enterprise deals per quarter is charging forty dollars for an input that delivers roughly two hundred thousand dollars in incremental revenue. The price-to-value ratio in that transaction is so lopsided that it is almost impossible to raise price fast enough to close the gap through seat-based increments alone.

Outcome-based pricing closes that gap structurally rather than incrementally. It anchors the price to the result rather than the resource. It makes the conversation about what the customer gets rather than what the customer accesses. And it produces a pricing architecture where your revenue grows as your customers succeed rather than only as your customer count grows.

Three times the revenue without a single additional user is not a fantasy. It is the arithmetic of closing the gap between what you charge and what your product actually delivers. The gap is there. The question is whether your pricing architecture is designed to capture it.

Pricing the Product Instead of Pricing the Problem

There is a moment in almost every SaaS founder’s pricing history that locks them into feature-based thinking before they have ever seriously considered the alternative.

It is the moment they open their top three competitors’ pricing pages and build their own pricing structure to sit somewhere reasonable in that landscape.

Competitive pricing feels like market intelligence. It is actually market anchoring. When you price relative to what competitors charge, you inherit their value framing along with their price points. If your competitors charge by seat, you charge by seat. If they tier by feature set, you tier by feature set. The entire category ends up pricing inputs because everyone is pricing inputs and nobody is asking whether inputs are the right unit to sell.

Veeva Systems entered the pharmaceutical CRM market in 2007 against Salesforce, which had already established seat-based pricing as the category norm. Veeva made a decision that looked irrational to everyone who evaluated it through the lens of competitive pricing. They charged significantly more per seat than Salesforce. Not marginally more. Significantly more. Then they justified the price not by listing features that Salesforce lacked but by calculating the specific compliance cost reduction, sales cycle compression, and regulatory submission acceleration their product produced for pharmaceutical companies operating in one of the most expensive regulatory environments in any industry.

The price was not high relative to what Veeva had built. It was appropriately calibrated relative to what Veeva’s customers saved. A pharmaceutical company spending forty million dollars per year on regulatory compliance that Veeva’s product reduced by fifteen percent was not paying a premium for software. They were paying a fraction of the value they were receiving.

Veeva went public in 2013 at a valuation of nearly three billion dollars. In a market dominated by Salesforce. Priced higher than Salesforce. Built on a pricing architecture that charged for outcomes rather than seats.

The mistake is not charging too much. It is charging for the wrong thing.

Finding the Outcome Your Best Customers Are Actually Buying

Outcome-based pricing begins with a conversation most founders have never had systematically with their customer base.

Not what features do you use. Not what would you like us to build. What would it cost your business if our product stopped working tomorrow?

That question surfaces the outcome. Not the feature. Not the workflow. The business consequence of the product’s absence. And the business consequence of absence is the most direct measurement of the value being delivered because it forces the customer to quantify what they have been receiving rather than describe what they have been using.

Run that conversation with your ten best customers this week. Best defined not by revenue contribution alone but by the combination of high retention, high engagement, and high expansion over the last twelve months. These are the customers whose relationship with your product is most representative of what it can deliver at its best.

Ask the question. Listen for numbers. Revenue protected. Costs reduced. Time saved multiplied by loaded hourly rate. Deals closed that would have been lost. Errors prevented that would have been expensive. Every answer is a data point that tells you what outcome your product is delivering in financial terms to the customers who are getting the most from it.

Then look at what you are charging those same customers. The gap between what they tell you the product saves or generates and what you are charging them is your pricing opportunity. Not all of it is capturable immediately. Some of it is structural and requires a pricing model redesign to access. But seeing the gap clearly for the first time is the beginning of every meaningful pricing evolution.

Datadog made this transition deliberately as they scaled from a monitoring tool into a full observability platform. Their early pricing was infrastructure-based. Hosts monitored per month. A clear, defensible, easily understood pricing unit that reflected what Datadog tracked rather than what Datadog prevented. The problem was that what Datadog prevented, production outages, engineering hours lost to debugging, revenue lost during downtime, was orders of magnitude more valuable than the number of hosts being monitored.

As Datadog matured their pricing, they shifted toward a model that captured more of the outcome value rather than the infrastructure input. Custom metrics, log ingestion volume, and APM traced services all became pricing dimensions that correlated more directly with the complexity and criticality of the environments being monitored rather than with simple host counts. The revenue per customer expanded without a proportional increase in the cost to serve because the pricing was capturing a larger share of the value being delivered to increasingly sophisticated enterprise environments.

The Three Outcome Pricing Models That Work in B2B SaaS

Outcome-based pricing is not a single model. It is a family of approaches each suited to a different type of product and customer relationship. The three that produce the most consistent revenue expansion in B2B SaaS are usage-based outcomes, success-based outcomes, and efficiency-based outcomes.

Usage-based outcome pricing ties the price to the volume of value the customer consumes. Twilio charges per message sent, per call connected, per email delivered. The customer pays more as they succeed more. The pricing grows with the customer’s business rather than requiring a renegotiation every time their usage doubles. AWS charges per compute unit consumed. Snowflake charges per query run. The commonality is that the price is a function of value delivered rather than access granted.

Success-based outcome pricing ties the price directly to a measured business outcome the product enables. Some legal technology platforms charge a percentage of the contract value they help negotiate. Some revenue intelligence tools charge a percentage of the pipeline they demonstrably influence. Some hiring platforms charge a fee per successful placement rather than a subscription for access to the search functionality. The customer pays when they win. The product provider wins when the customer wins. The alignment of incentives is complete.

Efficiency-based outcome pricing ties the price to the cost the product eliminates rather than the feature it provides. A product that automates a workflow previously requiring four hours of manual work per week can price against those four hours multiplied by the loaded hourly cost of the role performing that work. The pricing is anchored to a line item the customer already has in their budget rather than to a new software expense they have to justify.

Each of these models requires knowing your outcome before designing your price. Not guessing the outcome. Measuring it. In your best customers. In their own financial terms. Then building a pricing architecture that captures a consistent and defensible percentage of that measured value.

Run the Outcome Audit Before Your Next Pricing Review

Before you change a number on your pricing page, run the outcome audit.

Step one: identify your ten highest-retention, highest-engagement customers. Contact each one with a single question. What would it cost your business in the next twelve months if our product was no longer available? Collect the answers. Do not interpret during collection. Listen and record.

Step two: calculate the ratio between the annual revenue you receive from each of those customers and the annual value they reported the product delivering. If the median ratio is below ten percent, you are capturing less than ten cents of every dollar of value you create. That is your pricing gap stated in concrete terms.

Step three: identify which of the three outcome pricing models fits your product’s primary value delivery mechanism. Usage-based if your value scales with consumption volume. Success-based if your value is directly tied to a measurable business outcome. Efficiency-based if your value is primarily measured in cost or time eliminated. Then design one pricing experiment that moves one tier or one customer segment toward that model and measures the revenue impact over ninety days.

A practical AI prompt to run this analysis now: open Claude and paste this: “My SaaS product delivers value to customers by [describe the primary outcome your product creates]. My current pricing model is [describe your current pricing structure]. Here are the outcomes my best customers have described when asked what the product saves or generates for their business: [list the outcomes from your audit]. Based on this, identify which outcome-based pricing model best fits my product, calculate the approximate pricing gap between what I currently charge and what my best customers report receiving in value, and suggest one specific pricing experiment I could run in the next ninety days to begin closing that gap without restructuring my entire pricing model at once.” Use the output to design your first outcome pricing experiment and measure the revenue impact before making any permanent pricing changes.

The Startup Growth OS treats Monetization as the system that determines how much of the value your product creates actually converts into revenue you can compound. Feature-based pricing is a value capture floor. Outcome-based pricing is a value capture architecture. The product you have built is already delivering outcomes your pricing is not capturing. The gap between what you deliver and what you charge is the most available revenue opportunity in your entire business right now. It requires no new users, no new features, and no new channels. It requires a conversation with your best customers and the discipline to build a pricing architecture around what you find.

Sam Femi

Seamless Life HQ

P.S. Your best customer is not paying for your software. They are paying for what your software makes possible for their business. The distance between those two things is the distance between your current revenue and your real revenue ceiling. You close that distance not by adding features but by asking better questions about what your product is actually worth to the people who cannot imagine working without it. We have an offer for you here

Book a call with us, Here