Pricing Decides Where Uncertainty Sits

I once had to price a new B2B SaaS product.

We had taken it from an initial thesis through customer validation and were preparing to bring it to market. Pricing and packaging were now part of the product decision.

The obvious place to start was benchmarking. There was an established category, existing products and prices we could compare.

That was useful until it became clear that the category was describing only part of the value.

Customers already had ways to solve the familiar part of the problem. Those alternatives gave us a useful baseline for what they were accustomed to paying.

But the reason we had built the product was elsewhere.

Another part of the proposition connected that familiar capability to a broader problem and, we believed, created substantially more value.

Using only the category benchmark would have allowed the existing category to define that value for us.

The opposite conclusion would have been just as weak: we are different, therefore we should charge more.

Different is not automatically worth more.

The real question was which differences changed what customers were willing to pay for.

And underneath that sat another question we did not yet have enough evidence to answer with confidence: how much of that uncertainty should we take ourselves, and how much should we ask the customer to take?

What are customers actually comparing you with?

Product teams tend to think about competitors in product terms.

Who has similar features? Who appears in the same category? Which other software would the buyer evaluate?

Those comparisons matter, but the economic alternative can be very different. It might be another product, an existing workflow, internal work, consultants, several tools used together, or simply doing nothing.

The product that looks most like yours is therefore not always the most useful pricing benchmark.

What matters is what the customer believes they are replacing, improving or avoiding when they spend the money.

This matters even more when you are creating something new. An established category gives you context. It does not necessarily tell you what the differentiated part of the proposition is worth.

That led us to a more useful question:

What exactly are we asking the customer to pay for?

We separated the familiar part of the proposition from the capability where we believed stronger value existed.

That was packaging, but it was also product strategy. We were deciding where to put the commercial boundary around the value we wanted customers to recognize.

Pricing has a useful way of exposing vagueness. A roadmap can carry an imprecise value proposition for quite a long time. A price eventually forces someone to answer a simpler question:

Why should the customer pay for this?

You have to decide before you know enough

Eventually, of course, you need a number.

We built different scenarios around adoption, conversion, customer behavior and willingness to pay. At the same time, we were developing the proposition with a small number of customers, testing ideas, changing the product and discussing value and packaging with them.

All of that produced evidence.

None of it produced certainty.

Pricing research can create a strange illusion. After enough interviews, spreadsheets and simulations, assumptions start looking more factual than they are.

A customer saying they could imagine paying a particular amount tells you something. An actual budget decision tells you something else.

We eventually had an early customer move from discussion to a real commercial commitment.

That was an important signal, but it did not suddenly reveal the correct price.

It could not tell us whether a higher price would have worked, whether a lower one would have changed conversion materially, or whether another segment would behave the same way.

A transaction validates a buying decision. It does not validate a demand curve.

Different evidence answers different questions. Research tells you about preferences and sensitivity. Commercial discussions expose resistance. Purchases show whether someone will allocate real budget.

Later, renewals tell you whether the expected value survived actual use. Expansion adds another signal.

The product eventually grew into a meaningful recurring-revenue business. That gave us far better evidence than we had when we first had to price it.

But that evidence came later.

The decision had to come first.

That is why I think of an initial price as a hypothesis.

Not simply a hypothesis about whether one number is correct, but about the model underneath it.

Who sees the value?
Which differences increase willingness to pay?
What alternatives does the customer compare you with?
Which budget pays?
How sensitive is demand?
How will the product be used?
What does it cost to provide?
What will the pricing model do to adoption?
How will all of this vary across segments?

The number is one output of that model. Packaging, the meter, discount structure and commercial terms are others.

All of them allocate some part of the uncertainty.

This is also why I do not find “start high, because you can always lower the price” particularly useful advice.

Starting too high can reduce adoption and slow learning. Starting too low can create anchors that are hard to undo.

The more useful objective is to preserve your ability to learn without creating unnecessary commitments that become difficult to reverse.

Discounts can produce useful signals here, but they are noisy. Customers negotiate differently. Large accounts have more leverage. Salespeople behave differently. Procurement changes the dynamics of a deal.

If customers repeatedly resist one effective price and accept another, that deserves attention. It does not automatically mean the price difference caused the outcome.

Pricing data often arrives mixed with the behavior of the commercial system producing it. You need to understand both.

The company changes which uncertainty you can carry

The same pricing problem looks very different depending on the company.

A younger company may have significant freedom to redesign packaging, introduce a new metric or change the commercial model. Its problem is often lack of evidence. It may still be discovering the buyer, segment, usage pattern and even the category itself.

A larger company typically has more evidence and less freedom.

There may already be pricing policies, discount bands, SKUs, sales compensation, partner models, contracts, renewal rules, billing systems and commitments to existing customers.

The elegant model on the whiteboard now has to survive the commercial operating system.

Sales needs to sell it. Customers need to understand it. Procurement needs to buy it. Finance needs to forecast it. Contracts need to describe it. Billing needs to execute it. Eventually somebody needs to renew it.

The theoretically optimal pricing model may therefore not be the model the company can operate most effectively.

That is not organizational complexity sitting outside pricing. It changes which commercial risks the company is realistically able to take.

AI makes the uncertainty harder to hide

I have been thinking about these questions again because AI makes several of the underlying tensions much more visible.

Traditional SaaS always had infrastructure costs. But in many application products, the marginal cost of another user interaction was small enough to disappear inside the subscription.

