Cost-per-feature (not cost-per-PR)

Cost-per-feature is the total cost - in AI compute, CI infrastructure, human review time, and product management time - to deliver a complete user-facing feature from specification to production. It's the L5 replacement for cost-per-PR, which measures the cost of a code change but not the cost of delivering business value.

The distinction matters because PRs and features have very different relationships depending on how work is structured. At L4, a "feature" might be 20-100 PRs: the initial implementation, tests, bug fixes, documentation, configuration changes, and post-deploy cleanup. Cost-per-PR tells you how much each individual PR cost. Cost-per-feature tells you how much it cost to ship the thing that users actually experience. At L5, cost-per-feature is the unit of measure that connects engineering investment to business outcomes.

The shift from cost-per-PR to cost-per-feature requires tracing costs across the entire feature delivery lifecycle. This is harder than tracking per-PR costs because features span multiple sprints, involve multiple developers and agents, and have costs that don't neatly correlate with PR count. A feature that required extensive design iteration before any code was written has high cost even if it was implemented in a few PRs. A feature that was implemented through many small PRs but required minimal design might have lower total cost than the PR count suggests. Cost-per-feature accounts for all of this.

One pairing is mandatory, and this edition makes it explicit: cost-per-feature must be reported alongside incidents-per-merged-change and hours spent firefighting them. Those two move in the opposite direction to throughput, and a scorecard that shows only the first half is marketing rather than measurement. Reuters' special report on Meta's Project OT, published 2026-08-26, is the demonstration. Changes to internal platforms were up 220% year over year and changes reaching users as features up 36% - genuinely impressive delivery numbers. In the same period, major technical and security incidents were up 40% and time spent firefighting them up 70%. Meta's infrastructure teams had warned about unchecked agents performing "large-scale, disruptive actions that humans are unlikely to execute". Report the 220% without the 40% and you have described half a system.

The macro picture supports the same discipline. McKinsey's State of AI 2026, published 2026-08-25 across 1,719 respondents, found 37% attributing at least some EBIT impact to AI and only 6% qualifying as high performers at 5% or more of EBIT - both statistically flat against 2025 despite record spend, even as 80% of individual users reported personal productivity gains. That gap between felt productivity and booked earnings is precisely what a per-feature cost model, paired with its counterweight metrics, exists to explain. Note too that 20% of respondents said AI operating costs had constrained further adoption, which makes cost-per-feature a planning input rather than a reporting nicety.

At L5, cost-per-feature typically reveals a significant counterintuitive finding: the AI compute and CI costs are a small fraction of total feature cost. Human time in design, planning, product management, and final review often dominates the cost. This shifts the optimization target: the next big leverage point isn't cheaper AI iterations or faster CI - it's reducing the non-AI overhead of feature delivery through better specification tooling, autonomous planning agents, and reduced human coordination overhead.

• Aligns engineering metrics with business metrics - business stakeholders think in features, not PRs; cost-per-feature is the engineering metric that speaks the language of product, finance, and leadership
• Reveals the true cost of complexity - features that seem simple to implement often have high coordination and planning costs; cost-per-feature makes this visible and creates incentive to reduce unnecessary complexity in the planning process
• Enables feature-level ROI comparisons - with cost-per-feature data, you can compare: "this feature cost $12,000 to build and has generated $400,000 in revenue" - a direct ROI calculation that's impossible with cost-per-PR
• Identifies where the cost model has shifted - at L5, AI and CI costs are cheap; human judgment, product decisions, and architectural choices are expensive; cost-per-feature makes the new cost structure visible so investment can follow
• It is now a build-versus-buy input - nearly a third of McKinsey's respondents decided not to buy a software feature and built it with agentic coding tools instead; that decision is only defensible if you know what building the feature actually costs, including the maintenance and incident load it brings with it
• Provides the baseline for L5 autonomous feature delivery - to build autonomous feature delivery agents, you need to understand current feature cost in detail; cost-per-feature is the baseline measurement that defines what "autonomous" needs to beat

