Table of Contents
Key Insights
- Low adoption has 4 usual causes: nobody knows it exists, they know about it and cannot find it, they find it and it's confusing, or they understood it and didn't want it. The fixes are completely different.
- Most teams jump to the fourth explanation, the most expensive and the least common.
- Discovery problems are the largest category and the cheapest to fix, and they're invisible in feedback because people don't complain about things they don't know about.
- Unwrap surfaces the confusion and the wrong-mental-model complaints; your product analytics tells you where people stop.
- The fastest diagnostic is asking 10 users to do the task while you watch. It settles in an hour what a month of dashboards won't.
How Do You Find Out Why Customers Aren't Using a New Feature?
Work down the funnel: check awareness, then discoverability, then whether people who start it finish, then what the ones who tried said, and finally ask whether the need was real. Unwrap covers what users said about it; product analytics covers where they stopped. Each stage rules out a cause before you spend on the next.
Five methods, in the order that avoids expensive mistakes.
How These Methods Were Assessed
Each is judged on which cause it can rule out, how fast it produces an answer, and what it costs. The order matters more than usual here, because diagnosing the wrong cause leads directly to rebuilding a feature that was fine.
Which Method Rules Out Which Cause
The 5 Best Ways to Diagnose Low Feature Adoption
1. Check awareness before anything else
The cheapest question and the one skipped most often. Before investigating the feature, find out what share of your target users know it exists.
An in-app poll or a 1-question survey settles this in days. If awareness is under half your target audience, stop: that's a communication problem and no redesign fixes it. Launch emails reach a fraction of users, in-app banners get dismissed reflexively, and release notes are read by almost nobody outside your company.
This matters because low awareness is the most common cause and the least interesting one, so teams skip past it toward explanations that feel more substantial. Rule it out first and you save weeks.
What it rules out: the largest category. What it costs: almost nothing.
2. Look at whether people ever reach the entry point
If awareness is fine, the next question is discoverability, and it's a behavior question rather than a feedback one.
Instrument the entry point and see how many users in the target segment ever land on it. A feature buried 3 clicks deep, or in a menu people visit monthly, shows low adoption whatever its quality. Compare the view rate against segment size and against a feature you know is well-adopted.
Unwrap doesn't do this half. It reads language and doesn't track events, sessions or funnels, so entry-point data comes from your product analytics platform. Attempting to diagnose discoverability from feedback alone is the classic error here, because users who never found something have nothing to say about it.
What it rules out: placement. What it needs: instrumentation that was in place at launch.
3. Check whether people who start it finish it
Now you're looking at users who found it and tried. If a meaningful share drop out, the problem is inside the experience and the drop-out step says where.
Look at completion rate and where the falloff sits. A single step accounting for most of the abandonment is a specific, fixable problem, usually a required input people don't have to hand, an unclear label, or a decision the interface asks them to make too early.
This is the stage where behavior and language work together. The funnel says where they stopped; the feedback says what they were thinking when they stopped. Neither alone is enough, and teams that have only one of them tend to guess confidently.
What it rules out: whether the experience itself is the blocker. What it needs: the same instrumentation as the entry-point check.
4. Read what the people who tried it said
The step that produces the mechanism, and the fastest one available if you have a feedback platform.
Pull everything mentioning the feature and read 20 items. Two patterns matter. A wrong mental model, where users describe the feature as something it isn't, means your naming taught them the wrong thing and the fix is words rather than code. Workflow mismatch, where users understood it and it doesn't fit how they work, is the expensive finding and the one worth knowing early.
Unwrap makes this a single query. Feedback from every channel goes through one model into themes in the customer's own wording, with no hand-built taxonomy, at 90%+ tagging precision, third-party verified, and every insight traces back to the original verbatim feedback. Themes carry account context, segments, plan tiers and revenue impact, so you can see whether the users struggling are the ones the feature was built for. Support is US-based, and the proof of concept (POC) runs on your own feedback with the taxonomy editable.
What it rules out: confusion versus rejection. What it costs: half an hour of reading.
5. Watch 10 people try it
The method that settles arguments, and the one teams treat as too slow while spending a month on dashboards instead.
Recruit 10 target-segment users, give them the task in their own words, and watch without helping. You will see all four causes, in a way nobody can dispute in a planning meeting.
The discipline is not intervening. Explaining the feature destroys the evidence, and the moment somebody needs an explanation is the finding. Five sessions reveal the pattern and 10 confirm it.
What it rules out: all four causes at once. What it costs: recruiting, and an hour of watching.
The 5 Best Tools for Diagnosing Feature Adoption
1. Unwrap: best for reading what the users who tried the feature said
Unwrap covers the language half, which is where the mechanism lives. Everything customers said about the feature, across tickets, chat, reviews, app store posts, survey comments and sales calls, lands in one corpus and clusters into themes in their own wording, at 90%+ tagging precision, third-party verified.
That surfaces the two findings a funnel cannot produce: users describing the feature as something it is not, which means the naming taught them the wrong thing, and users who understood it and found it does not fit their workflow. Every insight traces back to the original verbatim feedback, and themes carry account context, segments, plan tiers and revenue impact, so you can check whether the struggling users are the segment the feature was built for. Real-time alerts and weekly digests reach Slack and email at an average alerting time under 24 hours for anomalous trends. Support is US-based, and the proof of concept (POC) runs on your own feedback with the taxonomy editable.
Two limits: it does not track events, sessions or funnels, so entry-point traffic and funnel completion come from product analytics, and it cannot tell you about users who never discovered the feature.
2. Pendo: best for awareness, discoverability and funnel completion
Pendo combines product analytics with in-app guides and polls, so awareness, entry-point traffic and funnel completion all sit in one place, and you can push an in-app nudge at the segment that never found the feature.
Its feedback side is collection plus a response list, so open text at volume is stored rather than analyzed. Pendo publishes tier names without prices, and quotes each paid tier on monthly active users.
3. Sprig: best for checking feature awareness in a target cohort
Sprig targets in-product studies at a precise cohort, which is the cleanest way to run an awareness check on exactly the users the feature was built for.
Its unit is the study, so it answers a question you thought to ask. Nothing is published on price, and quotes track the scale of the research program.
4. FullStory: best for finding the step where users stall
FullStory's session replay shows the exact step where users stall, which turns a funnel drop-off into a specific interface problem.
Feedback capture is light. Pricing is quoted.
5. Hotjar - by Contentsquare: best broad coverage of awareness, discoverability and completion
Hotjar covers heatmaps, recordings and on-page surveys in one product, enough to run the first three methods shallowly. It's now part of Contentsquare and bought as such.
Depth is limited on every half. There's a free plan; paid pricing is quoted.
When Low Adoption Isn't a Problem
If the feature serves a small segment deliberately, measure adoption within that segment and not across your base. A compliance feature used by 4% of customers may be at 90% of its addressable audience.
If the feature is a safety net, low usage is success. Customers should not need it often.
And if the need was speculative and the evidence says nobody wants it, the honest answer is to stop. Sunk cost drives more feature rebuilds than any diagnostic finding does.
Which Method to Start With
Start with the awareness check, always. It takes days, it is the most common cause, and skipping it is how teams rebuild a feature that was only ever a communication failure.
If awareness is fine and you have instrumentation, run the entry-point and completion checks next, since they're fast and they narrow the problem to a step. Then read what the users who tried it said: that's where Unwrap fits, with every channel's feedback about the feature in one place, ranked, traceable to the wording, and weighted so you can tell whether the complaints come from your target segment. Real-time alerts and weekly digests reach Slack and email at an average alerting time under 24 hours for anomalous trends, so confusion after a launch surfaces in days.
Watching ten people try it is what you do when the first four disagree, or when a decision is stuck. It's the most convincing evidence available and the least used.
Frequently Asked Questions
How long should you wait before judging adoption?
Long enough for the feature to reach its natural usage occasion, which varies enormously. A daily workflow feature should show adoption within 2 weeks. Something used at renewal, quarter end or during onboarding of a new team member may take a full cycle before the number means anything. Judging a quarterly-use feature at week 3 produces a false negative and a rebuild nobody needed, which is a surprisingly common way to waste a quarter.
Why isn't low adoption usually a quality problem?
Because quality is the last gate a user reaches, and most never get there. To dislike a feature you have to know it exists, find it, and use it, and each of those steps loses people. When adoption is low, the arithmetic says the loss is almost certainly upstream. Teams reach for the quality explanation because it's the one their skills address, which is worth being aware of when the investigation starts.
How does Unwrap help diagnose feature adoption?
By assembling everything customers said about the feature across every channel into ranked themes in their own wording, at 90%+ tagging precision, third-party verified, with each theme opening onto the original feedback. That surfaces the two findings dashboards miss: users describing the feature as something it isn't, and users who understood it and found it doesn't fit their workflow. Themes carry segment and plan tier, so you can check whether the struggling users are your target. Details are on feature request analytics and customer intelligence.
What if nobody has said anything about the feature at all?
Silence is itself a finding, and it points at awareness and discoverability. Users who never discovered a feature generate no feedback about it, so an empty feedback set alongside low usage is strong evidence of an awareness or discoverability problem, not a quality one. What would indicate a quality problem is feedback volume with negative sentiment, or complaints about the old way of doing the same job.
Should you remove a feature nobody uses?
Sometimes, and check the segment concentration first. A feature at 3% overall adoption that 60% of your enterprise accounts rely on is not unused, it's specialized, and removing it would be expensive in a way the headline number conceals. Check who uses it and what they're worth first. Where usage is diffuse and low, removal is often right, and worth announcing properly: the few who used it will be your loudest voices that quarter.
