How to discover unused features in your product

Most B2B SaaS products carry features that nobody actually uses. They’re not malicious — they were once worth shipping. But they cost engineering time to maintain, they clutter the UI, they bloat onboarding, and they distort roadmap discussions because nobody can prove either way whether anyone cares. Below is a practical, five-step playbook for finding those features and deciding what to do about them.

This isn’t a theoretical guide. It’s the playbook we use ourselves, and the one our customers use UsageLens to run.

Step 1 — Instrument feature-level usage (not events)

The most common mistake when teams set out to measure unused features is to start from existing event analytics. The events are usually too granular, inconsistently named, or skewed by funnels that don’t reflect actual feature use.

Start fresh, at the feature level. Make a list — yes, a literal list — of every feature in your product that a user can invoke. Aim for the level of granularity where each item is something you could deprecate as a unit. A button that opens a panel is part of a feature; the panel itself is the feature. A keyboard shortcut is part of a feature; not its own feature.

Then instrument each one with a single signal: this feature was used, by this anonymized user, in this context, at this time. That’s it. One API call per feature, fired wherever the feature is invoked — including background features like scheduled jobs, API-driven workflows, and auto-running tasks. Those are exactly the features click-based analytics tools miss, and they’re often doing the most work. With UsageLens, the same API call works from a click handler or a server-side job, so instrument both.

If you’re using UsageLens, this is the data collection step. If you’re not, you can build the same model on top of an event analytics tool — just be disciplined about the naming convention from day one.

Step 2 — Segment usage by user role and customer tier

Raw usage counts are deceptive. A feature used 10,000 times last month might be used by three superusers in one enterprise account. A feature used 50 times might be used by 50 different customers — far more strategically important.

For each feature, look at:

Distinct users per week / month, not total invocations.
Distinct customers per month — especially important for B2B.
Distribution by user role (admin, viewer, regular user). If a feature is only ever used by admins but was designed for everyone, that’s a signal.
Distribution by customer tier (free, pro, enterprise). Features used disproportionately by your highest-paying customers may be earning their place even at low absolute volume.

The goal here is to avoid two opposite mistakes: killing a feature that’s quietly load-bearing for a key segment, and protecting a feature that has flashy total numbers but no real reach.

Step 3 — Measure adoption curves over time

A snapshot of feature usage isn’t enough. You also want the shape of adoption — is it growing, flat, or declining?

For each feature, plot weekly active users since launch. You’ll typically see one of four patterns:

Healthy adoption — a curve that rises through onboarding and stabilizes at a meaningful share of active customers. Leave it alone, or invest more.
Slow burn — never quite catches on but doesn’t decline. These are the candidates for either iteration (“does it solve the right problem?”) or sunset (“should we admit this isn’t going to work?”).
Declining — was once used, isn’t anymore. Often signals a competing feature, a workflow change, or a regression. Worth investigating.
One-time spike — used heavily at launch, then never again. Usually means people tried it once and didn’t come back. Either a bug, a UX problem, or a feature solving a non-problem.

The pattern matters more than the absolute number. A small but growing curve is more interesting than a large but flat one.

Step 4 — Cohort by customer to find concentration

For B2B products, the next step is asking which customers depend on a feature. A feature with 200 monthly active users sounds healthy until you discover those 200 users all belong to two enterprise accounts.

Run this analysis for every feature with non-trivial usage:

How many distinct customers used this feature in the last 90 days?
What share of total customers does that represent?
Of the customers who do use it, are they typically your top-tier accounts, mid-tier, or low-tier?

A feature concentrated in two enterprise accounts isn’t necessarily worth keeping (depends on those contracts), but you need to know before you deprecate. A feature used broadly but shallowly may have a different fate than one used deeply by a few.

Step 5 — Decide: invest, iterate, or sunset

Once you have the data, run each feature through a three-way decision:

Invest — adoption is healthy, the curve is growing, and there’s clear value to building further. Allocate more engineering capacity.
Iterate — there’s some adoption but not what you expected. Before sunsetting, try one focused round of improvement: rework the UX, change the entry point, fix the onboarding. Re-measure 90 days later.
Sunset — adoption is low, concentrated, declining, or never materialized. Communicate to the affected customers, give them time to migrate or export, then remove. Removing dead features is one of the highest-leverage things product teams can do, and one of the rarest.

Don’t skip the communication step. Even a feature used by 10 customers will have one of those customers email support if you remove it silently.

How to run this in UsageLens

The five-step playbook above is intentionally tool-agnostic. If you’re using UsageLens specifically, the practical workflow is:

Define your feature list in UsageLens.
Add one API call (POST /track) wherever each feature is invoked, with the anonymized user ID, customer ID, and role.
Open the dashboard and filter by user role, customer tier, or time window to surface the questions above.
Use the side-by-side feature comparison to spot which features are growing vs. stalling.
Export the data for the deprecation discussion with stakeholders.

There’s no SQL, no dashboard-building, and no event taxonomy maintenance — that’s the whole point of building UsageLens around features rather than events.

A note on what not to measure

A few patterns we’d recommend against:

Don’t treat UI clicks as your only signal. For user-facing features, a click is often the natural moment a feature gets used — tracking it there is fine. The trap is making clicks the only mechanism: background features, scheduled jobs, and API integrations are invoked without a click and will be invisible. Instrument the feature wherever it actually runs, click handler or backend code.
Don’t conflate adoption with satisfaction. A feature can be heavily used and hated. Usage data tells you what, not why. Pair it with qualitative feedback when sunsetting anything non-trivial.
Give it time before you decide. Wait until you have at least 90 days of data on an established feature — or a full onboarding cycle on a newly launched one — before drawing conclusions. Shorter windows are too noisy to act on.