When does each shipped feature pay back its engineering cost, and how does revenue contribution compound after launch?
№ 195 · Feature ROAS curve
Definition
MetricCumulative attributable revenue from a shipped feature divided by its fully loaded engineering cost, over months since general availability
Unitratio of cumulative attributable revenue to $1 of engineering cost
Cumulative revenue lift attributable to a feature divided by engineering cost across months. Multiple feature cohorts compared. Build per-feature: track attributed revenue against eng cost monthly. Example: Top feature 1.0x at M4, hits 4.8x at M24; bottom feature never crosses 1.0x.
- ROAS
- Return on ad spend. Revenue attributed to a campaign divided by the spend on that campaign.
Benchmarks
| Bottom 30% | Median | Top 30% |
|---|---|---|
| Never crosses 1.0x. On Pendo's distribution, where roughly 80% of features are rarely or never used, this is the majority of what gets shipped rather than the exception. | Crosses 1.0x somewhere between month 9 and month 18 at portfolio level, consistent with a derived median of roughly $0.88 of R&D spend per $1 of net new ARR. At individual feature level the median feature never crosses it. | Crosses 1.0x within two to three quarters and compounds past 3x by month 24. At portfolio level this is what a company running R&D near 20% of ARR at top-quartile growth produces. |
Private B2B SaaS at portfolio level, derived from R&D as a percent of ARR against net new ARR using SaaS Capital and Benchmarkit 2024 and 2025 survey data, n=1,000+ companies each. Engineering cost is fully loaded, using ICONIQ's median R&D spend per employee of $200,000 to $250,000 as the unit cost. Individual-feature ROAS is not published by any Tier 1 source. · This chart cannot be benchmarked from published data at the feature level, and any source claiming to do so should be checked. The figures above are derived from portfolio-level spend and growth data and should be used to sanity-check a portfolio total, not to grade a single release. Three cautions. First, the distribution is extremely skewed, so a portfolio mean is meaningless and one launch will usually carry the total. Second, attribution is the binding constraint: without a plan boundary, meter or matched control the numerator is an assertion. Third, the correct comparator is not zero but the alternative use of the money, and Benchmarkit puts expansion CAC at $1.00 per $1 of ARR against $2.00 for new customer ARR, which is the hurdle a build has to beat.
Category split omitted: No Tier 1 or Tier 2 publisher reports revenue attribution against build cost at feature level for any category, so there is no split the data can support.
When it looks bad
Every individual feature curve is a near-flat line just above zero and the portfolio total only clears 1.0x because a single launch carries it, so the median release is a cost with no measurable return.
Eleven features shipped over 18 months at roughly $2.4M of loaded engineering cost. One reached 4.1x. Nine sat under 0.3x. Portfolio total 0.9x at month 18, still under break-even.
What to do about it
- Price at least one thing in every release, whether a plan boundary, a usage meter or an add-on SKU. Without a commercial mechanism attached the numerator on this chart is unattributable, which is the most common reason the curve stays flat rather than the feature being bad.
- Set an explicit portfolio budget split across new bets, expansion enablers and maintenance, and hold keep-the-lights-on work to the 10% to 15% band ICONIQ recommends. Portfolio ROAS is set by the mix long before any individual build is scoped.
- Test each proposed build against the expansion alternative rather than against zero. Benchmarkit puts expansion CAC at $1.00 per $1 of ARR against $2.00 for new customer ARR, so a build that will not beat a dollar of expansion spend is worse than the obvious alternative even if its own curve eventually clears 1.0x.
- Retire the flat tail rather than carrying it. Dormant features accrue maintenance and support cost on the denominator forever while contributing nothing to the numerator, which is the mechanism behind Pendo's estimate of up to $29.5 billion of cloud R&D tied to unadopted features.
Sources
- Pendo 80% of features in the average software product are rarely or never used, and 12% of features generate 80% of daily usage. Sets the base rate for how many curves on this chart stay flat. pendo.io ↗
- Pendo Estimates up to $29.5 billion of public cloud R&D spend associated with unadopted or underutilised features, funds the authors argue could have been redirected to higher value work. pendo.io ↗
- ICONIQ Growth Median R&D spend per employee stabilises at $200,000 to $250,000, infrastructure runs 7% to 15% of revenue, and keep-the-lights-on work should be held to 10% to 15% of total engineering time. cdn.prod.website-files.com ↗
- SaaS Capital Total median spend of 96% of ARR for bootstrapped companies and 101% for equity-backed, with R&D the single largest expense category regardless of size or funding type. saas-capital.com ↗
- SaaS Capital Median growth rate of 25% for 2024. Combined with the R&D spend line this produces the portfolio-level payback window used above. saas-capital.com ↗
- Benchmarkit Expansion CAC ratio of $1.00 at the median against a new customer CAC ratio of $2.00, with the fourth quartile spending $2.82 to acquire $1.00 of new customer ARR. The alternative use of money that any build has to beat. benchmarkit.ai ↗
- SaaS Mag The median SaaS company spends about $2.00 to generate $1 of new ARR, up 14% since 2023, and recommends fixing efficiency first where the burn multiple exceeds 2.5x. saasmag.com ↗
- MetricHQ Defines the efficiency score as net new ARR divided by net burn, giving the incremental ARR added per dollar of burn. The portfolio-level analogue of this chart. metrichq.org ↗
- High Alpha Companies above $50M ARR generate roughly 60% of new ARR from existing customers, citing product stickiness and multi-product adoption, so most of the return on this chart arrives through expansion rather than new logos. highalpha.com ↗
- Mountain Goat Software Traces the widely repeated 64% figure to a 2002 conference keynote rather than a published study. Included as the caution against the most commonly quoted number on this topic. mountaingoatsoftware.com ↗