Low Feature Adoption Is a Discovery Problem, Not a Gap
You shipped the feature. The demo landed, the reviews were clean, and then the usage graph flatlined. The reflex is to assume the feature isn't good enough yet, so you open a roadmap and plan the next version. That reflex is what turns low feature adoption into a six-month rebuild nobody needed.
Most of the time, a feature people ignore is missing discoverability, not capability. They never found it, never recognized it, or looked where you didn't put it. Before you fund more building, you have to know which problem you actually have, and the two look identical from the dashboard.
Why do users ignore a feature you shipped?
Usually because they never found it, not because it lacks capability. Low feature adoption is far more often a discoverability failure wearing a quality-problem costume, and the two demand opposite responses.
I recently sat down with a product manager who owns the automation area at a SaaS platform where automations run into the hundreds of millions of executions a day. His mandate was to raise user trust: when an automation fails, people need a way to see what broke and fix it. That tool already existed, an activity log showing every run's status and failure reason. On paper the problem was solved. In practice, almost nobody opened it.
A brilliant feature nobody uses is a dead letter: added complexity, burned engineering time, no business impact. The PM's job isn't to ship clever things; it's to make sure the clever thing gets used. So the first question is never "what should we add," it's "does anyone even reach this."
How do you diagnose low feature adoption?
Measure the drop-off before you touch the feature: of the users who hit the exact problem the feature solves, how many even open it. That single number tells you whether you have a discovery problem or a capability problem.
He started there. The product manager I spoke with found that of the users whose automation had just failed, only about 20% ever opened the diagnostic tool his team had built. Four out of five people who hit the exact problem it solves never touched the tool built to solve it. That is the signature of a feature people can't find, not a weak one.
The method that keeps you honest is to move in three passes:
- Go broad with data. Instrument the funnel: who hits the problem, who reaches the feature, where they fall out. Find the size of the gap before you theorize about its cause.
- Go narrow with interviews. Talk to real users about what actually happens, and above all watch them try to do the thing. Don't stop at what they say.
- Go broad again to size it. Take the specific problems you heard from a handful of people and test them against a large group with a survey or an in-product prompt, so you know whether you found a real pattern or five loud edge cases.
Skip the third pass and you build for the five people who answered your email. Skip the first and you theorize about a gap you never measured.
Why does your feature research keep confirming the wrong thing?
Because you keep asking the people who already use the feature. Every convenient feedback channel lives inside the feature, so it only ever reaches the users who found it, and the majority who didn't stay invisible.
This is the trap that nearly cost him half a year. He'd collected complaints, benchmarked competitors' capabilities, and built a kickoff deck arguing for a full infrastructure rebuild. Then he asked a few of the complaining users to show him what they actually do when an automation fails. Many couldn't find the activity log at all. Some opened a different feature with a similar name. Some said, "oh, that's nice, I'll use it next time."
Looking back, every feedback channel had quietly filtered for the same crowd. He'd sent ideas to people who already used the log, put the feedback button inside the log's own page, and heard from users who wrote in about it, who were by definition the ones using it. He'd been interviewing the 20% and drawing conclusions about the 80%. When he finally surveyed a broad group with a screenshot, about 40% said they'd never seen the feature, then said it was exactly what they'd been wanting. The real question was "why didn't you open it," not "what's wrong with this feature," and that question is invisible if you only talk to the people standing under the streetlight.
Researching the users who don't use your feature is harder and far more valuable than polling the ones who do. It's the discovery muscle I drill with teams in discovery workshops, because almost every team's default channels are rigged to hear from its happiest, least representative users.
How do you find the cheapest fix for low adoption?
Watch where users actually look for the feature, and study how competitors place and name theirs, not what capabilities they packed in. Placement and naming are product decisions, and they are usually the cheapest lever you have.
Once he reframed the question from "what's wrong with the log" to "where do people look for it," the answers changed. Users went to entirely different corners of the product, most often into the automation itself, because that's where they assumed its history lived. Competitors, viewed through the same lens, confirmed it: instead of packing in more capability, they put the run history on the same screen as the automation, in the same context as the thing that failed. Several even called it "run history," a name closer to how users thought about it than "activity log."
Then he asked his tech lead the question that changes the economics: how hard is it to move the log next to the automation. About one to two weeks, against the multi-month rebuild he'd been about to greenlight. He A/B tested the placement for a rounding error of the rebuild's cost, and it lifted adoption among users who'd hit a failure by tens of percent, climbing week over week as more people saw the feature for the first time. The expensive project would not have moved that number at all, because those users were never going to find the feature, however good it got.
Should you kill the capability project you already planned?
No. Discoverability and capability usually serve different users, so the answer is rarely "either." He ran the placement fix and kept the infrastructure project alive, in parallel, because both were right for different people.
His heaviest users, building thousands of automations, knew exactly where everything was. Discoverability did nothing for them; they needed real capability, more data, and more speed, which justified the longer build. The occasional user whose automation fails once in a while needed the opposite: something dead-simple, sitting exactly where they'd look. One roadmap can't serve both, which is why his team now starts every plan by naming which persona it serves and where the personas pull against each other.
The hardest part was pausing a project he'd already poured months into, one he believed in, once the signals said the real problem was somewhere cheaper. That is a sunk-cost reckoning, and it runs straight into your ego. The discipline that beats it is one recurring question: if I were joining this team today with fresh eyes, would I still spend the next six months this way. The deeper you are inside a problem, the more of its signals you stop noticing, which is exactly why that question has to be forced. For a framework on deciding what to pause or cut rather than protect out of habit, we've published one in the RE.FOCUS resources.
Key takeaways
- Low feature adoption is usually a discovery problem, not a capability gap. A feature people can't find looks identical on the dashboard to one people don't want. Diagnose which before you build.
- Measure the drop-off first. Of the users who hit the problem your feature solves, how many even open it. If that number is tiny, more capability won't save you.
- Research the non-users. Every feedback channel inside a feature only reaches the people who found it. The question that matters, "why didn't you open it," comes from the majority you never hear from.
- Fix placement and naming before you rebuild. Where a feature sits and what it's called are product decisions. A one-to-two-week placement change can move adoption as much as a multi-month rebuild.
- Serve different users on different tracks. Discoverability helps the casual user; capability helps the power user. Run both, and beat the sunk-cost urge to protect the plan you already made.
If your usage graph is flat and the instinct is to build more, get a second read before you commit the quarter. Separating the discovery problem from the real gap is exactly the work I run with product teams in discovery workshops. Book a session and we'll pressure-test what your feature actually needs before you spend six months on the wrong half.