After writing about why AI ROI fails at the portfolio level and why feature-level measurement is the discipline most organizations are missing, the most common follow-up question I’ve received is a reasonable one: fine, but how do you actually do it?
This post answers that question directly. What follows is a named framework — the Feature Economics Model — built from what I’ve observed work in practice inside enterprise software organizations. It is not a vendor product. It is a measurement discipline, and it can be implemented with tooling most organizations already have.
It is designed to be understood by a CTO, actionable by a VP of Engineering, and explainable to a board.
Why a Named Framework Matters
Measurement disciplines only stick when they have a shared name. “Feature-level ROI” is a concept. The Feature Economics Model is a practice a team can say they are running, a CFO can put on an agenda, and a board can ask about by name.
The three components of the model are:
- The Feature Register — a living inventory of every AI capability in production or active development, with ownership and business objective assigned to each
- The Feature P&L — a cost and return accounting applied to each entry in the register, before deployment and reviewed quarterly after
- The Economics Gate — a pre-deployment checkpoint that no AI feature passes without a completed cost model and a defined return hypothesis
Each component is simple on its own. The discipline is in running all three together, consistently.
Component 1: The Feature Register
Most organizations cannot tell you, with confidence, how many AI-powered features they have in production. They can tell you what vendors they’re paying. They can estimate total AI spend. But a clean list of discrete AI capabilities — including what each one does, who owns it, what business outcome it was built to move, and what it costs to run — almost never exists.
The Feature Register fixes that. It is a single source of truth, maintained by engineering and reviewed by the CTO, that answers five questions for every AI feature:
| Field | Question It Answers |
|---|---|
| Feature name | What is it, specifically? |
| Business objective | What outcome was it built to improve? |
| Owner | Who is accountable for its performance? |
| Deployment stage | Pilot, production, or scaling? |
| Last reviewed | When was its economics last examined? |
This is not a complex database. It is a structured page to be updated whenever a feature ships or exits. The act of building it is itself diagnostic. Most organizations will find features they forgot about, costs with no owner, and objectives that were never defined.
Component 2: The Feature P&L
For every entry in the Feature Register, the Feature P&L captures four dimensions, two on the cost side, two on the return side.
Cost Side
Build Cost is what most teams already track, imperfectly: engineering hours, model evaluation, prompt engineering, integration testing. The undercount is the iteration cycles required to move from working demo to production-grade reliability. Budget these explicitly because AI features rarely ship clean on the first build.
Run Cost is where most organizations are flying blind. It has four components that belong in the model:
- Inference cost — token consumption × call volume, modeled at expected production scale, not pilot scale. These numbers are not the same. A pilot with 50 users does not predict what happens with 5,000.
- Operational overhead — retry logic, context window growth, tool call chains in agentic workflows. Each adds cost that is invisible in development.
- Human review labor — if the feature requires a human to validate a percentage of AI outputs before they reach customers, that labor cost belongs in the model. It is a direct cost of the AI feature.
- Maintenance and drift — model providers update their models. Prompts that performed well last quarter degrade. Retrieval pipelines need retuning. These are recurring costs, not one-time costs.
Return Side
Hard Return is what finance can validate independently: time saved expressed in fully-loaded labor cost, error rates reduced, support tickets deflected, revenue directly attributable to the feature. If a number requires the engineering team to self-report it, it is not a hard return.
Soft Return is real but requires discipline to use honestly: customer satisfaction delta, adoption rate, decision quality, time-to-market acceleration. These belong in the model but they cannot be the only thing in the model. Organizations that measure AI value exclusively through soft metrics are building a story, not an accounting.
If the cost side cannot be completed before a feature ships, the feature is not ready to ship. The build cost should be known. The run cost should be modeled from expected call volume. The return hypothesis should be defined in terms finance can validate within a defined time window.
Component 3: The Economics Gate
The Economics Gate is a pre-deployment checkpoint. It is not a bureaucratic approval process. It is a single conversation. Make it sixty minutes with the feature owner, the CTO or VP Engineering, and someone from finance. The outcome is a completed Feature P&L before the first production deploy.
Three questions must be answered to pass the gate:
What does this feature cost at scale?
Not at pilot. Not at internal testing. At the expected production call volume, with realistic usage patterns. If the answer is “we’ll know after we ship,” the gate is not passed.
What business outcome does this feature move, and how will we know?
The outcome must be specific and measurable. “Improve customer experience” does not pass the gate. “Reduce average support resolution time by 20% within 90 days” does. The measurement method and baseline must be defined before deployment.
Who owns the economics of this feature after it ships?
The gate must produce a named owner — not a team, not a function — a person who is responsible for the quarterly P&L review and accountable for the return hypothesis.
Organizations that resist the Economics Gate usually do so for one of two reasons: they don’t want to slow down, or they don’t want to be held to a return they aren’t confident they can deliver. Both are diagnostic. The gate exists precisely because those pressures, unchecked, are what produce the 95% of pilots that deliver no measurable P&L impact.
Running the Model in Practice
The Feature Economics Model is a quarterly operating discipline, not a one-time audit.
Month 1: Build the Register
Inventory every AI feature in production or active development. Assign ownership and identify the features with no defined business objective. There will be some — and you have to decide whether they get one or get retired.
Month 2: Build the P&Ls
For each feature in production, complete the cost side from cloud invoices and engineering records. Build the return side from product analytics and finance data. Treat the gaps as an instrumentation roadmap: where you can’t answer the question, build the logging that will let you answer it next quarter.
Month 3: Run the First Quarterly Review
Bring the register and P&Ls into a structured review with the CTO, CFO, and relevant product owners. Make three types of decisions: which features to scale (strong return, manageable cost), which to optimize (strong return, cost exceeding model), and which to retire (weak return, ongoing cost).
Ongoing: Gate Every New Feature
From this point forward, no AI feature enters production without a completed Feature P&L and a named economics owner.
What This Produces for the Board
The Feature Economics Model gives the CTO something most currently lack: a specific, defensible answer to the ROI question.
Not “AI is improving developer velocity.” Not “adoption is up 40%.” Something like: “We have eleven AI features in production. Seven are returning positive unit economics against their cost models. Three are in optimization — we’ve identified the cost drivers and have a plan to address them by Q3. One has been retired. Here is the aggregate return against the aggregate investment, broken out by feature.”
That answer does not require a heroic data infrastructure effort. It requires the discipline to build the register, complete the P&Ls, run the gate, and hold the quarterly review.
The executives who establish that discipline now will have a compounding advantage: every quarter of data makes the next deployment decision sharper, the next board conversation more credible, and the next AI investment better allocated.
The Honest Caveat
The Feature Economics Model will surface things that are uncomfortable. Features that looked like wins are more expensive than anyone modeled. Features that were shipped under pressure have no return hypothesis anyone can articulate. Costs that were reported as infrastructure are really AI feature costs that were never attributed.
That discomfort is the point. The model does not create problems — it reveals them. And problems revealed early, while they are still bounded and recoverable, are significantly cheaper than problems discovered on the cloud invoice at the end of the quarter.
Build the model. Run the gate. Hold the review.
The boardroom question isn’t going away. You might as well have the answer.