AI Product Economics: Every Feature Has a P&L

Every customer-facing AI feature has a P&L whether the product team acknowledges it or not.

That is one of the biggest changes AI brings to software economics.

Traditional SaaS features usually had marginal costs, but they were often small enough to ignore at the feature level. Storage, compute, bandwidth, support, and infrastructure mattered, but the cost of one more user clicking one more button was rarely the center of the product decision.

AI changes that. A feature can now generate meaningful variable cost every time it is used. The cost can vary dramatically depending on prompt length, context size, model choice, retries, retrieval, tool calls, latency requirements, moderation, and human review.

That means product decisions are cost decisions. Pricing decisions are architecture decisions. Model routing is margin management. Context policy is financial design. Gross margin becomes a product requirement, not a spreadsheet someone checks after launch.

Start with inference COGS.

Inference COGS is the direct cost of serving AI output to customers. At minimum, it includes model input and output costs. But a serious view includes the full chain: embeddings, retrieval, reranking, context assembly, model calls, cached context, retries, tool calls, safety checks, logging, monitoring, evals, human review, support burden, and cloud infrastructure.

If a product team only tracks model API cost, it is undercounting.

A customer asks a question. The product retrieves documents. It expands context. It calls a premium model. The answer fails a quality check. It retries. Then it calls a tool. Then it generates a summary. Then a human reviews a flagged response. Later, support handles a complaint because the answer was incomplete.

The token bill is only part of the economics.

The second concept is cost per successful outcome.

Cost per response is useful but incomplete. Some responses do not create value. Some are abandoned. Some are corrected. Some trigger support. Some create trust. Some drive conversion, retention, or expansion.

The better question is: what does it cost to produce the outcome the customer actually values?

Cost per resolved support issue. Cost per qualified research brief. Cost per accurate document summary. Cost per successful workflow completion. Cost per approved generated report. Cost per retained customer using the AI feature.

This is where product and finance need a shared model. Product knows the workflow. Finance knows the margin structure. Engineering knows the technical drivers. Customer success knows where the customer feels value or pain.

The third concept is customer-level profitability.

AI can make average gross margin misleading. One customer may use lightweight features occasionally. Another may hammer a high-context workflow all day. A third may require complex retrieval across huge data sets. A fourth may generate large support burden because their use case sits near the edge of model reliability.

If pricing is flat, heavy AI users can become margin sinks. That may be acceptable if they are strategic, expanding, or paying enough. It is dangerous if nobody knows.

AI FinOps should help product teams see profitability by customer segment, plan, usage pattern, and feature. Not to punish customers for using the product, but to understand whether packaging and architecture match the business model.

The fourth concept is model routing.

Not every task needs the best model. Some tasks need a frontier model. Some need a fast cheap model. Some need rules. Some need retrieval. Some need a human. Some need a sequence: cheap model first, premium model only when confidence is low or value is high.

Model routing is how product teams turn intelligence into an economic system.

Use premium models where better reasoning changes the outcome. Use cheaper models where the task is constrained. Use cached outputs where freshness does not matter. Use smaller context where full history adds cost without value. Use batch processing where latency is not critical. Use human review where risk is high.

The wrong approach is one-model-fits-all. That is how demos become expensive products.

The fifth concept is context discipline.

Context feels free because it improves quality in prototypes. In production, context is a cost and latency decision. More context can improve output, but it can also add noise, increase cost, slow the experience, and hide poor retrieval design.

Product teams need context policies. What context is required? What is optional? What expires? What can be summarized? What can be cached? What data should never enter the model? What context length is allowed by plan, customer tier, or workflow type?

Context is not just an engineering detail. It is part of the product’s cost structure.

The sixth concept is pricing and packaging.

If cost scales with usage but revenue does not, margin is exposed. That does not mean every AI product should charge per token. Buyers often hate token pricing because it maps to vendor cost, not customer value. But the price metric has to acknowledge the economic reality.

Possible patterns include premium tiers with included AI usage, usage allotments, workflow-based limits, outcome-based packaging, overage pricing, customer-tier routing, admin controls, and enterprise commitments. The right answer depends on buyer expectations, value clarity, predictability, and cost volatility.

The key is that pricing cannot be designed after the AI feature scales. It has to be considered while the product is being built.

The seventh concept is support burden.

AI features create new support categories: wrong answers, unclear provenance, missing context, slow responses, hallucinations, permission confusion, unexpected charges, output disputes, and trust breakdowns. Those costs belong in the P&L.

A feature that looks profitable on inference alone may be unprofitable once support and review are included. A feature that reduces support volume may justify higher inference cost. Again, the point is not to minimize spend. It is to understand the full system.

The operator rule is blunt: do not ship AI features whose economics only work in the demo.

Before scaling a customer-facing AI feature, teams should know:

What is the direct inference cost? What drives variation? What is the expected usage pattern? Which customers are heavy users? What is the cost per successful outcome? What support burden exists? What model routing is in place? What context policy exists? How does pricing recover value? What gross margin threshold must the feature meet? What happens to margin if the heaviest 10 percent of customers use it twice as much as expected?

AI product economics are not a finance cleanup exercise.

They are part of product strategy.