1. Define "feature" in your context - A feature is a user-facing capability that can be independently described in a user story or product requirement. Not every PR is a feature. Not every feature maps to a single epic. Agree on the unit of analysis with your product team before building cost tracking.
2. Connect engineering work to feature tags - Tag PRs, tickets, and agent tasks with the feature they belong to. This requires a consistent tagging convention across your project management system, version control, and CI pipeline. A feature ID that flows through the entire system is the prerequisite for feature-level cost aggregation.
3. Aggregate costs by feature - For each feature, sum: AI token costs for all agent tasks tagged to the feature, CI compute costs for all CI runs on feature-tagged PRs, and an estimate of human time (developer hours + product manager hours + design hours) converted to cost at fully-loaded rates. The resulting number is cost-per-feature.
4. Establish cost-per-feature benchmarks by feature type - Not all features cost the same. A UI polish feature might cost $2,000. A new payment integration might cost $40,000. Establish benchmarks by feature type and flag outliers: features that cost 2x the benchmark need investigation. Were they over-specified? Did they require excessive iteration? Was the implementation approach suboptimal?
5. Track cost-per-feature trend quarterly - As AI workflows mature, cost-per-feature should decrease for equivalent feature types. If it's not decreasing, identify which cost components are stable (AI costs, CI costs) and which are not (human coordination costs). The stable components are the next optimization targets.
6. Report the counterweight metrics on the same page - incidents-per-merged-change and firefighting hours, over the same period, in the same review. Not an appendix, not a separate reliability report. If delivery is up 36% and incidents are up 40%, both numbers belong in the same sentence.
7. Adopt the CFO vocabulary deliberately - Useful Work, Cost per Successful Task and Return on Compute are the three lines that survive contact with a finance function, and they map cleanly onto what you are already computing: features actually delivered and used, cost-per-feature divided by success rate, and value per unit of compute spent. Using their words is what gets the metric into the quarterly review rather than the engineering wiki.
8. Connect cost-per-feature to feature value - Pair cost-per-feature with feature outcome metrics: usage rate, revenue impact, customer satisfaction improvement, support ticket reduction. Features where cost is high and value is low should trigger retrospectives: was this the right feature to build, or could agents have explored a lower-cost alternative?

Conflating cost-per-feature with cost-per-PR at scale. Some teams compute cost-per-feature by summing cost-per-PR for all PRs in a feature. This works but misses the non-PR costs: design time, product management time, stakeholder review time. These non-code costs often exceed the code costs at L5. An accurate cost-per-feature calculation requires accounting for the full delivery lifecycle.

Using cost-per-feature to justify cutting product management overhead. When cost-per-feature analysis reveals that PM and design time dominates the cost, the wrong response is to cut PM and design involvement. The right response is to make PM and design more efficient: better specification templates, autonomous research agents, AI-assisted design exploration. Cutting oversight creates riskier features, not cheaper ones.

Not normalizing for feature complexity. A $30,000 feature isn't inherently worse than a $3,000 feature - it might just be more complex or more valuable. Compare cost-per-feature within complexity tiers (small/medium/large features) rather than using a single benchmark across all features. Complexity normalization is what makes the metric fair and useful.

Treating cost-per-feature as an individual team metric. Feature delivery involves product, design, engineering, and QA. Cost-per-feature is an organizational metric, not an engineering metric. Present it to cross-functional leadership and ensure that cost reduction initiatives address all the components, not just the engineering ones. Engineering-only cost optimization misses the majority of the leverage.

Reporting throughput without its counterweight. This is the pitfall of the year and it needs no subtlety: any cost-per-feature report that shows delivery going up and says nothing about incidents and firefighting is not measuring, it is selling. Meta's own telemetry has changes to internal platforms up 220% alongside incidents up 40% and firefighting up 70%. Both halves are real. Put them next to each other.

Assuming the productivity that individuals feel shows up in the accounts. McKinsey has 80% of individual users reporting personal productivity gains against an EBIT impact that is statistically flat year over year. Cost-per-feature is one of the few metrics positioned to explain where the difference goes, but only if the calculation includes the costs that do not feel like productivity: rework, incidents, coordination, and the maintenance tail of everything shipped. Note also the counter-evidence worth carrying honestly - Meta's second wave of team reductions was cancelled hours before execution, partly because internal data showed autonomous agents were not delivering the expected productivity gains, and Meta disputes the wider framing of that reporting.

Not accounting for failed features. Some features are built but never shipped, or are shipped and then removed because they didn't achieve their goals. These failed features had real costs. A healthy cost-per-feature metric includes failed features in the calculation - it measures the full cost of the organization's feature bets, not just the successful ones. Excluding failures understates the true cost of product development.