Adding AI does not make the product better: features without outcome metrics are costs

On October 24, Apollo chief economist Torsten Slok published an uncomfortable set of charts. Remove the seven largest tech companies from the S&P 500, and revenue per worker and profit margins across the remaining 493 companies have barely moved. The charts put inflation-adjusted revenue per worker around $780,000 for the Magnificent Seven versus roughly $525,000 for the S&P 493; margins sit near 30% versus about 10%.

This does not mean AI is useless. It means installing a tool, connecting a model and increasing usage only prove that technology was used. A product proves itself when revenue, retention, cycle time or error rates actually improve.

Usage is the easiest metric to fall in love with

Ramp data cited in the analysis shows 99.5% of model-serving and inference spend concentrated in the top 10% of companies, with 95.6% of OpenAI and Anthropic spend coming from that same group. Concentrated spending is not the same as demonstrated return. For early teams, the dangerous moment is when a rising call count gets mistaken for product-market proof.

Usage answers “how much,” not “why pay.” A support assistant can draft 1,000 replies a day and still create more handoffs. A coding assistant can add 20,000 lines while increasing rework and production failures. Faster output is not value when it accelerates the wrong thing.

Take a baseline photo before launch

Many features can never show a return because nobody recorded the old workflow. Pick one primary outcome and two guardrails before work starts. For support, the primary metric might be average handling time, with first-contact resolution and complaint rate as guardrails. For sales, use qualified opportunities, then watch unsubscribe rate and review time.

Suppose a feature cuts handling time from 18 minutes to 11 but pushes repeat contacts from 7% to 15%. That is not success; it moved cost from the front of the workflow to the back. A complete product manages the whole bill, not one attractive screenshot.

One result card is enough for an early team

• Write the outcome before the feature. Replace “add smart summaries” with “cut report preparation from 40 minutes to under 20.” The first cannot be accepted; the second can be tested in a week.
• Run one two-week experiment. Use ten real users and keep a small comparison group without the new feature. Review the outcome and guardrails after two weeks instead of extending the project on meeting-room confidence.
• Delete what does not earn its place. Money already spent is not a reason to maintain a feature forever. If nobody pays for the result, maintenance only makes the loss larger.

At 51kaifa.app, early-product requirements pair every feature with an acceptance number: who uses it, how long the task takes now, what the target is, and which two side effects must not get worse. Development does not end when a button appears. It ends when the team can hand a customer a result they can verify. For a budget-constrained startup, that is the most valuable form of product completeness.