Six months ago, a software team could reasonably focus on getting an AI feature into customers' hands. The product was changing quickly, usage was uncertain, and the first instrumentation often followed the model API. That first view is useful for debugging. It is not enough to understand gross margin.

In 2027, the relevant unit is not automatically the token, request, or model call. It is the unit that connects an AI workload to what the customer buys: a customer account, a feature, a completed workflow, or another product unit with meaning in the company's pricing and operating model.

Why averages conceal product risk

Two customers can use the same feature in very different ways. One may make occasional requests. Another may trigger long context, multiple tool calls, retries, and human review. A blended average can make the feature appear stable while a particular cohort or workflow erodes margin.

Start by defining the customer-facing work and the cost boundary. Include the model, retrieval, orchestration, hosting, retries, and other costs that are part of normal delivery. Explain how shared costs are allocated. Reconcile the total to provider invoices and show what remains estimated or incomplete.

Product review prompt: Which customer or feature has the widest gap between expected and observed AI cost, and what product decision does that gap change?

Separate what you are learning from what you are selling

Research workloads support product development. Production workloads support customer commitments. When a feature crosses that line, its cost treatment and owner need to change too. Leaving production AI inside a broad engineering or experimentation budget makes the product margin difficult to understand and the spending difficult to manage.

Six months ago, one combined AI total may have been the only number available. Build the transition into the operating model now. Label environments and workloads, state when a use case is considered production, and assign an owner to review exceptions. The rule matters more than a perfect tag taxonomy.

Optimize for gross margin and product quality together

Reducing cost per call does not guarantee better economics. If a cheaper model produces more retries, more escalations, or worse results, the cost of delivering the customer outcome may rise. Conversely, a more capable model can be economically sound if the feature enables a price or outcome customers value.

Every optimization should have a paired measure: cost per unit and a product-quality or customer outcome. Define the baseline before changing the system. State what result would justify the change and what result would cause the team to reverse it.

Use the measure to shape the product

Once teams can see cost at the customer or feature level, the result can inform packaging, limits, pricing, model routing, and product design. It may reveal that one feature needs a different interaction pattern or that a usage tier no longer matches delivery cost. Those are product choices, not merely infrastructure tasks.

Ask what your AI feature would look like if its cost per customer were visible in every roadmap review. Would the team scope it differently? Would pricing change? Would one workflow become a premium capability? If the number would change no decision, the metric is not yet attached to the business.

That is the shift for 2027: stop treating AI cost as a model statistic and start treating it as part of the product's cost to serve. Gross margin becomes legible when measurement follows the customer promise.