Product Engagement metric

Feature Adoption. The only honest referee in product development — and almost everything in your org is built to ignore it.

Feature Adoption is the percentage of your customer base that actually uses each feature. It's the honest scorecard for your roadmap: the number that tells you whether the thing you spent a quarter and six figures building actually mattered, or whether it's sitting in the product as dead weight you'll maintain forever. Here's the uncomfortable truth I learned over sixteen years running a CRM — the core features we launched with carried the business, and most of what we built in later years barely got touched. Adoption is the referee that calls that out. The problem is that the entire organization is wired to argue with the call.

What it is

The percentage of active customers who actually use a given feature in a period. Measured per feature, not blended — deals created, contacts imported, email sync, reporting, each tracked on its own. The honest read on whether a feature earns its place in the product, or just costs you maintenance.

Measurement period

Monthly.

Track adoption per feature month over month. It's the single biggest leading indicator of churn — a customer who isn't using the product isn't seeing value, and a customer who doesn't see value leaves.

Formula

Customers using the feature

Total active customers

× 100

Per feature, not blended across the product. Define "using" honestly — logged in once isn't adoption; repeat, unprompted use is.

When to review

Monthly.

Review the per-feature breakdown monthly, and use it as the referee in every roadmap discussion — what to polish, what to promote, and the hard one, what to kill.

Why it matters

We built Goals. Nobody used it for twelve years.

Let me tell you about the most honest feature-adoption lesson I ever got. We built a feature called Goals — a pet project of mine, inspired by something Nike had done in their running app. We shipped it thin, it was missing the pieces that would've made it land, and it never took off. And then it just… sat there. For a dozen years. An embarrassment in the product that our salespeople were literally coached not to show or talk about. Every one of those years, it cost us something to maintain, and it returned nothing. That's what low adoption actually looks like up close — not a number on a dashboard, but a feature you're quietly ashamed of and can't bring yourself to remove.

At PipelineCRM, customers used maybe half our features, and the half they used was telling: deals, contacts, tasks, email sync, calendar sync, follow-ups — almost all of it was the core we launched with. The stuff we built in later years, chasing the next thing, mostly didn't move the needle. That pattern is the real lesson of feature adoption: the instinct to build new is almost always stronger than the evidence says it should be. And the metric exists to push back on that instinct with data.

The deeper reason it matters is downstream: feature adoption is the single biggest driver of churn. A customer who isn't adopting the product isn't seeing value, and a customer who doesn't see value will leave — it's only a question of when. That's why this sits in engagement, ahead of retention on your scorecard: adoption is the leading edge of the churn you'll book two quarters from now. You don't get to manage retention directly. You manage adoption, and retention follows.

Goals sat in our product for a dozen years — an embarrassment our salespeople were coached not to show. That's what low adoption looks like up close: not a dashboard number, but a feature you're ashamed of and can't bring yourself to remove.

Worked example

Same product, four features. The adoption number sorts them for you.

A snapshot of a CRM's feature adoption across its active base. The number alone doesn't make the decision — but it forces the conversation each feature has been avoiding, and tells you where the work actually belongs.

Core · 88%

88%

FeatureDeals & contacts
Adoption88%
TrendSteady
ActionPolish and protect

The load-bearing core. This is where the value lives, so this is where investment should go — fix the bugs, smooth the edges, make the thing 90% of customers touch every day even better. The least glamorous work, the highest return.

Discoverable? · 34%

34%

FeatureReporting
Adoption34%
TrendFlat
ActionPromote or improve

Genuinely useful, under-adopted. Before killing or ignoring it, ask whether the problem is the feature or its discoverability. A valuable feature a third of customers use may just need to be easier to find — promotion before judgment.

Graveyard · 4%

Feature"Goals"
Adoption4%
TrendDead, years
ActionTest, then decide in 6 months

The pet feature nobody uses. Run the real test — does having it drive any adoption or retention? — and then make the call within six months. Don't let it sit for a dozen years costing maintenance and returning nothing.

Benchmarks

The bands — but read the strategic exception before you cut.

Adoption thresholds for a given feature across your active base. Treat the low end as a prompt to investigate, not an automatic kill order — a low-adoption feature can still be load-bearing for a key segment, and a low number with hundreds of real users behind it is a careful conversation, not a delete button.

Core Over 60%

Load-bearing. A majority of your base relies on this, so it's where the value — and the churn risk — concentrates. Invest here: polish it, fix its bugs, make it better. The unglamorous work on your core features almost always beats building something new.

Healthy 35 — 60%

Solidly adopted. A real, useful feature pulling its weight for a meaningful slice of customers. Keep it healthy, watch the trend, and look for ways to push it higher — but it's earning its place in the product.

Investigate 20 — 35%

