Simple Pricing Is Not Easy Pricing

Jokes aside, nearly every leadership team I work with sets "simple pricing" as one of their primary objectives. However, most don't notice that they're actually asking for two separate things at once. Pricing that is:

• Simple for the customer. Pricing a buyer can navigate, understand, and predict.
• Simple to run. Pricing your own team can sell and maintain without manual heroics.

Both matter. The problem comes when they are combined into a single objective, leaving no room to make deliberate tradeoffs between them. It's an easy conflation to make, and one reason otherwise sound pricing strategies get diluted before they launch.

“Simple for the customer” and “Simple for the vendor” are not always correlated outcomes

The two don't always move together. A team can deliver a materially simpler customer experience while their internal pricing operations get heavier, but that tradeoff may actually be the right one to make for the business. The trap is how it is ultimately perceived and evaluated internally, which comes straight from how the objective was initially set.

A team that writes "simplify our pricing" as one line item atop the list of objectives has committed to an outcome without carving out deliberate space to consider what produces it. A simple customer experience often depends on more intricate machinery behind the scenes: pricing curves, data inputs, calculation logic, and supporting value stories.

What ends up happening is that the right strategy can look like it does not satisfy the objective. The team designs a simple customer experience, sees for the first time the complex structure that sits behind it, and questions it because what they're looking at does not look “simple” in the slightest. They feel like they’ve gone off track, even though they're actually still on the right course.

Internal complexity, in service of customer simplicity, is not a failure

The typical reaction is to aim to simplify the structure by removing the complex structural elements. But what they are cutting is the very mechanism that enabled the simpler customer experience in the first place. In the end, what launches is often a less effective version of what was originally on the table.

In most of these cases, what a team reads as complexity is not really complexity at all. It is really better described as granularity: a model with more inputs, more calculations, and more moving parts. Pricing can be highly granular under the hood without ever feeling complex to the customer, so long as the customer isn't the one handling it.

A couple of brief examples of granular elements that do not add complexity to the customer:

• Implicit price metrics: a system where the price is driven by characteristics of the customer that are never exposed to the customer. The customer sees a final price with little-to-no visibility into the formula that produced it*.

This is simple for the customer: the buyer never has to reason about how their price got set. No negotiating a per-unit price or arguing about which tier they belong in.

But internally, that price took a lot of effort to produce. Someone has to source customer data reliably, keep the price curves calibrated as the customer base shifts, and give sales a way to defend it later if a customer asks questions (my colleague Max Baughman has written on the mechanics of this).

*Implicit metrics are usually combined with other “explicit” metrics, which are exposed to the client. In this way, implicit elements add pricing vectors without adding customer complexity. But it is usually inadvisable to only price based on implicit metrics, as then the customer would have no basis for their pricing.

• AI credits: the customer buys a block of credits and only thinks about two things, what it costs and roughly what it buys.

Internally, however, credits are often an abstraction layer over a multi-metric price architecture. Someone has to set the credit weight for every action type, keep those weights current as the product evolves, decide what happens to unused credits at renewal, and watch margin when one heavy user consumes many multiples of the average.

A team that never set separate objectives for pricing complexity absorbed internally vs. pricing complexity absorbed by the customer might treat these mechanics as the opposite of what they were asked to deliver, when they're actually how it gets delivered.

Granularity and complexity are not the same

None of this is a blanket defense of intricate internal pricing operations. It is important to distinguish between purposeful granularity and unnecessary complexity, because they deserve different treatment. Granularity is the detailed internal machinery required to support the pricing model: additional inputs, calculations, and processes that enable a simple customer experience while keeping prices aligned with the value each customer receives. When it shows up, it does not inherently mean the pricing effort has gone awry.

Granularity is not always the right answer. It takes effort to build, maintain, and use, and that effort may not always be justified by the resulting improvement in customer simplicity or value capture. But this is a strategic tradeoff that teams should make deliberately as they design their pricing strategy.

Unnecessary complexity is different. It comes from unstructured or redundant pricing decisions: price curves added deal by deal until nobody can count them, or two metrics measuring the same thing. It supports nothing the customer sees and should be eliminated. So when your pricing operations feel complex, the first question worth asking is "why?" Does it come from the more granular mechanics required to support the external pricing model, or unnecessary complexity left behind from past pricing strategy decisions?

The former presents a strategic choice. The latter does not.

Conflating the two types of simplicity costs more than it used to

Teams have been conflating these two concepts for as long as pricing strategies have existed, but what has changed is how visible the damage is. Products used to be narrow enough that a pricing model which missed some value capture missed a small amount, and the gap was easy to live with.

Today’s SaaS products span more use cases and deliver a wider range of value than their predecessors. A model calibrated to the middle of that range can leave substantial value uncaptured at the top while pricing itself out at the bottom. AI has widened that range further, given the enormous variation in usage and valuable actions, while also introducing higher variable costs that pricing must account for. To work across that rapidly expanding range of value delivery, pricing mechanics need to become more dynamic and creative. So, a team that commits to simple pricing today without deciding and committing to what they are willing to build to support it gives up more value than that same (in)decision would have a decade ago.

Split the "simplify pricing" objective into two

Our advice to tech leaders considering the simplicity of their structure is to take the single "simplify pricing" line item and split it into the two distinct concepts we’ve discussed.

We want to create pricing that is:

• ‍Simple for the customer. What should a customer see, understand, and be able to predict? Set that ambition against your market and your buyers. What your team runs today is the second question.
• ‍Simple to run. For internal operations, "simple" means as simple as the customer experience allows, not as simple as possible. So, the question becomes: how much granularity are we prepared to build and operate to make the first objective true? That needs a concrete answer before design work starts, because it's where the first objective's ceiling gets set. And the honest answer might be "very little." Some businesses can run simple pricing end to end without trading off value capture (how much simplicity trades off against monetization is its own question, and my colleague Scott Mahon has taken it on here). But that should be a conclusion you reach, not a default you fall into.

Setting the objectives this way does most of the work on its own. If both are considered up front, your team walks into the project knowing that an increase in internal pricing granularity may be part of the ideal end state rather than a deviation from it. Nobody flinches when it shows up in the final pricing strategy design and it's time to operationalize.

Simple pricing is not always easy pricing. But it's always worth chasing, as long as you know what work you're willing to put in to make it happen.