Identifying Features With High Discovery but Low Habituation in B2B SaaS

Customer Alliance saw feature adoption climb nearly tenfold without touching the feature itself. The gain came from closing the gap between knowing which users hadn't picked up a capability and reaching them with guidance that was relevant and well-timed. Nobody redesigned anything. The mechanism was targeting.

That result only makes sense once you separate two things most B2B SaaS teams lump together as one problem: low feature usage. A user who tries a feature once has been activated. A user who comes back to it on their own, without a prompt, because it's become part of how they get work done, has adopted it. Those are different events, and the funnel between them has four stages: exposed, activated, used, used again. Only the fourth stage counts as adoption.

The distinction matters because the fix for each failure looks nothing alike. A feature with strong activation and no return usage needs a different intervention than a feature nobody finds in the first place, and running the wrong fix burns sprint capacity without moving a single metric. That's the trap: the two problems look similar from a dashboard showing low usage, but they demand opposite responses.

The scale of the problem is bigger than most teams assume. Pendo's 2025 State of Product report puts the average SaaS application at 40 to 60 distinct features, while users regularly touch only 5 to 8. The rest sit unused by the people paying for them, invisible rather than failing. Diagnosing why requires the four-stage lens above, applied feature by feature, cohort by cohort, rather than treated as one undifferentiated "adoption" number.

Three structural reasons the gap is wider in B2B than in consumer SaaS

B2B adoption breaks down for reasons that consumer product-led growth thinking doesn't account for, and in accounts with many users and many roles those reasons let the discovery-habituation gap go undiagnosed for a long time.

The multi-user account itself is the first reason. One champion activates a feature, logs in regularly, and shows up as healthy usage in a product manager's session data. Meanwhile the rest of the team never touches it, so account-level feature penetration sits far below what the dashboard implies. The gap becomes visible at renewal, when the conversation reveals a product embedded in one person's workflow and nowhere else in the company.

The product itself keeps growing after the sale closes. Every feature shipped after signup requires its own re-adoption cycle from existing users, separate from whatever onboarding they got on day one. A customer who fully adopted the product in January hasn't adopted the three capabilities released since, and their adoption curve effectively resets at every release without anyone designing for that reset. Consumer apps with a narrower, more stable feature set don't face this compounding problem at the same rate.

One account can contain several genuinely different users with different jobs. The features that keep an account administrator renewing aren't the same ones that keep an end user engaged in the same account, so a single adoption campaign aimed at the average user ends up serving neither well.

A natural objection is that this is really just a weak onboarding flow. It isn't, because onboarding and the discovery-habituation gap cover different things. Onboarding covers the first experience a new user has with the product as it exists on day one. The discovery-habituation gap covers everyone, new and tenured, against a feature set that keeps changing underneath them. Fixing onboarding for new signups does nothing for existing users who never touched the three features shipped last quarter.

Discoverability problems versus value problems

Two numbers separate the two failure modes: feature activation rate by eligible cohort, and feature retention rate at 90 days. Read together, they tell you which problem you're actually facing instead of leaving you to guess from a single usage figure.

Activation rate by eligible cohort asks what share of users who have access to a feature, and an actual workflow reason to use it, have touched it at least once. The denominator has to be the right population. Counting every logged-in user understates how badly a feature is being missed by the cohort that actually needed it.

Retention rate asks, of the users who did activate, how many came back. A curve that spikes on first use and then drops off sharply signals a value problem. The feature got found. It just didn't hold.

Activation and retention together produce four possible outcomes. Low activation paired with low retention points to a discoverability problem, meaning users simply aren't finding the feature. High activation paired with low retention points to a value problem: users found it, got nothing sticky from the first interaction, and didn't return. Low activation paired with high retention among the small group that did find it points to an announcement problem, where a feature carries real value but reaches almost nobody. High activation paired with high retention means the feature is working, and the team should look elsewhere for its next adoption problem.

Time-to-first-use and first-week engagement intensity predict long-term retention well before the 90-day mark arrives, so they're worth tracking alongside these two core rates. Users who engage early with a feature are substantially more likely to stick with it, which makes early-week behavior a leading indicator rather than something you only learn in hindsight.

None of this works without defining, ahead of time, what counts as adoption for a given feature. The right criterion is a behavior that shows the feature has changed how someone works day to day. That threshold varies by feature and by workflow, so it has to be set deliberately rather than borrowed from another team's definition. Tracking against that kind of action-gated milestone, rather than counting any interaction, gives both the user and the product team an honest read on whether real adoption is happening or just surface-level contact.

The behavioral window that determines whether a habit forms

The usual explanation for a feature that gets found but never sticks is that the feature itself lacks value, or the launch announcement was weak. Often the real cause is simpler: the announcement fires at the wrong moment for the person receiving it.

There's a narrow stretch of time, typically right after signup or right after a user finishes a related task, when the odds of adopting a new feature are highest. Most teams miss that window because their announcement logic runs on a calendar, not on what the user is actually doing. An in-product prompt set to fire on day three reaches every user on day three regardless of what they're working on, and someone deep in an unrelated task won't retain a feature announcement timed to a date on a schedule.

