Feature adoption: measure it properly, then cut what nobody uses

By Meet Patel · 2026-10-03 · 6 min read

In February 2019, Pendo published its Feature Adoption Report, built from product usage data across 615 Pendo subscriptions belonging to customers who had used the tool for more than a year. Its headline finding was that “80 percent of features in the average software product are rarely or never used.” A second figure in the same report is more useful to a product team: only 12 percent of features generated 80 percent of average daily usage volume.

Pendo also estimated that publicly traded cloud software companies had collectively invested up to $29.5 billion in R&D on these features, per its announcement of 5 February 2019. Treat all of this with the caution it deserves. The source is a vendor that sells adoption analytics, the sample is its own customers, and the data is from 2019. The order of magnitude is still a reasonable prior for any mature product, and it raises a practical question: how do you find out which of your features sit in the unused majority, and what do you do about them?

Reading the 12 percent

The 12 percent figure describes concentration, and concentration is normal. Usage in most products is skewed because a few core workflows dominate daily work. What matters is where your own features sit on the curve. Rank your features by qualifying events, then count how many account for 80 percent of the total. Then ask, of the features in the long tail, whether each one serves a rare job you chose to support.

Why an unused feature is not free

A shipped feature keeps costing money after the launch. It needs tests that run on every release, documentation that must be kept true, support staff who must understand it, and a place in the interface that other features cannot occupy. It also interacts with later work: every new feature has to be checked against the old ones. None of these costs shows up on a roadmap, so the feature looks free until a team notices that a simple change takes three weeks. The PM's veto makes the same point from the other side: an unbuilt feature has no maintenance, no tech debt and no documentation.

The reverse is also true, and it is the reason to be careful. A feature used once a year can be worth more than one used daily. A year-end export or a compliance report may be what keeps a customer renewing. Low usage alone is therefore a prompt for investigation, and the verdict waits on what the investigation finds.

Measure adoption with a defined denominator

Most adoption numbers go wrong in the denominator, so define four things before measuring.

1. Eligible users. People who could use the feature: right plan, right role, right data connected. Someone on a plan without the feature cannot adopt it.
2. Qualifying event. The action that shows the feature did its job, such as a report exported or a filter saved. A page view does not qualify.
3. Window. The period that matches how often the job occurs. A daily workflow is measured over 7 days, a monthly close over 30 to 35 days, a year-end task over 12 months.
4. Depth. The share of adopters who used it more than once. A feature that people try and abandon has a different problem from one they never find.

Adoption is then the number of eligible users with a qualifying event in the window, divided by the number of eligible users. Depth is the share of those users with two or more events.

Two worked examples (hypothetical)

Take a 20-person SaaS company with 1,000 active accounts. Scheduled reports are available on the paid plan, which covers 400 accounts. In the last 30 days, 48 of those accounts scheduled or edited a report, and 36 of them did so more than once. Adoption is 48 divided by 400, which is 12 percent. Depth is 36 divided by 48, which is 75 percent. Measured against all 1,000 accounts, the same feature would show 4.8 percent, and the team might remove something that 12 percent of its eligible customers use and keep using.

Now a second feature, a CSV import that shows 3 percent adoption over 300 eligible accounts, because only 9 accounts used it. It is an onboarding job, performed once. Measured on the 11 accounts created in the last 30 days, 9 used it, which is 82 percent. The first number suggested removal, and the right window says keep.

I would run this check on every feature that looks unused. The denominator and the window decide the verdict, and writing both down before looking at the number prevents choosing the combination that gives the answer you wanted.

Four outcomes for a low-adoption feature

Once adoption and depth are measured, each feature with low adoption falls into one of four groups.

• Promote. Depth is high and adoption is low. People who find it keep using it, so the problem is discovery. Move it, name it better or prompt it at the moment of the job.
• Fix. Depth is low. People try it and leave, which usually points at a usability or reliability problem. Watch a handful of sessions before deciding anything else.
• Keep. Adoption is low in the window but the job is rare by nature, or a small group depends on it for renewal. Mark it as intentionally low frequency and exclude it from future reviews until the context changes.
• Remove. Adoption and depth are both low, the adopters are not a segment you want to keep, and the carrying cost is real.

One caution on the value check. It is tempting to compare retention for users of a feature against users who never touched it. Heavy users adopt more of everything, so the comparison flatters every feature. Compare within a similar group, for example accounts of the same size and age, and treat the result as a hint. I argued in retention is a product problem that retention gets fixed in the product itself, and a feature review is one place where that work happens.

How to remove a feature without a revolt

Removal is a reversible decision if you build it that way. Put the feature behind a flag, turn it off for a small group, and watch support contacts and the exact accounts that used it. Before turning it off for everyone, contact the named accounts that used it in the last 90 days, offer the alternative and give a date. Keep the data export available for a period after removal.

Set the review in advance. Write down the adoption and support figures that would make you restore the feature, and the date you will look. If nothing crosses the line, the removal stands. This turns a political conversation about someone's pet feature into a check against numbers agreed earlier.

A quarterly review that stays small

The routine I would use takes two hours a quarter. List every feature with its eligible users, qualifying event and window. Sort by adoption. For the bottom quarter of the list, assign one of the four outcomes and an owner. Record the decisions where the team can find them. I described a related pattern in a company with 41 dashboards and nineteen unopened ones, and the same logic applies: an artifact nobody opens keeps costing attention, and the sooner you ask whether it earns its place, the cheaper the answer.

The review also supports a habit of saying no earlier. A team that sees the cost of an unused feature writes tougher non-goals for the next one, which fits the case in constraint is strategy that winning strategies are defined by what a company decides never to do.

Every feature is a standing commitment to maintain, explain and support something. The adoption review is where that commitment is checked against what customers actually do with it, and the ones that do not earn their keep can be retired deliberately.

Written by Meet Patel — startup operator and growth strategist in Dubai.

Read on themeetpatel.com