Pricing Should Not Be the Last Step in Product Development

Product teams are under constant pressure to ship faster, add new capabilities, respond to customer demand, and increasingly, embed AI into their products.

Pricing often comes later.

That sequencing creates a problem.

The teams responsible for building the product are focused on creating value. The teams responsible for pricing, packaging, selling, and monetizing the product are focused on capturing that value. When those conversations happen separately, companies can end up with a product that is technically compelling but commercially difficult to package, price, sell, and scale.

In a recent LogiSense conversation, Kevin McCabe of Applied Frameworks described this as a disconnect between product architecture and commercial architecture. Product teams and commercial teams may both be thinking about value, but they are often defining it differently and making decisions in different parts of the organization.

As pricing models become more dynamic, particularly with usage-based and AI-enabled products, that separation becomes harder to sustain.

Product Innovation and Value Capture Need to Happen Together

A company may invest heavily in a new feature because customers are asking for it, competitors already offer it, or the technology appears strategically important.

But another question needs to be asked at the same time:

How will this investment create economic value for the business?

That does not simply mean attaching a price to the feature after development is complete.

It means understanding:

• Which customers value the capability
• How much value it creates
• How it should be packaged
• Which pricing metric best reflects that value
• How the feature affects the broader commercial model
• Whether the business can operationally support the pricing model

McCabe argues that this discussion often does not happen in one place. Product teams decide where to invest, then the problem of monetization is effectively handed downstream to pricing, finance, or sales.

The result is a familiar pattern: the product is already built, the commercial team now has to determine how to monetize it, and operational teams must figure out whether the existing systems can actually support the model.

That is not commercial design. It is commercial adaptation.

Pricing Drift Is a Warning Sign

One of the more useful concepts from the discussion is what McCabe calls pricing drift.

Products evolve continuously. Pricing often does not.

New features are added. New modules are launched. Infrastructure costs change. AI capabilities are introduced. Customer segments shift. Usage patterns evolve.

Yet the commercial model may remain largely unchanged.

Over time, the way the business captures value begins to drift away from the value the product actually creates.

The symptoms can appear in several places.

Discounting begins to increase. Sales teams ask for more exceptions. Similar customers end up paying materially different prices for similar products. Commercial teams start creating workarounds to accommodate deals that no longer fit the standard model.

These may look like individual sales or pricing problems.

They can actually be symptoms of a deeper architectural problem: the product and commercial models have fallen out of alignment.

Changing the price list alone will not necessarily fix it.

Your Billing System Can Limit Your Pricing Strategy

There is another dimension to this problem that is often discovered much later.

A pricing strategy may look excellent on a spreadsheet and still fail operationally.

McCabe describes organizations that develop new pricing approaches without first determining whether their billing infrastructure can actually support them. The strategy reaches implementation, and only then does the business discover that its systems cannot accommodate the required pricing logic or operational complexity.

This becomes particularly important with usage-based and hybrid pricing.

A business may want to introduce:

• Tiered usage pricing
• Credits
• Minimum commitments
• Overages
• Customer-specific rates
• Real-time consumption
• Multiple usage metrics
• Hybrid subscription and consumption models
• Outcome-oriented pricing

Each additional model creates operational requirements behind the scenes.

Usage has to be captured. Data may need to be normalized. Charges must be rated correctly. Contract rules need to be enforced. Customers need visibility into their consumption. Finance needs confidence in the resulting revenue.

That is why monetization infrastructure should be part of the pricing conversation before a model is launched, not after.

Pricing Complexity Can Suppress Growth

More pricing flexibility is not automatically better pricing.

McCabe describes one company that continually added products, features, and corresponding pricing metrics until customers were effectively buying individual components rather than a coherent solution. The commercial model eventually became difficult for customers to understand and budget for.

That created a particularly damaging outcome.

Customers became hesitant to use more of the product because they could not confidently predict what additional usage would cost.

For a usage-based business, that is the opposite of the desired behavior.

A good usage-based model should align growth in customer value with growth in customer spend.

But if customers feel that increasing usage introduces financial uncertainty, the pricing model can create friction precisely where the company wants expansion.

This is why predictability remains important even in consumption-driven business models.

Customers need to understand the relationship between usage, value, and spend.

AI Is Making the Product-Pricing Gap More Visible

AI is accelerating this entire challenge.

Companies are adding AI capabilities rapidly, but the economics of those capabilities differ from traditional software.

AI can introduce variable infrastructure costs tied to tokens, inference, models, compute, APIs, or third-party services. That creates an understandable temptation to take those costs and translate them directly into a customer-facing pricing metric.

Tokens are an obvious example.

But McCabe raises an important concern: if companies simply price around their underlying token costs, they risk recreating a cost-plus model rather than pricing around customer value.

The more important question may be:

What is the AI actually doing for the customer?

If an AI agent performs a growing percentage of a workflow, reduces manual work, accelerates a business process, or replaces activities that previously required people and systems, then its economic value may be significantly greater than the cost of the tokens it consumes.

The infrastructure cost matters.

But it does not necessarily define the price.

That distinction will become increasingly important as companies move from AI-assisted products toward more autonomous and agentic experiences.

Outcome-Based Pricing Is Appealing, but the Market Is Still Learning

If AI creates value through outcomes rather than simply activity, should companies move directly to outcome-based pricing?

Possibly, but the conversation highlights why the transition may be gradual.

Customers still need predictability. They need to understand what they will spend and how they will budget for it.

McCabe notes that companies and customers may not yet be ready to move fully into true outcome-based models. Instead, the commercial model can become a mechanism for learning. Usage, pricing, customer behavior, and sales outcomes can all provide signals that help companies understand where value is actually being created.

That suggests a more practical approach.

Companies do not necessarily need to discover the perfect AI pricing model immediately.

They need infrastructure and commercial processes flexible enough to evolve as they learn.

Pricing Data Should Influence the Product Roadmap

The relationship between product and pricing should work in both directions.

Product decisions influence pricing.

But pricing can also reveal important information about the product.

Which features customers are willing to pay for, where deals are consistently discounted, which segments expand, where customers resist additional spend, and how usage changes after pricing changes all provide signals about perceived value.

McCabe argues that these signals can help inform segmentation, commercial strategy, and ultimately the product roadmap.

That creates a feedback loop:

Product creates value → pricing attempts to capture value → the market responds → those signals inform future product decisions.

When product and commercial architecture are disconnected, much of that feedback is lost.

The Goal Is Not More Pricing. It Is Better Alignment.

The answer is not to involve a pricing committee in every product decision.

It is to stop treating monetization as something that happens after the product is built.

Product, finance, sales, pricing, and technology teams need a shared understanding of how value will be created and captured.

Before launching a new product, feature, or AI capability, organizations should be able to answer several questions:

• What value does this create?

• Who values it most?

• How should that value be measured?

• How should the offering be packaged?

• What commercial model supports both customer adoption and profitable growth?

• Can the existing monetization infrastructure operationalize that model?

• And how will the company know when the model needs to change?

Companies that can answer those questions together will be better positioned to experiment with pricing without introducing unnecessary complexity.

Because the real challenge is not simply designing a better product.

It is ensuring the business can capture the value that product creates.

Want to hear the full conversation? Watch The Missing Link Between Product and Pricing with Kevin McCabe of Applied Frameworks and Tim Neil of LogiSense.