AI Features Are Easy to Ship. Harder to Price.

AI has become the new product tax. Every roadmap needs to show it. Every board deck needs a slide on it. Every customer wants to know where it fits. Somewhere in the middle, a product leader is looking at the roadmap and thinking: this is exciting, but how exactly are we going to price it?

That is the tension I see now. Companies are under pressure to add AI features, but many are still learning where customers see enough value to pay differently.

I have seen this pattern before.

Years ago, during the ISE repricing exercise moving from perpetual to subscription we ran conjoint analysis and learned something uncomfortable: customers would have paid significantly more for certain capabilities than our packaging assumed. The value was there. We hadn’t built the discipline to measure it. By the time we did, the price anchor had already been set.

AI features are not free to build or operate. They can carry meaningful compute costs. That cost structure is different from traditional SaaS inference is not free to scale the way storage or bandwidth became and it changes the math on which features can reasonably sit in a base tier. They can also change the value equation for customers in ways that are not always obvious at launch: faster workflows, better decisions, fewer manual steps, reduced risk, or more output from the same team.

Roadmap pressure → value → pricing model. The gap between them is where the monetization problem lives.

1. Seat-based pricing will come under pressure.

For years, SaaS pricing had a simple growth logic: as the customer grew, more people used the product, and the vendor captured more revenue through more seats.

Agents complicate that model.

If one user can now do substantially more work through AI agents, seat count may no longer be the best proxy for value. The product may be delivering more output without adding more users. In some cases, it may even help customers avoid adding users.

That does not mean seat-based pricing disappears. It does mean product leaders need to ask whether seats still reflect the value being delivered.

The better question is not, “Should we abandon seats?” It is: where does the customer experience value, and does our pricing meter reflect it?

One useful frame: where does the AI capability sit on the risk spectrum for your seat model?

If AI primarily augments users making them faster, better, less error-prone seat count may still work, perhaps with packaging adjustments. If AI starts doing work that previously required more people, or allows a customer to avoid hiring, seats become a weaker proxy. That is when a distinct AI-specific meter workflow completions, actions executed, outcomes delivered becomes more than a packaging question. It becomes a strategic one.

When agents automate, seat count stops being a revenue proxy.

A good pricing meter needs to be understandable, predictable, tied to customer value, fair to both sides, and reasonably connected to the vendor’s cost to serve. For most AI capabilities today, the seat model does not meet that standard.

2. Packaging has to be rebuilt around value, not around the word “AI.”

Before getting to packaging, it is worth naming a real objection: some customers feel like AI add-ons are double billing. That reaction is understandable, and product leaders should not dismiss it. The honest answer is that not all AI features earn separate pricing. A capability that simply makes the product less frustrating to use removing a manual step that never should have existed probably belongs in the base tier. But a capability that genuinely changes what a customer can accomplish, replaces work they were paying people to do, or delivers outcomes that would otherwise require a different tool or vendor that is a different conversation. The question is whether you can show the customer the difference clearly enough that they see it too. If you cannot, the pricing will not hold regardless of how you structure it.

Adding “AI” to a tier and hoping customers pay more is not a pricing strategy. It is a label.

The packaging work starts with better questions:

• Is the AI feature making existing users more productive?
• Is it automating work that previously required people?
• Is it reducing risk or improving decision quality?
• Is it consuming meaningful compute that changes the cost to serve?
• Is it valuable to every customer, or only to certain segments/use cases?

Each answer points to a different packaging choice.

Augments vs. automates different paths, same meter criteria.

Some capabilities may belong in the base tier because they make the whole product more competitive. Some may belong in a higher tier because they create clear incremental value. Some may need usage limits, credits, or work-unit pricing because the vendor’s cost varies materially but only if customers can connect the unit to value. Otherwise it becomes another confusing meter.

There is a natural temptation to give a new capability away to gain traction, then figure out pricing later. Sometimes that is the right move but it should be a deliberate experiment, not an accidental permanent decision. In one pricing exercise I was involved in, we introduced AI capabilities with limited-time discounts not to give them away permanently, but to learn willingness-to-pay before the anchor set. Giving something away forever is different from using a launch period to learn.

3. Experiment before the pricing hardens.

None of that works without the right data. Instrumentation should track value influence, not just usage: which workflows, what downstream outcomes, what productivity delta. Without this trail, you are asking customers to price in the abstract and abstract research produces abstract answers.

AI pricing is still early. That should make product leaders more experimental, not more casual.

Run willingness-to-pay research. Test packaging alternatives. Use limited-time offers when you need market feedback without permanently anchoring the feature as free. Look at usage intensity, workflow value, and customer segment differences. Be open to hybrid models if the old model no longer maps cleanly to value.

The worst outcome is not launching at the wrong price. That can be corrected. The worse outcome is launching without the telemetry, research plan, or decision owner needed to learn from the market.

Three things I would do now:

1. Map value before mapping price.
2. Instrument the product before the debate gets philosophical.
3. Run pricing research and packaging experiments before the market teaches you the hard way.

The harder question: can your pricing model capture the value being created without surprising the customer or destroying your margins?

The companies that instrument early, experiment deliberately, and revisit packaging with real data will have an advantage over the ones that simply add AI to the base tier and hope to fix pricing later.

Wishing that traction will eventually force the pricing question is not a strategy. The market will answer it for you, just not in your favor.

Ameet Kulkarni is the founder of MRNA Inc., a product strategy consultancy for B2B companies at inflection points. He led the monetization transformation of Cisco ISE from perpetual to subscription, growing annual bookings to $350M+.