How to Measure Feature Adoption (And When to Kill a Feature)

Most Features Fail Quietly

The uncomfortable truth about product development is that most features do not fail loudly. They fail quietly. They ship, a few people try them, and then usage decays to near zero while the team has already moved on to the next build cycle. Nobody declares the feature dead. It just sits there, accumulating tech debt and diluting the product surface.

I have seen this pattern everywhere I have worked. At a financial social media startup I worked at before its acquisition, we shipped a social sharing feature that hit 40% trial rate in its first two weeks. The team celebrated. Two months later, repeat usage had settled at 8%. The feature was not adopted. It was sampled. That distinction matters because it changes what you do next.

Across 20+ consulting engagements with SMBs and startups through Gradient Growth, I consistently find the same gap: teams track whether features get used but not whether features get adopted. Usage is a count. Adoption is a lifecycle. Measuring the lifecycle is what tells you whether to invest, iterate, or kill.

The Adoption Lifecycle

Feature adoption moves through four distinct stages. Each stage has its own metric, and each transition is where most features die.

Discovery. The user becomes aware the feature exists. This sounds trivial, but it is the most common failure point I see in consulting. At one client (a B2B SaaS company with 12 major features), analytics showed that 35% of active users had never encountered 4 of those features. Not rejected them. Never seen them. Discovery failure is a distribution problem, not a product problem.

Trial. The user engages with the feature for the first time. Trial rate is the percentage of eligible users who use the feature at least once within a defined window. This is the metric most teams stop at, and stopping here is exactly why adoption measurement breaks down.

Repeat. The user comes back to the feature a second or third time without prompting. Repeat usage is the first real adoption signal. The gap between trial and repeat is where the sharing feature died: 40% tried it, 8% came back. That 32-point drop told us the feature delivered less value than users expected on first contact.

Habitual. The feature becomes part of the user's regular workflow. This is true adoption. The user would notice and care if you removed it. At the same consulting client with 12 features, only 3 had reached habitual status, and those 3 drove 80% of total engagement. The other 9 were somewhere between trial and repeat, consuming maintenance resources while contributing almost nothing to retention.

The Four Formulas

Each lifecycle stage maps to a specific metric. These are the formulas I use in every engagement.

Adoption Rate measures the share of eligible users who reach repeat usage.

``` Adoption Rate = (Users with 2+ feature uses in period) / (Users who discovered the feature) * 100 ```

Note the denominator. This is not total users. It is users who discovered the feature. Measuring against the full user base conflates discovery failure with adoption failure, and the interventions for each are completely different.

Time to Adoption measures how quickly users move from discovery to repeat use.

``` Time to Adoption = Median days from first feature use to second feature use ```

If the median is longer than your product's natural usage cycle, the feature is not integrating into the user's workflow. For a daily-use product, time to adoption should be under 7 days. For a weekly-use B2B tool, under 21 days.

Depth of Adoption captures how intensively adopted users engage with the feature.

``` Depth of Adoption = (Feature actions per user per period) / (Expected actions for full utilization) ```

"Expected actions" requires judgment. For a reporting feature, full utilization might mean generating 4 reports per month. If adopted users average 1.2, your depth is 30%. Low depth among adopted users suggests the feature is partially useful but has friction or gaps that prevent full integration.

Feature Retention is a micro version of [product retention curves](/insights/retention-curve-analysis-guide). It measures whether adopted users continue using the feature over time.

``` Feature Retention (Week N) = (Users active on feature in Week N) / (Users who adopted in Week 0) * 100 ```

Feature retention curves behave identically to product retention curves. They drop sharply, then either flatten (the feature has durable value) or decay to zero (the feature was a novelty). The same diagnostic framework applies: look for the flattening point, track period-over-period retention, and segment by user cohort.

Tracking Adoption From Event Data

Here is a practical Python implementation for computing these metrics from raw event logs. This assumes a standard event table with user IDs, event names, and timestamps.

```python import pandas as pd from datetime import timedelta

def compute_feature_adoption( events: pd.DataFrame, feature_event: str, discovery_window_days: int = 30, user_col: str = "user_id", event_col: str = "event_name", date_col: str = "event_date", ) -> dict: """ Compute adoption lifecycle metrics for a single feature.

Parameters ---------- events : DataFrame with columns [user_id, event_name, event_date] feature_event : the event name that signals feature usage discovery_window_days : period over which to measure adoption

Returns ------- dict with adoption_rate, median_time_to_adoption, trial_users, repeat_users, and per-user usage counts """ events = events.copy() events[date_col] = pd.to_datetime(events[date_col])

# isolate feature events feat = events[events[event_col] == feature_event].copy() if feat.empty: return {"adoption_rate": 0, "trial_users": 0, "repeat_users": 0}

# first and second use per user user_uses = ( feat.sort_values(date_col) .groupby(user_col)[date_col] .apply(list) .reset_index() .rename(columns={date_col: "use_dates"}) ) user_uses["first_use"] = user_uses["use_dates"].apply(lambda x: x[0]) user_uses["use_count"] = user_uses["use_dates"].apply(len) user_uses["second_use"] = user_uses["use_dates"].apply( lambda x: x[1] if len(x) > 1 else pd.NaT )

# filter to discovery window window_start = feat[date_col].min() window_end = window_start + timedelta(days=discovery_window_days) discovered = user_uses[user_uses["first_use"] <= window_end]

trial_users = len(discovered) repeat_users = len(discovered[discovered["use_count"] >= 2])

# adoption rate: repeat / discovered adoption_rate = (repeat_users / trial_users * 100) if trial_users > 0 else 0

# time to adoption: median days between first and second use repeat_mask = discovered["second_use"].notna() if repeat_mask.any(): days_to_repeat = ( discovered.loc[repeat_mask, "second_use"] - discovered.loc[repeat_mask, "first_use"] ).dt.days median_time = float(days_to_repeat.median()) else: median_time = None

# depth: median uses per adopter in window adopters = discovered[discovered["use_count"] >= 2] median_depth = float(adopters["use_count"].median()) if len(adopters) > 0 else 0

return { "adoption_rate": round(adoption_rate, 1), "trial_users": trial_users, "repeat_users": repeat_users, "median_time_to_adoption_days": median_time, "median_depth_per_adopter": median_depth, }

def feature_retention_curve( events: pd.DataFrame, feature_event: str, weeks: int = 12, user_col: str = "user_id", event_col: str = "event_name", date_col: str = "event_date", ) -> pd.Series: """ Compute weekly retention curve for a specific feature. Week 0 cohort = users who first used the feature in that week. """ events = events.copy() events[date_col] = pd.to_datetime(events[date_col]) feat = events[events[event_col] == feature_event]

first_use = feat.groupby(user_col)[date_col].min().rename("first_use") feat = feat.merge(first_use, on=user_col) feat["week_offset"] = ( (feat[date_col] - feat["first_use"]).dt.days // 7 )

cohort_size = first_use.count() weekly_active = ( feat[feat["week_offset"] <= weeks] .groupby("week_offset")[user_col] .nunique() ) retention = (weekly_active / cohort_size * 100).round(1) retention.name = "retention_pct" return retention ```

