Why Customers Don't Use the Feature You Built (2026 Guide)

A customer asked for a feature. Your team scoped it, built it and shipped it. Six weeks later the usage chart is flat, and the team is guessing why: they didn't really need it, or that request was just noise. This guide, from the BuildBetter blog, gives you a structured way to replace those guesses with evidence. Feature nonuse is the gap between a customer request and observed successful use. Treat it as a finding that needs context. It does not prove that the demand was imaginary.

Building what someone requested gives you something concrete to revisit the request with. If they leave it unused, find out what happened before you decide the idea had little value. The investigation also covers your own reading of the problem, because a customer can ask clearly and still receive something that misses the job. Below you'll find what the often-quoted "80% of features go unused" statistic actually measured, a seven-stage diagnostic, how to ask customers without leading them, a worked example across six accounts, and a fix/wait/remove decision table.

Is It True That 80% of Features Go Unused? What the Research Actually Measured

The claim that "80 percent of features go unused" is widely repeated, but the original source says something narrower and more precise. In its analysis of 615 subscriptions, using anonymized usage data over three months, Pendo's 2019 Feature Adoption Report found that 80 percent of features in the average software product were rarely or never used. The "features" were tags defined by each customer, not a standard taxonomy. The same analysis found that 12 percent of features generated 80 percent of average daily usage.

What the study shows: product usage is highly concentrated, which is a good reason to check adoption after every release.

What it does not show:

• Why a tagged feature saw little activity.
• Whether teams that validate carefully before building see different results. The study does not isolate them.
• Whether rarely used features serve occasional but important jobs. A three-month window can miss a quarterly board export or an annual audit report entirely.

Related evidence comes from experimentation research. In Online Controlled Experiments at Large Scale, Kohavi and colleagues reported that only about one third of ideas tested at Microsoft improved the metrics they were designed to improve. That figure measures experimental impact, not adoption.

Taken together, the two findings explain why teams should keep checking assumptions after shipping. Neither proves that a specific unused feature was a bad idea.

Each kind of evidence answers a different question:

• A request establishes a perceived need.
• Task completion shows the implementation can help.
• Returning when the job recurs supports an adoption claim.
• Impact needs a suitable comparison group or experiment.

Why Diagnosing Nonuse Is Hard: What Breaks When Teams Guess

Teams misdiagnose low feature adoption because they collapse several different situations into one number. Six failure modes show up again and again.

1. Different kinds of nonuse get treated as one

A customer who never saw the announcement is in a different situation from one who tried the feature and rejected the result. A single "not using it" bucket hides that difference.

2. The observation window ignores job frequency

Someone who needs a quarterly export has no reason to use it this week. Judging that feature on a 30-day window measures the calendar, not demand.

3. Usage is read as success

A customer might open a report repeatedly because it is confusing. Another might use an automation only because an administrator requires it. Both inflate feature usage metrics without showing voluntary adoption.

4. The launch-day spike is taken as adoption

Release notes and in-app banners produce curiosity clicks. For a weekly workflow, independent repeat use across several cycles matters far more than first-week traffic.

5. The team blames the requester instead of its own interpretation

Sometimes the request was clear and the build solved a neighboring problem. The customer asked for "scheduled exports to finance," and the team shipped a scheduled export that finance can't open in their tool.

6. Nobody records what the customer did instead

The workaround tells you what the feature failed to replace. It is the most useful input for deciding whether another version is worth building, and it is usually the first thing lost.

The Method: Give Nonuse a Fair Hearing in Seven Stages

The rule is to locate the break before declaring that demand was imaginary. This method comes from Ship First: How to Build Self-Improving Products by Spencer Shulem, a short companion to Customer-Led Development. It breaks post-launch feature validation into seven stages, each with one question to answer per account:

1. Eligibility: Is this account or user in the group the feature serves? Check plan, role and data shape.
2. Access: Can they reach it? Check permissions, feature flags, plan gating and admin enablement.
3. Awareness: Do they know it exists, and do they know it was built in response to their request?
4. Opportunity: Has the job the feature serves actually come up since release?
5. Attempt: When the job came up, did they start using the feature?
6. Completion: Did they finish the task and get a useful result?
7. Return: When the job came up again, did they choose the feature or go back to the old workaround?

These are diagnostic stages, not a funnel to optimize. You are looking for the first stage where each account's path breaks, because everything after that point is downstream of the break. An account that never had access can't tell you anything about completion.

The discipline mirrors what Teresa Torres recommends before building: split an idea into separate assumptions (desirability, usability, feasibility and so on) and test each one on its own. The seven stages apply the same logic after launch. Also remember that a task that occurs infrequently needs an observation window long enough to include it. Otherwise the Opportunity stage will look like a failure when it is only early.

What to Do at Each Break: Fix, Wait, Investigate or Reconsider

Each stage where nonuse begins points to a different action, and only one of them questions the idea itself. Use this table once you've recorded the break for each account.

