Driving adoption. The configuration they can't walk away from.

Activity is not adoption

The distinction that matters is depth versus activity. An account logging in daily to check a single report is active — and shallow. It's using the product the way you use a wall clock: glancing at it, never depending on it. Depth looked different. Depth was a customer using a broad set of features — tasks, the calendar and events, integrated email, the deals and contacts views — on top of repeated logins. Not one habit, but the product threaded through the whole workflow.

That's the line between "using it" and "relying on it," and it's the line that predicts retention. Raw activity tells you the lights are on. Depth tells you the customer would feel the loss if you disappeared.

Why the sticky features stick

Some features were dramatically stickier than others. For us it was custom fields, custom list views, and the pipeline review — and if a customer implemented those, their churn probability dropped, noticeably. The interesting question is why those, and not some flashier capability.

This is the most useful thing I know about adoption, so it's worth stating as a principle. A feature you simply use is easy to walk away from. A feature you configured — that holds your data shaped to your process, that your team has been trained on — is woven into how the company works, and pulling it out means unpicking that work. The switching cost isn't something you imposed with a contract. It's something the customer built, voluntarily, by investing effort — and that's the most durable kind there is.

The implication for how you drive adoption is direct: don't just push customers to use more features. Push them toward the features that ask something of them — configuration, data, team training. The effort feels like friction in the moment and becomes retention later. A customer who has merely tried your product can leave on a Tuesday. A customer who has built their workflow into it has to dismantle something to go.

Deepening an already-live account

Getting a live customer to go deeper — to pick up the features they aren't yet using — is its own motion, separate from onboarding. We tried four tactics, and they did not perform equally.

We marketed underused features through QBRs, through webinars (both customer-specific sessions and broader cross-customer ones), through email campaigns, and through in-app messaging. Of the four, QBRs and webinars worked best by a clear margin — a real conversation or a live walkthrough, where a human showed the customer what a feature would do for them. In-app messaging, the tactic that scales most cheaply, tended to yield the least.

There's a pattern in that ranking worth noticing: the tactics that worked were the high-touch ones, the same lesson that runs through onboarding and the save play. Deepening adoption is a persuasion problem, and persuasion still mostly happens human-to-human. The cheap, automated nudge is appealing precisely because it scales — and it underdelivers for the same reason.

The gating we couldn't build

One honest constraint shaped our adoption work: we feature-gated across plans, but not as aggressively as we should have, and the thing holding us back was engineering resources, not strategy. We knew gating could help; we couldn't always build it.

Where it would have helped most is telling. Smarter gating around email integration, custom fields, and custom list views — the very features that created depth — would have done double duty: nudging customers toward the sticky capabilities while giving the upgrade conversation something concrete to stand on. Gate the features that create depth, and a customer reaching for depth naturally reaches for a higher plan. We left some of that on the table for want of engineering time, which is its own quiet lesson about what bootstrapped constraints actually cost.

Adoption lives or dies with the leader

Here's the organizational truth underneath all of it: adoption was driven, more than by anything else, by the champion — the VP or Director of Sales. Where we had a committed sales leader, adoption took. Where we didn't, it died, almost regardless of what the product or the CSM did.

That reframes the whole problem. You are not, fundamentally, persuading thirty individual reps to love your software. You're equipping one leader to require it — because a leader who runs their team off the tool makes adoption the path of least resistance for everyone under them. The single most effective version of this we ever found was the sales leader running their weekly pipeline meeting from the product; no rep wants to sit in that meeting in front of their boss and peers looking at obsolete data. (That mechanic earns its own treatment in the first 90 days — here the point is simply that it flows from the leader, not the rep.)

The quiet engine, and the honest paradox

Does depth of adoption predict retention? Clearly, yes — better than almost anything else we watched. And it sounds almost too simple to say out loud: get your customers to genuinely use the product and see its value, and they'll stay.

That's the truth. It's also much easier said than done, because customers will find many reasons not to adopt your product, and left alone, plenty of them will. I'll admit the failure mode my own company fell into at times: customer signs up, converts, gets set up and trained — and then we forget about them until they cancel. The most dangerous stretch isn't the trial and it isn't the cancellation. It's the long, quiet middle, where a customer who never reached depth slowly drifts back to their old habits and stops logging in.

That's why adoption can't be left to chance after training. It's the highest-leverage retention work there is, and it's invisible — no fire, no angry email, just a workflow that never quite took. The whole job is making sure depth happens on purpose: push the features that ask something of the customer, deepen through real human touch, and arm the one leader who can make the team rely on you. Do that, and the health score stays green because the underlying thing it measures is actually true.