This gives you everything you need to evaluate a feature: adoption rate, time to adoption, depth, and a retention curve. Run it weekly, compare features side by side, and the kill candidates surface themselves.

The Kill Decision Framework

Killing a feature is one of the hardest decisions in product management because the cost of building it is already sunk, and someone on the team is emotionally attached to it. A framework removes the emotion.

I use a three-signal test. A feature should be killed (or deprioritized to zero maintenance) when all three signals are present:

Signal 1: Low adoption rate after adequate discovery. If more than 70% of users have discovered the feature and the adoption rate (repeat usage) is below 15%, the feature is not providing enough value to sustain engagement. The discovery qualifier matters. A feature with 5% adoption but 10% discovery has a distribution problem, not an adoption problem.

Signal 2: Declining feature retention. If the feature retention curve never flattens and instead decays continuously through week 8 and beyond, no stable user base is forming around it. Even a small but stable retained group (say, 5% who use it every week) suggests the feature has niche value. Continuous decay to zero suggests it has none.

Signal 3: No impact on product-level retention. The final test is whether the feature contributes to overall product stickiness. Compare product retention between users who adopted the feature and users who did not (controlling for overall engagement level). If there is no measurable difference, the feature is not pulling its weight. At the consulting client I mentioned earlier, we ran this analysis across all 12 features. The 3 habitual features showed a 12-point lift in D30 product retention for their adopters versus matched non-adopters. The other 9 showed no statistically significant difference. That analysis became the basis for sunsetting 4 features and reallocating the engineering team.

One important caveat: run this analysis on cohorts who had adequate time and opportunity to adopt. Killing a feature two weeks after launch because adoption is low is premature. The minimum evaluation window should be at least two full product usage cycles (for most products, 4 to 8 weeks).

Why AI Features Are Different

Working on a GenAI squad at a major finance technology company, feature adoption measurement for AI features requires adjustments to the standard framework. The core issue is that AI feature output quality varies across users, queries, and contexts in ways that traditional features do not.

A traditional feature either works or it does not. A charting tool renders the chart. A notification setting triggers the notification. The user's experience is deterministic. An AI feature might produce a brilliant summary for one query and a mediocre one for the next. This means that trial-to-repeat conversion depends heavily on the quality of the user's first few interactions, which is partially random.

Three adjustments I have found necessary:

Extend the trial window. For traditional features, a single use is a fair trial. For AI features, a user needs at least 3 to 5 interactions to form a reliable assessment of the feature's value. I track "meaningful trial" (3+ uses within 14 days) separately from "any trial" (1+ use). The gap between these two numbers reveals how many users bounced after a bad first interaction.

Measure output quality alongside adoption. [Activation metrics for AI products](/insights/ai-startup-activation-metric) are inherently harder to define because value delivery is probabilistic. For adoption measurement, this means tracking whether users who received higher-quality outputs (as measured by engagement signals like copy, share, or follow-up queries) adopt at higher rates. If they do, the adoption problem is partially an output quality problem, and the fix is model improvement, not UX improvement.

Expect lower baselines. AI feature adoption rates run 30% to 50% lower than equivalent traditional features in my experience. This is not because AI features are worse. It is because users have not yet developed reliable mental models for when and how to use them. Benchmarking AI feature adoption against traditional feature benchmarks will make every AI feature look like a kill candidate, which is the wrong conclusion.

Putting It Together

The minimum viable feature adoption system requires four things: an event taxonomy that distinguishes discovery from usage, a weekly computation of the four lifecycle metrics, a retention curve per feature updated on a rolling basis, and a quarterly kill review using the three-signal framework.

Most teams I work with can set this up in under a week using their existing event data and the code patterns above. The hard part is not the instrumentation. It is the discipline of actually running the kill review and making the call.

The features you remove are almost as important as the features you ship. A smaller, tighter product surface where every feature is adopted and retained beats a sprawling surface where most features are ghosts.

I help product teams build feature measurement systems that tell you what to ship next, not just what shipped last. [lester@gradientgrowth.com](mailto:lester@gradientgrowth.com)