Feature adoption rate: how to measure it, and how to raise it

You shipped the feature, announced it, wrote the help article. A month later almost nobody has used it, and someone in a sales call asks whether you could build exactly that. Feature adoption rate is how you see this happening in numbers, and the number is only useful if you measure it the same way every time.

The formula

Feature adoption rate = users who used the feature in the period ÷ users who could have used it in that period × 100.

For example, if 1,200 users were active in the last 30 days and 300 of them created a recurring invoice, the adoption rate of recurring invoices is 25% for that month.

Three decisions change the result more than anything else, so make them once and write them down:

• Who counts as eligible. All active users, or only those on a plan that includes the feature, or only those whose role can use it. A feature for admins measured against every user will always look unused.
• The period. Seven days for something people do daily, 30 or 90 for something they do monthly. Compare equal periods only.
• What counts as a use. A completed action: the invoice was created, the report was exported. Opening the screen is curiosity, not adoption.

What the benchmarks really say

Most "average feature adoption rate" figures online come from vendor blogs and trace back to no dataset. The best-sourced numbers are older but real: in its 2019 Feature Adoption Report, Pendo analysed three months of anonymised usage across 615 subscriptions and found that 80% of features in the average software product are rarely or never used, and that an average of 12% of features generate 80% of daily usage.

The useful reading of that is not a target. It is that a low number is normal, and that the question worth asking is which of your features belong in the 12% and are stuck outside it. The benchmark that matters most is your own history: the same kind of feature, launched before, measured over the same period.

Why adoption stays low

When a feature people would value goes unused, it is rarely the feature. It is the path to it:

• The name. Users look for "unpaid"; the filter is called "status: outstanding".
• The depth. Every level of settings between the user and the feature loses more of them.
• The combination. What users want is often two features together, a filter then a bulk action, and nobody looks for two things at once.
• The timing. The announcement arrives weeks before the need, and by the time the need comes, it is forgotten.

The clearest sign of a path problem is users asking for a feature you already have. That post goes through it in detail.

How to raise it

Meet the need, not the calendar. Show a feature where and when it is needed: the recurring option on the third time someone creates the same invoice, not in a release email.

Use your users' words. Collect the exact phrases people use in feature requests, sales calls and feedback, and rename and reorganise around them.

Let users ask for the outcome. An AI agent inside the product lets a user type "send this invoice to Acme every month" and does it with the features you already have, as that user, after showing them what it is about to change. Adoption of the feature rises because the user never had to find it.

Measure what people ask for. Once users can ask, the requests become the best adoption data you have: what they wanted, in their words, and which of those your product could not do. With Verb, the requests no action could handle are grouped on the dashboard for exactly this.

If the feature is one users should learn and repeat every day, guidance still has its place; digital adoption platforms and AI agents covers when each fits.