A feature ships. Two weeks later, the CEO asks how it's doing.
The honest answer is "barely used."
Nobody says that out loud. What happens instead is a meeting, and in that meeting someone decides the feature isn't done yet. It's missing a setting. It needs a better empty state. Sales heard it lost a deal because it doesn't do the one thing.
So the team builds more. v2. Then v3.
And the number stays flat.
The misread that starts the spiral
Shreyas Doshi has a name for what happens next. The death spiral.
Sales says you're still losing deals because the feature "isn't full featured yet." The team believes them, signs up for more build, and ships v2 into the same silence. "Through a product leader's life," Doshi says, "you just accumulate this debt, feature after feature."
Yuhki Yamashita lived the cleaner version at Figma. Branching and merging was a feature customers explicitly asked for. They built it. And "in the initial stages, just didn't really see that much adoption."
A requested feature, built well, that nobody used.
That is not a build problem. You cannot build your way out of it, because the thing you'd build more of is already there.
What flat adoption is actually telling you
Here's the uncomfortable part. Most of the time, the feature works fine. The users just never found it, or never understood why it was for them.
Pendo has the number that should reframe the whole conversation: across thousands of products, about 6.4 of every 100 features drive 80% of the click volume. Not 80% of features. Six. The long tail of everything else you've built is competing for the few clicks left over, and most of it loses.
When I was a Solution Architect at Mixpanel, I'd sit with a team staring at exactly that shape on a dashboard, and watch the conversation go the same way every time. Not "how do we get people to the feature." Always "what should we add to make them want it." The room's instinct was to grow the tail, never to ask why nobody was reaching the head.
That instinct is the spiral. v2 is just one more entry in the 80% nobody finds.
The test before you fund v2
So before the next build cycle, run one check. It takes an afternoon, not a sprint.
- Count discovery, not usage. Of the users who could benefit from this feature, how many ever arrived at the screen where it lives? Not "used it well," just "got there." If that number is tiny, you don't have a feature problem. You have a discovery problem, and v2 won't fix it.
- Watch five real sessions of users who should have used it but didn't. Where were they when the feature would have helped? What did they do instead? You're looking for the moment they needed it and went another way.
- Separate "didn't find it" from "found it, didn't get it." These need opposite fixes. The first is a guidance problem. The second is a clarity problem. Building more functionality solves neither.
If most of your non-adopters never reached the feature at all, stop. The work isn't another version. The work is getting the right user to the thing you already built, at the moment they need it.
Why this keeps happening
Building feels like progress. It's visible, it's fundable, it's the thing the org knows how to do.
Checking whether anyone found the last thing is quieter work, and it sometimes returns an answer nobody wants: that the last three sprints shipped into a discovery gap, and the gap is still there.
It also gets worse the faster you ship, which is its own essay (Shipping Got Faster. Discovery Didn't.). The short version: you can now build features faster than your users can possibly find them, so the unfound tail grows every sprint.
This is the gap we built Deway to close: guiding each user to the feature they never found, in real time, as they work, instead of waiting for them to stumble onto it or building a fourth version they'll never see. But you don't need us to run the test above this week.
The next time a feature lands flat, the cheap question comes before the expensive one.
Not "what should we build next?"
"Did anyone ever find the last thing we built?"
Alon Binman is the co-founder of Deway (deway.ai), an AI-native autonomous adoption layer for SaaS products. Before Deway, Alon spent 15+ years at the intersection of product and customer success, including roles as a Product Manager, founder, data and product strategy consultant, and Senior Solution Architect at Mixpanel. You can reach Alon on LinkedIn.