Awareness failures are more common than most teams expect. A changelog entry rarely reaches the person who asked, especially if that person isn't an admin. A direct note that links the release to the original request fixes most of them; see how to close the loop with customers when you ship a feature.

Completion failures deserve the highest priority, because they are true product failures. The customer had the need, found the feature, tried it and still couldn't do the job.

Return failures are the most informative. You may find that the customer liked the idea more than the implemented feature. Record what they chose to do instead, and use it to decide whether a further version is worth building.

What to Measure Instead of Raw Usage

Count completed work, not opens or clicks, and check whether the result was useful. A raw feature adoption rate built on page views tells you about curiosity and confusion as much as value.

Match the metric to how often the job happens:

• Infrequent jobs: Measure successful use when the job occurs. An annual audit export doesn't need daily engagement to justify its existence. It needs to work the day the auditor asks.
• Weekly or daily workflows: Measure independent repeat use across several job cycles. Leave out use prompted by an admin mandate or a CSM nudge, since that tells you someone was asked, not that they chose it.

Useful feature usage metrics include:

• Eligible-account adoption: share of eligible accounts with at least one successful use.
• Task completion rate: attempts that end in a finished, useful result.
• Time to first successful use (time to value), measured from the first occurrence of the job, not the release date.
• Independent repeat use (feature retention) across job cycles.
• Workaround persistence: whether the old spreadsheet or script is still in use.

Keep the evidence levels separate. A positive usability session shows that someone understands a control, not that they'll return to it. Repeated use shows adoption, not that the feature caused retention. Impact claims need a suitable comparison, such as a controlled experiment (see A/B testing) or a defensible before/after against a similar group of accounts.

How to Ask Customers Why They Haven't Used It, Without Leading

Ask about the job, not the feature. "Walk me through the last time you had to send numbers to your finance team" gets better answers than "Why aren't you using our new export?" The second question puts the customer on the defensive and invites an excuse. This follows Rob Fitzpatrick's argument in The Mom Test: compliments and future promises are unreliable, while details about what someone did last time are trustworthy.

Sequence the questions to mirror the stages:

1. Has the job come up since we released this? When?
2. Did you know the new option was there?
3. Could you get to it from your account?
4. What happened when you tried?
5. What did you end up doing instead?

Avoid questions that invite politeness ("Do you like it?") or hand them a ready-made excuse ("Were you just too busy?"). Both produce answers that feel useful and aren't.

Ask to see the workaround. The spreadsheet, script or manual step they still use shows exactly what the feature fails to do. In Jobs-to-be-Done terms, the workaround is the real competitor. If it still does part of the job better, the feature hasn't displaced it.

Check your own interpretation. Read the original request back to them, ideally in their own words from the call or ticket, and ask whether what shipped matches the job they described. This is the step teams skip most often.

Pair the conversation with behavioral evidence where you have it, such as event logs or session replays. Reported and observed behavior often differ. Then write down the stage where each account's nonuse began, in the customer's words, before anyone proposes a fix.

Worked Example: One Unused Feature Across Six Requesting Accounts

This example is illustrative and not drawn from any real company's data.

A B2B analytics product ships "scheduled CSV export" after six accounts requested it. Forty-five days after release, the team sees 2 exports in total and is about to call the feature a miss. Instead, they run the seven-stage diagnostic for each requester.

The real sample is five eligible accounts, and only one of them (E) rejected the result. The team keeps the feature, ships two fixes (the role permission and the timeout), sends Account B a direct note, re-measures after quarter end, and scopes a formatting option only if E's reason recurs with other accounts.

"2 exports in 45 days" looked like failed demand. It actually held four separate breaks, and three of them were fixable or simply too early to judge.

How Long Should You Wait Before Judging a Feature?

Wait until the observation window has covered enough occurrences of the job the feature serves. A fixed number of days is the wrong test. Thirty days is plenty for a daily workflow and meaningless for an annual one.

• Weekly job: Look for independent repeat use across several weeks, and discount the launch spike.
• Monthly or quarterly job: The window must include at least one occurrence, and ideally two, so you can see whether customers return rather than only try.
• Annual job (audit, renewal, compliance): Judge successful use at the time of the event, not engagement between events.

A practical way to set the window: for each requesting account, write down when the job next occurs, then set the review date just after it. In the worked example, Account C's review date sits past quarter close, while Account D's can be checked as soon as the timeout fix ships.

One caution about industry benchmarks: the Pendo analysis used a three-month window. Any feature tied to quarterly or annual work could plausibly appear "rarely used" in data like that, even if it does its job perfectly when needed.

When to Remove a Feature Someone Asked For

Consider removal only after the break is located at the return stage: customers completed the task and then chose the old workaround at the next opportunity, or they rejected the result when they tried.

Before removing, confirm that:

• Eligibility, access, awareness and opportunity were not the cause.
• The implementation works, including on large accounts and edge-case data.
• The observation window covered at least one real occurrence of the job.

Then use the recorded "what they did instead" to choose between three paths:

