Pricing an AI Feature Inside an Existing Product

Adding an AI feature to an existing product is not a pricing question about the feature. It is a question about what happens to the margin of the product you already have, and the answer depends on a variable most launch plans treat as a goal rather than as a cost driver: how many people use it.

Bundling dilutes margin with adoption

Bundle the feature into the existing price and you have set its price to zero at the margin. Every adopting customer adds cost and no revenue:

m_new = 1 - (COGS_old + a * u * c) / R

  a   attach rate: fraction of customers who use it
  u   units of the feature per adopting customer
  c   fully loaded variable cost per unit
  R   revenue per customer, unchanged

Assume R = $50 per month, COGS_old = $5 (90% margin),
and an adopting customer consuming u*c = $6 of
inference a month:

  a = 0.00 : COGS 5.00  -> margin 90.0%
  a = 0.15 : COGS 5.90  -> margin 88.2%
  a = 0.40 : COGS 7.40  -> margin 85.2%
  a = 0.70 : COGS 9.20  -> margin 81.6%
  a = 1.00 : COGS 11.00 -> margin 78.0%

Twelve points of gross margin between a feature nobody uses and one everybody uses. The launch is judged a success precisely as the margin decays, and the two facts are usually reported to different people in different meetings.

Notice that a appears multiplied by u. Both are moving targets, and both move upward as the feature gets better: more people adopt, and adopters use it more per month. Model the product a * u rather than either alone, and forecast it at the level you are trying to reach rather than at today’s.

The price rise that holds margin

If bundling is the plan, the honest version prices it. Solve for the revenue that keeps the old margin:

R_new = (COGS_old + a * u * c) / (1 - m_target)

Same assumptions, m_target = 0.90:

  a = 0.40 : R_new = 7.40 / 0.10 = $74.00
  a = 0.70 : R_new = 9.20 / 0.10 = $92.00
  a = 1.00 : R_new = 11.00 / 0.10 = $110.00

To bundle an AI feature at full adoption and keep a
90% margin on a $50 product, the price has to more
than double.

Which is usually not going to happen, and that is a finding rather than a failure of the arithmetic. It says either the target margin has to fall, or c has to fall, or the feature cannot be given away to everyone. Deciding which, in advance and explicitly, is the entire value of doing this calculation before the launch instead of during the following year’s planning.

A partial version is often the answer: raise the price by a defensible amount, accept a few points of margin, and cap u so the tail cannot run away. The formula tells you what each of those three concessions is worth, so the trade can be made deliberately.

Three options and their conditions

Bundle into the existing price

Right when the feature’s job is retention or competitive parity rather than revenue; when u is naturally bounded; and when adoption itself is the point, because charging separately would suppress the adoption you need. Wrong when u is unbounded, because you have written a blank cheque denominated in someone else’s usage. If you bundle, cap.

Sell it as an add-on or a higher tier

Right when the buyers who value it are identifiable, when the value is concentrated in a minority, and when you want a clean revenue line to prove the feature works. Costs: adoption is limited to those who buy, which weakens the feature’s effect on retention for everyone else, and you have made your most differentiating capability optional at the moment competitors are including theirs. A higher tier also forces a decision about existing customers, which is the sequencing problem below.

Meter it

Right when usage varies enormously across customers, when value scales with usage, and when the unit is legible to the buyer. Costs: the risk premium the buyer applies to an uncertain bill, and the suppression of the usage you were trying to create — both quantified in why usage-based pricing is hard. Metering a brand-new feature is the hardest version of this, because the buyer has no prior for what it will cost them.

The adoption paradox

The three options interact with adoption in opposite directions, and this is the core tension:

Bundled:   adoption is high, revenue per use is zero,
           margin falls as the feature succeeds.

Add-on:    revenue per use is positive, adoption is
           capped by willingness to buy, retention
           benefit reaches only the buyers.

Metered:   revenue tracks cost, adoption is dampened
           by price salience at the moment of use.

There is no shape that gives high adoption, positive
revenue and no price salience at once. Choose which
one you are giving up.

There is one combination that mitigates the tension rather than resolving it: bundle a real but bounded allowance, and meter beyond it at a price above cost. Adoption is unimpeded for the majority who stay within the allowance, the margin floor is protected against the tail, and the price salience appears only for the users who have already demonstrated that the feature is worth something to them. It is a more complicated invoice, and it is the only shape that does not force the choice above.

The choice follows from what the feature is for. If it exists to stop churn, adoption is the objective and bundling with a cap is coherent — the cost is a retention expense and should be argued as one. If it exists to open a new budget, an add-on or metering is coherent, and the reduced adoption is the price of a measurable line. What does not work is bundling for adoption and then being surprised by the margin, or metering for revenue and then being surprised by the usage.

Sequencing, so you can change your mind

• Launch with a limit, not with a promise. A stated allowance can be raised later without a customer conversation. “Unlimited” cannot be walked back without one, and walking it back is among the most damaging things a product can announce.
• Measure a and u from day one, per plan and per cohort. The dilution formula is only useful with real values in it, and they are only obtainable if the instrumentation shipped with the feature.
• Decide the grandfathering rule before launch. Whether existing customers get the feature at their current price is a decision with a large revenue consequence, and deciding it under pressure after an announcement produces the worst of both.
• Re-run the arithmetic when c moves. A halving of inference cost can turn an unaffordable bundle into an affordable one; the decision has an expiry date, and revisiting it is cheap.