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.

·Cost-per-feature is tracked (not cost-per-PR) - aggregating all agent, CI, and review costs per delivered feature
·Business value throughput is the primary metric (features delivered per week, not PRs merged per week)

·Metrics system auto-detects vanity metrics (high activity, low value delivery) and flags them
·Cost-per-feature trend is declining quarter-over-quarter

Evidence

·Cost-per-feature dashboard with feature-level cost attribution
·Business value throughput chart correlated with product delivery milestones
·Quarter-over-quarter cost-per-feature trend report

What It Is

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.

Why It Matters

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

Getting Started

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

Tip

The hardest part of cost-per-feature tracking is estimating human time. Developers rarely track time per feature. Rather than building complex time-tracking systems, use a proxy: calendar time from feature kick-off to production deploy, multiplied by the number of people actively working on it, multiplied by a utilization factor (70-80%). This produces a rough but defensible human cost estimate without requiring granular time tracking.

6 steps to get from here to the next level

Common Pitfalls

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.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob is presenting the AI program's value to the board. He has detailed cost-per-PR data, throughput metrics, and CI efficiency numbers. But the board is asking: "What does it cost to ship a feature now compared to two years ago?" Bob doesn't have a direct answer because he's never tracked at the feature level.

What Bob should do: Bob should build a retrospective cost-per-feature estimate for three representative features: one from two years ago (before AI tooling), one from one year ago (early AI adoption), and one from the current quarter (mature L4 workflows). For each, he should estimate the total cost using the available data: engineering hours (from Jira tickets and calendar records), PR counts (from git history), and today's AI/CI costs for the current feature. The trend line across the three features - even with rough estimates - will show meaningful cost reduction. Bob should present this at the board with honest caveats about estimation methodology and a commitment to systematic cost-per-feature tracking going forward. An imperfect retrospective is far better than silence.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah has been tasked with designing the L5 metrics framework for the engineering team. She wants to move from activity metrics (PRs, commits) to outcome metrics (features shipped, user value delivered). Cost-per-feature is the bridge between engineering activity and business outcomes.

What Sarah should do: Sarah should build a pilot cost-per-feature tracking system for one team over one quarter. The system needs three inputs: feature tagging in Jira (feature ID applied to all tickets), PR tagging in GitHub (same feature ID applied to all PRs), and a simple time estimation survey (developers estimate hours spent on each feature at sprint close). From these three inputs, Sarah can compute a rough but directionally accurate cost-per-feature for every feature shipped in the quarter. After one quarter of data, Sarah should identify: which feature types have the highest cost, which have the highest cost-to-value ratio (using any available product metrics), and where the biggest cost reduction opportunities are. This analysis is the foundation for the L5 roadmap.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor is already thinking at the feature level. He tracks, informally, how long it takes him to deliver complete features from task specification to production: 2-3 hours for small features with his agent workflows, 1-2 days for medium features. He knows these numbers are dramatically better than the team average but doesn't have the data to prove it systematically.

What Victor should do: Victor should instrument cost-per-feature tracking for his own work for one quarter. He should tag every PR he works on with the feature it belongs to, log his agent session times and costs using Claude Code's built-in usage tracking, and record his time estimates per feature. At the end of the quarter, he'll have a per-feature cost breakdown that shows: AI compute cost, CI cost, and his own time (the expensive part). Victor should then analyze whether there are patterns in which features cost more or less than expected and what drove the variance. This personal cost-per-feature analysis is the most credible possible argument for the L5 investment: real data, from a real feature portfolio, showing what autonomous feature delivery actually costs.

What Victor should do - role-specific action plan