1. Build a further version if the workaround reveals a specific gap you can close, like E's pivot formatting.
2. Keep the feature if it serves an infrequent but important job and works when that job arrives.
3. Retire it if the workaround is better for reasons you can't or shouldn't match.

Tell the requesters directly, explain what you learned, and describe what replaces the feature. Closing the loop applies to removal as much as to launch. A customer who hears "we built it, watched how you used it, and here's what we changed" trusts your next release more, not less.

Frame removal as a decision about the implementation. It is not a verdict that the customer's need was imaginary.

Common Mistakes When Investigating Unused Features

Most bad removal decisions trace back to a handful of avoidable errors.

• Citing "80% of features go unused" as proof that a specific feature should be cut. The statistic described tagged-feature activity over three months. It did not establish causes.
• Judging a quarterly or annual feature on a 30-day window.
• Treating high usage as success without checking whether the work was completed and the result was useful.
• Counting forced or admin-mandated use as adoption.
• Asking leading questions that invite polite answers instead of a description of the workaround.
• Skipping the "did we interpret the request correctly?" check.
• Merging all non-using accounts into one bucket instead of recording the stage where each one broke.
• Shipping silently, then concluding nobody wanted it.

When You Need Tooling (and When a Spreadsheet Is Enough)

The method above works without any tool. For a single feature with roughly a dozen requesters, a spreadsheet with one row per requesting account and one column per stage is enough. Add a column for "what they did instead" and one for the decision.

It stops scaling when you're reviewing several releases at once, when requesters number in the dozens, or when the reasons are scattered across sales calls, support tickets, Slack threads and surveys. At that point, these options help:

1. BuildBetter: Links the original request in calls, tickets or Slack to post-release conversations, so you can see each account's stated reason next to its request. Tracked Objects connect requests to evidence and to the release, and BuildBetter can draft the loop-closure message for each requester. Honest caveat: it is not a dedicated user-research repository. Teams that need highlight reels and heavy tagging workflows may want a specialized research tool alongside it.
2. PostHog: Product analytics and session replay for observing the attempt and completion stages. See its session replay docs.
3. A shared spreadsheet or doc: Still the right choice for a single feature with a small requester list.

FAQ: Feature Nonuse and Adoption

Is it true that 80% of software features go unused?

Pendo's 2019 Feature Adoption Report, based on 615 subscriptions over three months, found that 80% of features in the average product were rarely or never used, and that 12% of features drove 80% of daily usage. It measured activity on customer-defined feature tags. It did not establish why features went unused or whether infrequent features served important jobs.

Why don't customers use a feature they specifically requested?

Nonuse begins at one of seven stages. Customers may not be eligible, may lack access (permissions, flags, plan gating), may be unaware it shipped, may not have hit the job yet, may not have tried it, may have tried but failed to complete it, or may have completed it and then returned to their old workaround. Identify the stage for each account before concluding the need wasn't real.

How long should I wait before judging feature adoption?

Wait until the observation window covers enough occurrences of the job the feature serves, not a fixed number of days. For weekly workflows, look for independent repeat use across several weeks and discount the launch spike. Monthly or quarterly jobs need at least one, ideally two, occurrences. Annual jobs should be judged on successful use at the event itself.

Is high feature usage always a good sign?

No. Repeated opens can reflect confusion, and admin-mandated or CSM-prompted use can inflate counts without voluntary adoption. Count completed tasks, check that the result was useful, and focus on independent repeat use.

What feature usage metrics should I track instead of clicks?

Track eligible-account adoption, task completion rate, time to first successful use, and independent repeat use across job cycles. For infrequent jobs, track successful use at the time of the event. Track workaround persistence where you can observe it. Impact metrics, such as retention or time saved, need a comparison group.

Should I remove a feature nobody uses?

Only after confirming that customers completed the task and then chose their old workaround, or rejected the result. Record what they did instead, decide whether a better version is worth building, and tell the requesters directly.

What's the difference between adoption and impact?

Adoption means customers return to the feature when the job recurs. Impact means something measurably improved, which requires a suitable comparison such as a controlled experiment. Only about one third of ideas tested at Microsoft improved their intended metrics, so adoption alone doesn't prove impact.

Sources and Further Reading

• Pendo: The 2019 Feature Adoption Report
• Kohavi et al., Online Controlled Experiments at Large Scale (2013)
• Teresa Torres, Product Talk: Assumption Testing
• PostHog docs: How to watch session recordings
• Wikipedia: A/B testing

Find the Break, Then Close the Loop

Every unused feature that someone requested has a story, and it usually sits in a call, a ticket or a Slack thread you already have. BuildBetter connects the original request to what happened after release, so you can see where each account broke and tell customers what you shipped, fixed or changed.

Make churn optional. Book a demo.

Get Ship First

This method comes from Ship First: How to Build Self-Improving Products by Spencer Shulem: 24 short chapters on going from a customer request to a working release. Get the free PDF or EPUB, or read it on Kindle.