Habituation doesn't form from a single exposure under those conditions. If activation is high and retention is low, the first interaction didn't give the user a concrete enough reason to return, and no follow-up message fixes that if the original timing missed the window.

Crossbeam tested this directly. The company switched from a role-based announcement strategy to behavioral routing for its in-product banners and saw click-through rates triple. The announcement's content stayed the same. Only the timing relative to what the user was doing changed.

Contextually triggered feature introductions, shown while a user is actively working in a related part of the product, appear to achieve substantially higher engagement than time-based announcements delivered at login or by scheduled email. Yet only a minority of feature launches include targeted, behavioral campaigns that guide specific user segments toward the features relevant to their workflow, and passive launches land well behind behaviorally triggered ones on 90-day adoption.

Three triggers stand out: a prompt re-engaging users promptly when activation is incomplete, a "here's what to do next" message delivered right after someone completes a first key action, and a discovery prompt aimed at users who've been active for a week but still haven't found a feature that matters to their workflow.

What the gap costs when it goes undiagnosed

The discovery-habituation gap is hard to catch because the numbers most teams check every day don't register it. Session counts and login frequency look fine right up until the churn data arrives weeks or months later.

Totango's 2025 customer health research found that accounts adopting fewer than three core features in their first 90 days churn at renewal far more often than accounts adopting five or more, and that relationship between adoption breadth and retention runs close to linear.

It also hides behind healthy-looking revenue numbers. A company can post strong gross and net revenue retention overall and still find that most of its churn comes from customers who never adopted the core features the product team shipped for them. The product team did its job. The adoption motion never caught up, and that's precisely where the return on a roadmap quietly disappears.

The account-level version of this problem compounds the delay. A champion activates a feature and looks like a satisfied, active user, while the rest of the account never touches it. Nobody sees the gap until a customer success manager sits down for the renewal conversation and finds a product that only ever lived in one person's workflow. By then, it's late in the retention cycle, with little room left to intervene before the decision gets made.

The stakes go beyond any one product team's roadmap. McKinsey's analysis points to net revenue retention as the metric now deciding SaaS valuations, and feature adoption breadth is one of the clearest levers a company has on NRR. That puts the discovery-habituation gap on the board's agenda, not just the product team's.

Measuring eligible-cohort adoption instead of raw activation

Counting every logged-in user inflates the base and turns a serious gap into something that looks like normal variance.

The fix is a specific formula: feature adoption rate equals the number of users who completed the defined adoption action, divided by the total eligible users in the period, times 100. "Eligible" means users who have access to the feature and an actual workflow reason to use it, not everyone who happened to log in that month.

Before running that calculation, a team has to define what the adoption action actually is: the specific behavior that shows a feature has become part of someone's regular workflow, set feature by feature and workflow by workflow rather than applied as one universal click count.

Restricting the denominator this way turns a vanity metric into a working diagnostic. If 180 of 600 eligible users completed the defined adoption action, the useful question is what happened to the other 420.

The same discipline applies to the unit of measurement. Account-level adoption numbers can mask individual-level gaps entirely, since a feature used by one power user inside a ten-seat account isn't meaningfully "adopted" by that account at all. Measuring at the person level, inside each account, is what exposes the gap the renewal conversation would otherwise reveal too late.

A message sent before someone uses a feature, followed by that person using the feature, doesn't prove the message caused the behavior. The measurement setup needs to track whether product behavior actually changed.

Retention at 30 and 90 days is the real test of whether any of this worked. A high 30-day adoption rate that falls off sharply afterward means the first interaction didn't hold up as a value proposition, even though the feature cleared the activation bar. That's the number that confirms whether a fix actually closed the gap, or just moved it further down the funnel.

Moving from behavior data to individually grounded guidance, not broadcast nudges

Diagnosing the gap by eligible cohort and locating it correctly in the funnel only pays off if the response that follows matches the diagnosis. The intervention that actually works is guidance grounded in each person's current state in the product.

Broadcast nudges fail for a structural reason: they treat a segment as if every person in it is in the same place at the same time, when the whole point of the activation-retention split is that people in the same segment are often standing in completely different spots in the funnel. Someone who activated a feature and quietly abandoned it needs a different message than someone who's never found the feature at all, and sending both the same email solves neither problem.

The Customer Alliance result traces back to exactly this kind of precision. The gap closed because the team could identify which users hadn't adopted a given capability and reach each one with guidance relevant to their situation, delivered at the right moment.

That same precision matters most once the activation-retention split has told a team which failure mode it's dealing with. High activation paired with low retention points to a value problem, and the right response is reaching the specific users who tried a feature and dropped it, not re-engaging the whole eligible population at once.

The multi-user account issue calls for the same logic applied across roles instead of across time. A single champion's activation data says nothing about whether an account administrator and an end user on the same team would get value from a feature in the same way, so a reactivation campaign built for "the average user" misses both of them. Adoption agents built to ground guidance in a person's actual role and usage pattern, rather than mail-merging a first name into a template, are what separates a renewal conversation that reveals adoption spread across a team from one that exposes a feature still living in a single person's workflow.

None of this replaces the diagnostic work in the sections above. The activation and retention numbers tell a team what's broken. The guidance that follows only closes the gap if it's built around what each person has actually done in the product, not around what the average member of their segment is assumed to need.