Under-adopted — find out why before you judge. Is it a discoverability problem (good feature, nobody finds it) or a value problem (they find it and don't care)? The fix is completely different. Promote it and improve it before concluding it's dead.

Graveyard Under 20%

Probably not pulling its weight — but check the exception first. Is this dead weight, or a small-but-strategic feature load-bearing for your biggest accounts? If it's genuinely dead, run the adoption/retention test and decide within six months. Don't let it become a twelve-year embarrassment.

When adoption is low

Three plays that actually move it.

Low adoption isn't one problem — it's three different problems wearing the same number. The plays run in order: diagnose which one you have, resist the reflex that caused it, and only then make the kill-or-keep call with real evidence.

— 01 Diagnose: discoverability, value, or dead?

Three problems, three completely different fixes.

A low number could mean customers can't find the feature (discoverability — fix the UX and promotion), can find it and don't care (value — the feature is wrong, not hidden), or genuinely never needed it (dead weight). These look identical on the dashboard and need opposite responses. Before you touch anything, figure out which one you're actually looking at — talk to the customers who don't use it, not just the ones who do.

— 02 Resist the new-feature reflex — polish instead

The pressure is always to build new. Push back.

Here's the trap that quietly kills SaaS products: the prospect who won't sign without feature X, the customer success team sure a renewal hinges on feature Y, the co-founder with a brilliant new idea, the engineers bored and wanting a new toy to build. Every force in the org pushes toward new. Meanwhile support is hearing that an existing feature could be great with a few fixes — and nobody's listening. In a new SaaS company, I'd invest far more in polishing what you have and fixing its bugs than in chasing the next new thing. New rarely pays back what it promises.

— 03 Run the real test, then decide in six months

A/B it, hold it accountable, make the call.

Adoption alone isn't proof — the real test is whether the feature drives anything. Split it: these customers have it, these don't. Does it lift adoption? Retention? Expansion? That's the true measure of success, and almost nobody runs it. Set a window — six months — and at the end, make a decision: kill it or commit to it. The discipline isn't the test; it's forcing the decision instead of letting the feature drift into the graveyard for a decade.

Common mistakes operators make with Feature Adoption.

Choosing new over polishing what already works.

The biggest one, and the hardest to resist. Every pressure in a SaaS company points toward building new — sales wants the feature that lands the prospect, success wants the one that saves the renewal, the founder has a vision, the engineers want a fresh toy. Almost nobody is championing "let's fix the bugs in the feature 88% of customers already use." But that polishing work usually has the higher return, because it improves the experience of your whole base instead of a hypothetical slice. Be aggressive about improving what works before you build what's new.

Never enforcing accountability on the bet.

Features get built on a narrative — "this lands enterprise accounts," "this expands seats," "this closes deals that need the security feature." Fine. But almost no one goes back and checks: how many seats did we actually expand? How many deals did the security feature actually close — more or fewer than we promised? The investment is real and unrecoverable, so the discipline has to be measuring whether the bet paid off. If you never audit the narrative, you'll keep funding narratives that don't.

Reading raw adoption % without strategic context.

A low number isn't automatically dead weight. The integration only 8% of customers use might be the one your three biggest accounts depend on; the security feature few touch might be what clears enterprise procurement. Raw adoption hides that. Before you act on a low percentage, ask who the users are and what the feature unlocks — separate genuinely dead weight from small-but-strategic. The math is the prompt; the judgment is yours.

Letting loud customers drive the roadmap.

A single big customer demanding a feature — even one tied to meaningful revenue — is not the same as the base needing it. We stuck to our guns most of the time: would this be useful to all of PipelineCRM's customers, or just a few loud voices? Feature-adoption data is exactly the ammunition for that fight, with sales and even with your own product team. Build for the base, not for the loudest account in the room.

Not collecting evidence before the investment.

The cost of a feature is real and you can't undo it — $50K to $100K in development plus years of maintenance, gone whether anyone adopts it or not. The fix is unglamorous: collect more data from customers and prospects before you commit. It slows you down, and that's the point — better a slower decision than six figures down the drain on something that ends up in the graveyard. Validate demand before you build, not after.

Letting dead features linger instead of deciding.

The real failure with Goals wasn't building it — it was letting it sit for twelve years without a decision. Low-adoption features are hard to kill: even 5% can be hundreds of customers you'd have to message carefully about why and how. But indecision is its own cost — maintenance, clutter, the salespeople coached to hide it. Set a window, run the test, and make the call. Keeping it or killing it are both fine; letting it drift is the mistake.

Read alongside

Low adoption today is churn next quarter.

Feature adoption is the leading edge of retention — a customer not using the product isn't seeing value, and will eventually leave. By the time it shows up in revenue churn, the conversation that could have saved them is already a quarter late. Watch adoption to get ahead of the churn it predicts.

Revenue Churn guide →

How Upbeat helps

The referee, on the scorecard where the roadmap gets argued.

Feature adoption only changes decisions if it's in the room when decisions get made. Upbeat keeps per-feature adoption on your weekly scorecard, next to the churn it predicts — so when sales pushes for a new feature or a pet project drifts toward the graveyard, the data is right there to referee the call. The honest number that turns roadmap debates from opinion into evidence.

See how it works → See pricing

Related metrics

Adoption leads. These are what it predicts.

Build for the base, not the loudest account in the room.

Upbeat keeps per-feature adoption on your scorecard next to the churn it predicts — so the roadmap gets argued with evidence, the polish-versus-new fight has a referee, and no feature drifts into the graveyard for a decade.

Email Nick directly →