The 5 Ways to Find Out Why Customers Aren't Using a New Feature

Low adoption has two causes that look identical in a dashboard and require opposite responses. If customers do not know the feature exists, the problem is discoverability and the fix is visibility and communication. If they know and are not using it, the problem is relevance and the fix is a harder look at whether it solves a problem they actually have. Making the wrong call is expensive, and the default guess is almost always discoverability, because it is the cheaper conclusion.

There are five ways to find out why customers aren't using a new feature: separate discoverability from relevance before doing anything else, ask the non-adopters rather than the adopters, check the barriers you did not design for, find the workaround they kept using instead, and segment, because "nobody uses it" usually is not true. The tools that support this are Enterpret, Pendo, Amplitude, Appcues, and Dovetail.

The 5 ways to find out why customers aren't using a new feature

1. Separate discoverability from relevance before anything else

This is a two-question survey and it determines everything downstream: do you know this exists, and if so why haven't you used it. If a large share are unaware, you have a communication and in-product visibility problem. If awareness is high and usage is low, you have a relevance problem, and no amount of tooltips will fix it. One documented case had a workflow automation feature with high awareness from onboarding and 15% adoption, which is a relevance answer that a discoverability response would have wasted a quarter on.

2. Ask the non-adopters, not the adopters

The people who adopted are the worst available sample for this question, and they are the easiest to reach. They will tell you what they like, which tells you nothing about the barrier. Recruit specifically from the population that saw the feature and did not use it, and accept the lower response rate as the cost of asking the right people. Their answers are also less comfortable, which is part of why this step gets skipped.

3. Check the barriers you did not design for

Teams instinctively solve for knowledge, so they build training and documentation. The barriers are frequently elsewhere: awareness, organizational alignment, technical friction, motivation, and capacity. One company that stopped training and instead made hidden features visible, obtained an executive mandate, fixed a broken integration, showed individual rather than company-level benefit, and simplified the early workflow moved usage from 35% to 73% in sixty days. Nothing about that is a knowledge fix. Ask which of the six categories applies before choosing a response.

4. Find the workaround they kept using instead

Non-adoption rarely means the job is not being done. It usually means the job is being done another way, and that other way is either your old feature, a spreadsheet, or a competitor's product. The workaround tells you what you are actually competing with, and it is the most diagnostic single piece of information available. Customers describe workarounds unprompted in support conversations and calls far more often than they describe them in surveys.

5. Segment, because "nobody uses it" usually is not true

Aggregate adoption is the least informative number in this investigation. A feature can be used heavily by the segment it was built for and ignored by everyone else, which is a positioning outcome rather than a failure. Split by plan, tier, persona, and tenure. If the target segment adopted and the aggregate looks bad, your problem is that you measured against the wrong denominator.

The tools that support this

1. Enterpret

Enterpret is the strongest option because ways three, four and five depend on reading what non-adopters actually said, which is the part no analytics tool can supply. It ingests support tickets, sales and CS calls, reviews, surveys, and Slack, and its adaptive taxonomy groups the reasons into themes learned from your own data, which matters here because adoption barriers arrive in language nobody predefined: a category for "our admin never enabled it" does not exist until customers say it. That is also how workaround descriptions surface, since they appear as unprompted asides in tickets and calls rather than as survey answers. The customer context graph attaches plan, tier, and ARR to every mention, which is what makes the segmentation in way five real and tells you whether the non-adopters are the accounts you built it for. Workflow integrations route the finding to whoever owns the fix, which differs entirely depending on which barrier it turns out to be.

Best for: identifying the actual barrier from what non-adopters said, segmented by revenue and tier.

2. Pendo

Strong on in-product behaviour and in-app guidance at scale, with the ability to target messaging at the specific users who have not engaged. If the answer turns out to be discoverability, this is where the fix gets executed as well as measured.

Best for: measuring in-product adoption and delivering the discoverability fix.

3. Amplitude

