There is a product chart that can make an entire team feel good. Usage is up. Adoption is accelerating. Customers are coming back. The feature is working exactly as designed.
Then somebody looks at the economics, and the bill is growing faster than the value.
That is one of the stranger product lessons of the current software economy: growth can make a product economically worse.
The old intuition is not always safe
Software trained a lot of product people to treat usage as close to pure upside. Build the code once. Serve another user at relatively low incremental cost. Drive adoption. Improve retention. Scale.
That model still works for plenty of products. It is just not universal.
Some product behavior has meaningful variable cost: AI inference, third party API calls, payment processing, logistics, human review, Customer Support, fraud exposure, content licensing, delivery subsidies, anything where more usage creates more real expense.
Once that happens, the relationship between adoption and business health changes. More can still be better, but you have to prove it.
The feature can work and the economics can still fail
Imagine an AI assistant inside a supply chain platform. In beta, customers love it. They use it to reroute delayed shipments and answer routine questions. Support ticket volume falls. Sales has a new AI story. Product wants broad access because the usage signal is strong.
There is just one problem: every interaction costs money, and the heaviest users are also the most expensive customers to serve.
At low usage, the feature looks healthy. At high usage, the economics start to bend in the wrong direction. Nothing is wrong with the user experience. Nothing is wrong with adoption. The problem is the relationship between usage and value capture.
The feature worked. The economics did not.
Growth amplifies the unit underneath it
The math is simple enough to say out loud. If each additional unit of usage creates less incremental value than incremental cost, adding more units makes the problem larger.
That can hide inside an organization because different teams own different parts of the story. Product sees adoption. Support sees ticket deflection. Sales sees differentiation. Engineering sees infrastructure demand. Finance sees cost to serve.
Everybody can be right locally. Somebody still has to connect the system.
Suppose a feature saves $2 of Support cost per active customer but creates $3 of additional variable cost elsewhere. The feature did not create a $2 efficiency win. It moved one cost and created another.
Or suppose retention improves, but the customers using the feature most heavily require enough ongoing subsidy that the lifetime economics deteriorate.
Growth does not repair a bad unit. It gives the bad unit more volume.
This is bigger than AI
AI makes the problem obvious because inference cost is visible and usage can expand quickly, but the pattern exists anywhere success carries a meaningful cost.
A delivery product can grow order volume while subsidies or last mile costs destroy the economics. A marketplace can grow transactions while fraud losses or support requirements rise faster than captured fees. A payments product can increase volume while processing economics differ sharply by transaction type. A service heavy enterprise product can retain customers while implementation and support burden quietly expand faster than revenue.
The question is not whether growth is good or bad. The question is: What kind of growth are we creating?
A growth target without an economic companion is incomplete
Suppose the team has a goal of getting 60% of customers to use a capability every week. That may be a perfectly reasonable product target.
It is incomplete if nobody has asked what the economics look like at 60%.
What is the variable cost per active customer? How does usage differ by segment? Do the heaviest users pay more, create more strategic value, or simply cost more? What cost is genuinely displaced elsewhere? Does an automated workflow remove expense from the business or just free capacity that gets used for something else? What happens at twice the expected adoption?
The point is not to make every growth target conditional on a finance model. The point is to make sure the team is not accidentally rewarded for creating behavior the business cannot sustain.
Product has more levers than “turn it off”
Once you can see both curves, the conversation gets more useful. Finance may look at the cost curve and want to shut the feature down. Product may look at the adoption curve and want unlimited access.
Those are not the only choices.
You can change packaging, create usage tiers, include a baseline allowance, charge for higher volume, use cheaper infrastructure for routine requests, route complex work differently, target segments where the value is high enough to support the cost, or redesign the experience so customers reach the same outcome with fewer expensive actions.
Sometimes the fix is commercial. Sometimes it is technical. Sometimes it is product design. Often it is some combination of all three.
The goal is not to punish customers for loving the feature. The goal is to find a sustainable relationship between the value they receive and the cost the company incurs.
Segment the economics before the average hides them
Average economics can make a bad product decision look fine. A small group of power users may create most of the cost. Large enterprise customers may generate enough value to justify expensive behavior while smaller accounts do not. One workflow may be both highly valuable and highly expensive while another costs almost nothing.
That changes the answer.
Instead of asking only whether the feature is profitable on average, ask where the economics are strong and where the business is subsidizing behavior. That gives Product better options than “raise the price” or “kill the feature.”
You can put expensive behavior in the right tier, focus the product on the segment where the economics work, or redesign the costly path itself.
Every growth metric needs an economic shadow
I like pairing growth measures with a second question. Usage is up: what happened to cost to serve? Transactions are up: what happened to variable profit? Retention improved: what happened to lifetime economics? Orders increased: what happened to fulfillment cost? Adoption is accelerating: what happens if it doubles again?
Not because every PM needs a finance dashboard open all day. Because growth without economics can create false confidence.
The curve goes up and the team assumes the business is healthier. Sometimes the curve is telling you the opposite.
The worst time to discover bad economics is after growth works
There is something perverse about building a feature people love and then discovering that you cannot afford for them to love it this much.
That is not a reason to fear usage. It is a reason to understand the economic architecture before scale arrives.
The feature did its job. Customers changed their behavior. Demand arrived. And every new unit of success made the business a little worse.
Growth is not the enemy. Growth with bad unit economics is.