A shipped feature earned its keep only if three things are true: enough of the target audience tried it (breadth), the people who tried it used it substantively rather than once (depth), and they came back on their own in a later period (retention). Measure all three before declaring a launch a win — a single "adoption rate" number hides which of the three actually failed.
Quick Answer: Feature adoption isn't one metric — it's a triad. Breadth tells you who tried it, depth tells you how much they used it, and retention tells you if they came back unprompted. A feature that wins on breadth alone (lots of first clicks, no repeat use) is usually a discoverability success and a value failure.
Why "people clicked it" isn't adoption
A single usage event — one click, one session, one API call — tells you a feature was discovered, not that it was adopted. Adoption is a claim about durable behavior change: someone incorporated the feature into how they get their job done. Conflating the two is the most common reason launches get graded wrong.
The failure mode is specific and recurring. A team ships a feature, instruments a single "feature used" event, watches the count climb in week one, and calls it a success in the launch retro. Three months later usage has flatlined near zero and nobody notices, because the metric that mattered — did anyone still use it after week one — was never tracked.
This is a measurement design problem before it's an analysis problem. If your tracking plan only defines a single feature_used event with no session, user, or time-window structure, you've made it structurally impossible to distinguish breadth from depth from retention later. The event schema has to carry enough information — user ID, timestamp, a count or duration where relevant — to reconstruct all three views after the fact. Getting event property design right at instrumentation time is what makes this whole framework possible six weeks post-launch instead of theoretical.
Nielsen Norman Group's usability research has long distinguished between trial and sustained use as separate outcomes of an interface change — a distinction that maps directly onto breadth versus retention here. Trial tells you the feature is discoverable and the value proposition lands in the moment; sustained use tells you the value proposition survives contact with a person's actual workflow.
Breadth: what share of the target audience adopted it at all
Breadth answers "who tried this," measured as the percentage of your intended audience that used the feature at least once in a defined window. It's a reach number, not a value number — high breadth with low depth means people found it but didn't get much from it.
Calculate breadth against the right denominator, not your whole user base. If a feature is scoped to accounts with a Pro plan, or to users who've completed onboarding, the denominator is that qualifying population — not everyone who ever logged in. Using the wrong denominator is the single most common way teams inflate or deflate their own breadth number without noticing.
Breadth formula:
breadth % = (unique users who used the feature ≥1x in window) / (unique users in eligible population) × 100
Three practical decisions determine whether your breadth number means anything:
- Eligible population — who could plausibly have used it (plan tier, platform, cohort tenure)
- Time window — 7, 14, or 30 days post-launch is typical; pick one and hold it constant across features so comparisons are fair
- Qualifying action — does a hover count, or does it need to be a completed action (saved, sent, exported)?
A breadth number without a stated eligible population and window is not comparable to any other breadth number in your org, including your own from six months ago.
Depth: how much the adopters actually used it
Depth measures usage intensity among people who tried the feature — frequency per active user, session duration, or number of distinct objects touched, depending on what "meaningful use" looks like for that specific feature. It answers "for the people who came in, did they use this a little or a lot?"
Depth needs a feature-specific unit of value, not a generic session count. A bulk-export feature's depth might be rows exported per week; a collaboration feature's might be distinct collaborators invited; a search feature's might be searches per active session. Picking a unit that doesn't map to the feature's actual job produces a depth metric that looks fine and means nothing.
| Depth signal | Best for | What it misses |
|---|---|---|
| Actions per active user per week | Frequent, low-friction features (search, filters) | Doesn't capture value per action |
| Session duration on the feature | Exploratory or analysis tools | Long duration can mean confusion, not value |
| Distinct objects created/touched | Content or workflow features (docs, boards) | Ignores read-only or passive usage |
| % of eligible actions routed through the feature | Features meant to replace an old path | Requires instrumenting the old path too |
Depth without a denominator of active adopters (not all trialists) rewards features that get one power user doing a lot while everyone else abandons — check the distribution, not just the average, before trusting a depth number. A median or a histogram catches a single whale skewing a mean; an average alone hides it.
Applying Jobs to Be Done thinking here sharpens which depth unit to pick: the metric should track how often the feature gets "hired" for the job it was built to do, not how often someone touched any part of the UI near it. If you haven't mapped the underlying job the feature serves, revisit the Jobs to Be Done framework before choosing a depth unit — it's the fastest way to avoid measuring the wrong thing precisely.
Retention: did they come back without being told to
Retention is the triad's hardest test: did adopters use the feature again in a later, unprompted period, without a notification, email nudge, or re-onboarding push driving them back? This is the metric that separates genuine habit formation from a spike caused by launch-week curiosity or marketing.
Measure retention as a cohort curve, not a single number. Take everyone who adopted the feature in week 1, and track what percentage of that cohort used it again in week 2, week 4, and week 8 — each measured independently of the last, so a lapsed-then-returned user still counts as retained at that checkpoint. A feature with strong week-2 retention and a collapse by week 8 is a novelty-driven feature, not a habit.
Kissmetrics and multiple product-analytics practitioners popularized cohort retention curves specifically because a single "30-day active" number smooths over the shape of decay — two features can post an identical 30-day rate while one is still climbing and the other has already flatlined. The curve's shape, not just its endpoint, is the signal.
Two retention pitfalls worth naming explicitly:
- Nudge-inflated retention — if a push notification, in-app banner, or CS outreach drove the return visit, that's re-engagement marketing working, not the feature earning organic pull. Segment retention numbers by "returned with a nudge" versus "returned unprompted" wherever your instrumentation allows it.
- Survivorship blindness — reporting retention only among users still active on the product overall hides feature-level churn inside overall product health. A feature can look retained while quietly being abandoned by users who are still logged in daily for other reasons.
If your event naming doesn't distinguish a nudged return from an organic one, that's a taxonomy gap worth closing — see the guidance in event naming and taxonomy convention for how to encode trigger source in the event itself rather than trying to reconstruct it later from timestamps.
The adoption matrix: reading breadth, depth, and retention together
No single metric in the triad tells you what to do next — the combination does. Plot each feature against all three (high or low, roughly split at your own thresholds) and a small number of distinct situations emerge, each demanding a different response.
| Breadth | Depth | Retention | What it means | Likely action |
|---|---|---|---|---|
| High | High | High | Genuine hit — broad reach and habitual use | Invest further, consider expanding scope |
| High | Low | Low | Curiosity click, no real value delivered | Redesign the core value prop, not the onboarding |
| Low | High | High | Niche but sticky — a real job for a small segment | Keep, target discovery to the right segment |
| Low | Low | Low | Failed on every dimension | Sunset candidate |
| High | High | Low | Strong first use, doesn't survive repetition | Investigate a workflow-fit or fatigue problem |
| Low | High | Low | Found by the right few, but doesn't stick even for them | Talk to that segment before deciding |
The bottom-left combination — low breadth, low depth, low retention — is the clearest sunset signal in the matrix: it failed to attract, failed to engage the few who tried it, and failed to bring anyone back. Anything less unanimous deserves a conversation with actual users before a kill decision, because each other row implies a different root cause and a different fix.
The sunset conversation: what to do with a feature that fails all three
A feature failing breadth, depth, and retention simultaneously should trigger a structured sunset review, not a quiet abandonment — the review protects both the roadmap (stop maintaining dead weight) and the team (a documented decision, not a silent embarrassment). Treat it as a decision with a paper trail, the same rigor you'd apply to a launch decision.
- Confirm the data, not the narrative. Re-check the eligible population and time window before concluding failure — a genuinely low breadth number caused by a bad rollout gate looks identical to a low breadth number caused by nobody wanting the feature.
- Talk to a handful of non-adopters and the rare adopters. Five conversations with people who saw the feature and didn't use it, plus two or three who used it once and stopped, usually surfaces the actual reason faster than another dashboard cut.
- Decide: sunset, redesign, or re-target. Sunset if the underlying job doesn't exist for your users; redesign if the job exists but the execution failed; re-target if the job exists only for a narrow segment breadth never reached.
- Communicate the removal like a launch, in reverse. Announce deprecation timelines, migrate any residual users, and document the decision and its evidence so the next team doesn't re-debate a settled question.
- Retire the instrumentation too. A dead feature's events left running in your analytics instrumentation quietly pollute dashboards and denominators for everything else.
Reforge's and Gibson Biddle's public writing on product metrics both make the same point from different angles: the cost of not sunsetting is rarely visible on a dashboard — it's the maintenance burden, the support surface area, and the cognitive tax on every new hire trying to understand a product with dead limbs still attached. Sunsetting deliberately is a feature-quality practice, not an admission of failure.
Adoption also has to be read against the moment in the customer's experience where the feature sits — a feature with modest usage numbers can still be load-bearing if it resolves a high-friction point on the customer journey that a raw usage count won't reflect on its own.
Committing to a number before you launch, not after
The adoption triad is far more useful when the threshold for "success" is set before the feature ships, not reverse-engineered from whatever number the launch happened to produce. A post-hoc win story — "40% breadth is actually pretty good for a feature like this" — is a rationalization dressed as an analysis, and it's the reason most orgs never actually sunset anything.
Prodinja's Prioritization studio addresses this directly: when a feature is scored and bet on, it's designed to let a team set an adoption threshold at bet time — the breadth, depth, or retention number that would make the bet look right in hindsight — so the post-launch review measures the actual outcome against that committed number instead of against a narrative assembled after the fact. It's a small workflow change with an outsized effect on whether adoption reviews stay honest.
Key Takeaways
- Adoption is three metrics, not one — breadth (who tried it), depth (how much), and retention (did they come back unprompted) each fail independently and each need separate instrumentation.
- Breadth needs the right denominator — the eligible population and a fixed time window, or the number isn't comparable to anything, including your own past launches.
- Depth needs a feature-specific unit of value — a generic session count usually measures the wrong thing precisely rather than the right thing roughly.
- Retention should be read as a cohort curve, not a single percentage, and split apart from nudge-driven re-engagement wherever possible.
- The adoption matrix turns three numbers into a decision — most combinations point to a specific fix (redesign, re-target, keep) rather than a binary keep-or-kill call.
- Only the unanimous low-low-low combination is a clean sunset signal — anything else warrants user conversations before a kill decision.
- Setting the adoption threshold before launch, not after, is what keeps a review honest instead of becoming a post-hoc win story.
Frequently Asked Questions
What is a good feature adoption rate?
There's no universal good number — it depends entirely on the eligible population and the feature's role. A core workflow feature might reasonably target 60-80% breadth among eligible users, while a niche power-user feature succeeding at 15% breadth with high depth and retention can still be a clear keep.
How long should you wait before judging a feature's adoption?
Most teams read initial breadth at 2-4 weeks, but retention needs at least two full cohort cycles — commonly 8 weeks — before a decision is trustworthy. Judging retention off a single week-2 checkpoint is the most common way teams mistake curiosity for habit.
What's the difference between feature adoption and feature engagement?
Engagement usually refers to any interaction, including a single click, while adoption implies a threshold of meaningful, repeated use. A feature can have high engagement (lots of clicks) and low adoption (nobody uses it a second time) at the same time — that gap is exactly what the breadth/depth/retention split is built to reveal.
Should you sunset a feature with low usage but passionate users?
Not automatically — low breadth paired with high depth and high retention often signals a real, narrow job rather than a failed feature. Investigate whether breadth is low because the target segment is genuinely small or because discovery failed, before assuming the feature has no future.
How do you measure adoption for a feature with no clear "usage" event, like a settings change?
Define adoption around the downstream behavior the setting is meant to change, not the toggle click itself — for a default change, that might mean measuring the behavior it enables rather than how many people flipped it. This is a case where getting event property design right at the outset pays off, since the toggle event alone rarely carries enough context to answer the real question.