Product & Delivery · Chapter 7 of 13
Pricing and unit economics
Named in 39% of product postings. The half of product management that engineers-turned-PMs most often skip.
Cost and budget language appears in 39% of product postings and 42% of delivery ones. For anything with variable cost per use — which now includes most AI features — this is not a finance concern you can delegate.
The three numbers
- Cost to serve one unit of value. Not cost per API call — cost per resolved task, including retries, failures and human escalation. The denominator is the whole question.
- The distribution, not the mean. A small tail of expensive users can invert the margin while the average looks healthy. Price against the 95th percentile, not the median.
- Willingness to pay, which is anchored on what they do today. A customer paying three people to do something manually has told you the ceiling.
Structures, and what each protects against
| Structure | Protects you from | Costs you |
|---|---|---|
| Per seat | Usage spikes | Revenue when usage grows and headcount does not |
| Usage tiers with overage | Unbounded cost | Budget predictability for the customer — a real enterprise objection |
| Seat plus fair-use cap | Both, mostly | Complexity in the sales conversation |
| Pure pass-through | Margin risk entirely | Enterprise deals — nobody can budget for it |
| Outcome-based | Nothing, until you can measure the outcome reliably | A measurement dispute with every customer |
Two things to insist on from day one
Instrument cost per customer immediately. You cannot retrofit it, and without it you will not discover the loss-making segment until it is large.
Build a circuit breaker — a per-account spend cap that degrades rather than bills without limit. The first real incident in any usage-priced product is a runaway loop on one account, and it is much better to have decided in advance what happens.
The models, and what each one does to behaviour
| Model | Aligns with | Breaks when |
|---|---|---|
| Per seat | Team size, and it is easy to forecast on both sides | Value is not per person. An automation product that reduces headcount is priced to shrink as it succeeds |
| Usage | Value delivered, and it grows with the customer | Bills become unpredictable, which procurement hates — and a customer surprised by a bill churns even while getting value |
| Tiered | Simple to buy and to explain | Customers sit just under a boundary and optimise against you rather than using the product |
| Platform fee plus usage | The common compromise — predictable floor, upside as usage grows | Adds a barrier for small customers, which can close off the bottom of the market entirely |
The question that actually decides the model: what grows when the customer gets more value? If it is people, price per seat. If it is volume, price on volume. If it is neither — and for automation products it frequently is neither — you have a genuinely hard pricing problem and no standard model resolves it.
The metric that decides whether the pricing is working
Net revenue retention: revenue from existing customers this year against last year, including expansion and churn. It is the single most informative number about a subscription business.
Above 100% means the existing base grows without any new customers. That is the property investors pay for, and it is almost entirely a function of whether the pricing model captures growing value.
Per-seat pricing on a product that reduces headcount produces retention below 100% structurally — every successful deployment shrinks the account. No amount of customer success work fixes a pricing model that is short its own product.
Which is why AI-era pricing is genuinely unsettled. If the product does work that people used to do, seats are the wrong unit and outcome-based pricing is hard to measure and harder to bill. Most vendors have landed on usage as a proxy, which is honest about being a proxy.
The engineering consequence, which is where this touches your work: whatever unit you bill on has to be measurable, attributable and defensible to a customer disputing an invoice. That is a metering system with an audit trail, and it is real engineering that is routinely discovered late.
Check yourself