Why is nobody using the new feature I built?
Usually because people never reached it, not because they looked at it and said no. A new feature has to beat the path users already take for that job, and the old path keeps working, keeps being documented and keeps being what habit reaches for. Before reading zero usage as zero demand, check four things in order: did people see it, did the moments where they needed it lead to it, did the first attempt work, and did they come back. A zero at either of the first two is a routing problem you can fix this week.
Zero usage is a routing result before it is a demand result
When a shipped feature sits unused, the tempting read is that you built the wrong thing. That conclusion needs evidence you probably do not have yet. Usage only happens when a person with the job arrives at the feature at the moment they have the job, and in most products that moment arrives somewhere else: in a menu they already know, a template they copied last month, a help article written before the feature existed, or an onboarding email that still describes the old way.
The old way is the real competitor, and it has an advantage your launch post cannot remove — it still works. Nothing errors when someone takes the long route, so nothing tells you it happened. A feature that people rejected and a feature nobody could find produce the same number in your analytics, which is why the diagnosis has to separate them before anyone argues about the roadmap. For brand-new signups the equivalent question is the first win, covered in how do I improve user onboarding for my SaaS; this page is about the users you already have.
Read the zero one stage at a time
Adoption by an existing user works like activation for a new one: a short sequence of stages, each of which has to happen before the next can. Find the first stage where the count collapses. Each has a different owner and a different fix, and the cheap fixes all live near the top.
| Stage | What a zero here means | How to check |
|---|---|---|
| Seen | The people who needed it never learned it exists | Count views of the entry point, not uses of the feature, among users who had the job that week |
| Routed | The places where people act still point at the old path | Walk the job from start to finish the way a user would: the menu, your templates, your help docs, your emails, any saved instructions |
| Tried | They reached it and the first attempt failed or confused them | Watch three people attempt the job in one sitting and note every error, empty screen and abandoned form |
| Repeated | It worked once but did not beat the old habit | Compare second use with first use per user; healthy first use with weak second use means the feature is losing on value |
Only the last row is evidence about demand. A collapse at seen or routed says nothing about whether the feature is wanted, and removing it on that basis throws away work the market never got to judge.
The feature we built that was never used once
We built a content calendar into AgentCeres — the AI Growth Officer at agentceres.com — so that a social post could be approved once and then published on schedule, without anyone needing to be around at the time it went out. When we checked production, it had not been used a single time. Not rarely: zero scheduled posts, across every account.
The users in this case were our own agents rather than people clicking through a screen, which made the cause easy to read, and the cause was routing. The written instructions our agents follow when asked to schedule a post predated the calendar and listed every other way to do it. So when a paying customer asked for exactly what the calendar exists for — keep this approved post and publish it tomorrow morning — the agent did what its instructions said, and set itself a reminder to come back the next day and ask for approval again. The customer would have had to be present a second time for a post they had already approved.
Demand was there at the exact moment the feature was built for, and the path sent it somewhere else. Nothing failed, so nothing alerted anyone. The fix was not an announcement: we made the calendar the first answer in those instructions, marked the old route as a last resort together with what choosing it costs, and replaced a worked example that had been quietly teaching the old habit. Judged on its usage alone, it would have looked like a feature nobody wanted.
Fixes, in the order they pay off
Work down the table from the top, and give each change a fair window before you read the next number.
- Find every place that describes the job — help docs, templates, onboarding emails, saved prompts, sales scripts — and make the new feature the first answer in each.
- Put the entry point where the job starts, not where the feature happens to live in your navigation.
- Tell the users who did the job the old way this month, individually, in one sentence about what they no longer have to do.
- Watch three people try it before you build anything else on top of it.
- Only then read second use. That is the number that answers whether it is wanted.
FAQ
- How long should I wait before deciding a feature failed?
- Long enough for the job it serves to come up several times for the people who have it. A weekly job needs weeks of data, a monthly one needs months, and a launch-week spike tells you about curiosity rather than adoption. Set the window before you look, in terms of how often the job happens, so the number cannot talk you into the answer you were already leaning towards.
- Should I announce the feature again?
- An announcement fixes the seen stage and nothing below it. If people saw the first one and still take the old path, a second one reaches the same people with the same result. Change what happens at the moment of need instead — the entry point, the template, the default — and announce it only to the users you can show it saves time for.
- Should I remove the old way of doing it?
- Rarely, and never first. Removing a working path forces adoption and hides whether the new feature is actually better, and the users it annoys most are the ones who relied on the old path most. Make the new route the default and leave the old one reachable; if second use of the new feature holds up, the old path will empty on its own.
- Is low feature adoption a sign of churn?
- It can be an early one, but only for features tied to the reason people pay. A feature that serves an occasional job can sit at low usage inside a perfectly healthy account. Watch adoption of the features that carry your core value, and treat the rest as roadmap questions rather than retention alarms. How do I reduce churn for my SaaS covers the retention side.
Want this done for you?
AgentCeres is a managed AI marketing team — specialists draft the work, you approve what ships. 14-day free trial, from $39/month.