Feature Adoption: How to Measure It and How to Move It
You shipped it; is anyone using it? How to define adoption for a specific feature, the three numbers that describe it, how to diagnose a low number, and the nudges that raise it — including showing the feature in context.
Feature adoption is the share of the users who should use a feature who actually do — measured against the relevant population, not your whole user base. Describe it with three numbers: breadth (what percentage have tried it), depth (how much the adopters use it), and retention (whether they keep using it). Trend all three by signup cohort. When a number is low, the cause is almost always discoverability, positioning, friction, or fit — and you find out which by asking users who should be using the feature and aren't. The nudges that move adoption are making the feature visible at the right moment, explaining it in context, and showing it in action rather than describing it.
Define the population first
Adoption of an advanced export format among all users is a meaningless number if only 10% of users export anything. Measure against the people for whom the feature is relevant:
- Users on a plan that includes it.
- Users doing the workflow it improves.
- Users at the stage of their lifecycle where it becomes useful.
Get the denominator right and the number starts meaning something.
The three numbers
- Breadth — of the target population, what percentage have used the feature at least once? This is the "did they find it" metric.
- Depth — among users who've adopted it, how often or how much do they use it? This is the "was it useful" metric.
- Retention — of users who tried it, what percentage are still using it N weeks later? This is the "did it stick" metric.
A feature can be high-breadth and low-retention (everyone tried it once, no one came back — usually a fit or quality problem) or low-breadth and high-retention (hard to find, but the people who find it love it — a discoverability problem). The pattern tells you where to look.
Diagnosing a low number
Talk to five users who fit the target population and haven't adopted the feature. The reason is almost always one of:
- Discoverability — "I didn't know that existed." The feature is buried, or lives behind a menu no one opens.
- Positioning — "I saw it but didn't get what it was for." The label or the empty state doesn't communicate the benefit.
- Friction — "I started and it wanted me to configure three things first." The setup cost is higher than the perceived payoff.
- Fit — "I don't have that problem." Sometimes the honest answer. Not every feature is for everyone, and that's fine — just make sure you're measuring against the right population.
The nudges that move it
Make it visible at the moment it's relevant
A contextual prompt when the user is doing the related task beats a one-time announcement they've forgotten. "You're doing X manually — there's a faster way" at the point of pain.
Explain it in context, not in a doc
An empty state or tooltip that shows what the feature produces, with a real example, does more than a paragraph in the help center.
Show it, don't tell it
The fastest way to communicate a feature's value is to let someone watch it work. A short interactive walkthrough of the feature in action — the real interface, the actual steps, the outcome — can go in the announcement, the empty state, and the docs:
Remove the first-use friction
If adoption stalls at "started but didn't finish," the setup is too heavy. Add a template, a default, or a sample so the first use produces something without configuration.
Track it after every launch
Feature adoption isn't a one-time check. Add breadth / depth / retention to the post-launch review for every meaningful feature, trend it by cohort, and treat a flat or falling line as a prompt to go ask users why.
Related: how to write release notes people actually read, how to collect product feedback, user activation.
Frequently asked questions
What is feature adoption?
Feature adoption is the degree to which the users who could benefit from a feature actually use it. It is measured against the relevant population — not your whole user base — and usually described with three numbers: breadth (what share have tried it), depth (how much they use it), and retention (whether they keep using it after the first time).
How do you measure feature adoption?
Pick the population who should use the feature, then track: the percentage who have used it at least once (breadth), the frequency or volume among users who have adopted it (depth), and the percentage still using it weeks later (retention). Trend these by signup cohort so you can see whether changes are helping.
What is a good feature adoption rate?
It depends entirely on the feature and how broadly it applies. A core workflow feature should approach universal adoption among active users; a power-user feature might do well at 15%. The useful comparison is against your own expectation for that feature and the trend over time, not an industry benchmark.
Why is my feature adoption low?
Usually one of: users do not know it exists (discoverability), they do not understand what it is for (positioning), it is too much work to start using (friction), or it does not actually solve a problem they have (fit). Diagnose by talking to users who should be using it and are not — the reason is usually obvious once you ask.