With AI, usage can trigger inference, retrieval, reasoning, tools, external services and agent loops. Two actions that look almost identical to the customer can have very different costs underneath.

That creates a temptation to expose the cost unit commercially.

Tokens cost us money, so sell tokens. Calls cost us money, so sell calls. Compute costs us money, so expose compute.

That can make perfect sense for an infrastructure product.

For application products, cost-based pricing is usually the wrong starting point. Customers do not value tokens. They value the problem being solved.

But ignoring cost is not sensible either.

You need to understand the cost distribution, not simply the average. You need to know what happens to the economics when usage is much higher than expected.

The metric used to understand your costs does not have to be the unit you ask the customer to buy.

Measurability does not make something valuable.

AI also changes another assumption behind traditional SaaS pricing. It can change the unit in which value itself is created.

Software has traditionally monetized access reasonably well. Five hundred people use a product, so five hundred seats is understandable, predictable and easy to procure.

That model can continue to work when AI primarily assists those people.

It becomes less natural when the software itself performs substantial amounts of work.

A small number of agents can execute thousands of tasks. The amount of work performed no longer scales neatly with the number of employees accessing the product.

The customer may be moving from buying access to software toward buying work performed by software.

That makes the uncertainty around usage, value and cost much harder to bury inside a familiar seat model.

Pricing decides where the uncertainty sits

This is why I find one question more useful than simply debating seats, credits, usage or outcomes:

Which uncertainty are we asking the customer to carry, and which uncertainty are we willing to carry ourselves?

A fixed subscription gives customers strong budget predictability while the vendor takes more usage and cost variance.

Consumption reduces that exposure for the vendor, but gives the customer more budget uncertainty. It can also make the vendor’s revenue more volatile.

A hybrid model splits it again. Seats or a base subscription create a predictable commitment, while consumption captures some of the variance in usage.

Outcome pricing shifts the balance differently. Customers carry less execution risk while vendors take more performance, attribution and delivery risk.

Committed consumption improves predictability, but introduces the possibility that the customer buys capacity they do not use.

Allowances and overages distribute the uncertainty again.

The point is not that every model simply transfers the same amount of risk from one side to the other. Some models reduce uncertainty. Some make it easier to forecast. Some create better alignment.

But there is no pricing architecture where uncertainty disappears.

Pricing decides where it sits.

Both sides have legitimate needs.

Enterprise customers need to budget, forecast and get spending approved before actual usage is fully known.

Vendors cannot ignore a model where successful adoption can generate substantially more cost without additional revenue.

Pricing architecture is the mechanism that tries to make those realities coexist.

The allocation is not determined by the pricing model alone. Commercial defaults matter too. Auto-renewal, minimum commitments and cancellation mechanics can move uncertainty between customer and vendor without changing the headline price at all.

They can also change the evidence you get back. A repeat purchase that requires an active decision is a cleaner signal of continued demand than one that happens by default.

The meter also changes behavior

The effect is not only economic.

The way you charge changes how the product is used.

If every interaction consumes visible credits, people start deciding whether another interaction is worth it. If an allowance feels scarce, experimentation changes. If usage feels unlimited, adoption becomes easier while the vendor carries more of the variance.

If customers pay only when the product produces a successful result, the vendor absorbs the failed attempts.

These choices create incentives inside the product.

I wrote before about where the AI meter sits. The question before that is perhaps even more important:

What behavior are we trying to encourage?

Sometimes the objective is direct revenue. Sometimes a capability makes another product more valuable. Sometimes adoption, retention or differentiation matter more than directly monetizing the capability itself.

A new feature does not automatically need a new revenue line.

But a pricing decision should know which economic outcome it is trying to produce, because that choice changes both behavior and where the uncertainty lands.

Value has to survive reality too

This is where value-based pricing enters the discussion.

Customer value should influence willingness to pay far more than the vendor’s infrastructure bill. But value-based pricing does not require billing directly against the final business outcome.

Value can shape segmentation, packaging, tiers and price even when the commercial meter is much simpler.

The harder part comes later.

The value needs to remain credible after the sale.

Can the customer see it?
Can they explain why the product deserves the budget?
Will the value proposition still make sense at renewal?

If the value story works beautifully until the contract is signed and then disappears, you may have strong value-based selling without having created a durable value-based pricing model.

Value-based pricing eventually has to survive the renewal because that is when another assumption gets tested: whether the value was durable enough for the customer to keep carrying their side of the commercial commitment.

Then reality starts returning data

When we made that original pricing decision, we had benchmarks, customer research, simulations and our judgment about where the value really was.

Later we had purchases. Then broader adoption. Then recurring revenue.

The evidence improved because reality had started happening.

That sequence has not changed.

You still have to choose before you have the evidence that would make the choice obvious. Then customers start correcting your assumptions.

Usage differs from the model. A segment values something you considered secondary. Sales encounters resistance you did not expect. A pricing unit that looked elegant turns out to be difficult to operate.

Costs change. The product changes. The market changes.

And you update.

That is why I still think of price as a hypothesis, but the hypothesis is bigger than the number.

It is a hypothesis about value, demand, behavior, economics and the system around them.

And every pricing architecture turns that hypothesis into a particular allocation of uncertainty between the customer and the vendor.

Pricing is one of the places where Product, Finance, Sales and customer reality become impossible to separate.

It forces the assumptions into the open.

Then it lets the market test them.

Pricing needs enough conviction to launch and enough humility to change.