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.

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
• 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. 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.

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.