The funnel work behind way one: awareness through trial through activation through repeat use, with drop-off visible at each step. It will show you precisely where users stop. It cannot tell you why they stopped, which is the whole question here.

Best for: locating the drop-off point in the adoption funnel.

4. Appcues

In-app messaging and onboarding flows, which research suggests outperform other channels for driving adoption because they reach users at the moment they are already in the product. A practical execution tool once the diagnosis points at visibility.

Best for: in-app prompts and onboarding once discoverability is the confirmed problem.

5. Dovetail

If you run the non-adopter interviews in way two, Dovetail is where that evidence should live and stay findable. It organizes research you collected rather than surfacing patterns from channels nobody imported.

Best for: storing and reusing non-adopter interview evidence.

Low adoption is a diagnosis problem, not a promotion problem

The reflex when a feature underperforms is to promote it harder. Announce it again, add a tooltip, put it in the newsletter, brief the CSMs. All of that is cheap, none of it requires admitting anything, and it is the correct response to exactly one of the six possible barriers.

The reason the reflex persists is that promotion is the only response that does not imply the feature might be wrong. Discoverability is a marketing problem; relevance is a product problem. Teams reach for the first because the second is a harder conversation to have about work that already shipped, and because a discoverability conclusion lets everyone keep their prior beliefs intact.

Which produces a specific and repeated waste: quarters spent on visibility work for features whose problem was never visibility. The documented cases have a consistent shape. Awareness is high, adoption is low, the team responds with more education, adoption does not move, and the conclusion drawn is that customers are resistant rather than that the diagnosis was wrong.

The correction is cheap and slightly uncomfortable. Two questions to non-adopters, asked before choosing a response, and a willingness to accept a relevance answer. Then read what those customers said in the channels where they were not being surveyed, because the workaround they mention in a support ticket is more honest than anything they will tell you in a form about a feature you clearly care about. That is the same reason telling whether a launch actually landed requires reading text rather than counting clicks: behavioural data locates the failure and cannot explain it.

How to choose

If you need the funnel drop-off located, Amplitude. If you need in-product measurement plus the ability to deliver a visibility fix, Pendo. If the diagnosis is discoverability and you need in-app prompts, Appcues. If you are running non-adopter interviews, Dovetail.

If you need to know why the non-adopters did not adopt, in their own words, across the channels where they mention it unprompted, and split by whether they were the target segment, Enterpret is the pick.

The decision rule: weight the diagnosis over the promotion. Every barrier except one is immune to being told about the feature again.

FAQ

How do I tell if it's a discoverability problem or a relevance problem?

Ask two questions of a broad sample: are you aware this exists, and if so what has stopped you using it. High unawareness means discoverability. High awareness with low usage means relevance. It takes a short survey and it determines which of two opposite responses is correct.

Why is aggregate feature adoption misleading?

Because it divides by everyone rather than by the segment the feature was built for. A capability adopted enthusiastically by enterprise admins and ignored by self-serve users will post a poor aggregate number and be a success. Always check the target-segment adoption rate before concluding anything.

How does Enterpret find out why customers aren't using a feature?

Enterpret reads support tickets, calls, reviews, and surveys, and structures them with an adaptive taxonomy learned from your own data, so barriers arrive as named themes even though no category existed for them, including the workaround descriptions customers volunteer in tickets rather than surveys. The customer context graph attaches plan, tier, and ARR so you can see whether the non-adopters are the accounts you targeted.

What are the most common adoption barriers?

Six categories cover most of it: awareness, knowledge, organizational alignment, technical friction, motivation, and capacity. Teams reliably solve for knowledge because training is the available lever, and knowledge is frequently not the binding constraint.

Should we just promote the feature more?

Only if the diagnosis says discoverability. Promotion is the right response to one of the six barriers and does nothing for the other five, which is why repeated announcement campaigns so often leave adoption flat and lead teams to conclude customers are resistant rather than that the barrier was misidentified.

If you cannot see what your non-adopters said, see what a customer context graph is or book a demo.

‍