We launched a core analytics feature to 300,000 enterprise users. Ninety days later, adoption was at 23%.
The first instinct from leadership was: we need a campaign. An email sequence. A webinar. Maybe an in-app banner. Some form of marketing push to make users aware the feature existed.
I pushed back. Here's why — and what we found instead.
The wrong diagnosis
When a feature has low adoption, the reflex is to treat it as an awareness problem. Users don't know it exists, so we need to tell them about it.
This is wrong more often than it's right — and it's a costly mistake, because campaigns take resources and time, and they often don't move adoption in any durable way. You get a spike on launch week, then numbers drift back to baseline.
The more likely explanation for low adoption is a friction problem. Users found the feature. They tried it. Something got in the way before they got to the value moment. They gave up — not loudly, but quietly, by just not coming back.
The question isn't "do users know this exists?" It's "what stopped them between finding it and using it?"
How to audit a feature funnel in 2 weeks
I don't have a dedicated data team. What I have is Mixpanel, Hotjar, a Zendesk export, and two weeks.
Here's the audit structure I ran:
Week 1: Map the funnel, find the drop-offs
Step one was defining the funnel. Not the funnel we wished existed, but the one users actually experienced. Starting from the feature entry point (in this case, a nav item in the left sidebar), I mapped every discrete step between "user sees feature" and "user completes first meaningful action."
We had 8 steps. I pulled event data for each step and calculated step-by-step conversion.
The numbers:
- →Step 1 → 2: 81% (most users who found the sidebar item clicked it)
- →Step 2 → 3: 67% (most users who landed on the feature started interacting)
- →Step 3 → 4: 31% (two-thirds of users dropped off at step 3)
Step 3 was where we needed to look.
Week 2: Understand why
For Step 3, I did three things:
- Session recordings: Watched 200 sessions of users who hit Step 3 and didn't proceed. Within the first 20, a pattern was visible. Users would reach a configuration screen, look at it for 5–15 seconds, and then navigate away. They weren't confused by the interface — they were looking for something that wasn't there.
- Support tickets: Searched Zendesk for tickets mentioning the feature name. Found 47 tickets in 90 days, almost all of them asking the same question: "Where do I connect my [data source] to this?"
- User interviews: Spoke with 8 users who had not adopted the feature. Every single one had reached Step 3 and stopped because they didn't know how to connect their existing data. They assumed it required IT involvement or a technical setup they weren't equipped to do.
The feature required connecting a data source at Step 3. We had assumed users would understand this was a quick, self-serve action. They assumed it was complex and required help they didn't have access to.
The 3 friction points we fixed
Based on the audit, we identified three specific interventions — none of which required engineering to build new features:
Friction point 1: No progress indicator
Users at Step 3 had no sense of how close they were to being done. When you don't know how far away the finish line is, you're more likely to quit. We added a 4-step progress bar (Step 3 was the last real step — users didn't know they were almost there).
Friction point 2: The "connect data" prompt had no context
The screen that asked users to connect their data source had a field and a button. Nothing else. We added a single line of copy underneath: "This takes about 2 minutes. No IT required." We also added a tooltip showing an example connection that matched the most common data source our users had.
Friction point 3: No recovery path
Users who clicked away from Step 3 had no way back except navigating through the sidebar again. We added a contextual tooltip that appeared the next time they logged in: "You're one step away from setting up [Feature Name]. Pick up where you left off."
The result
Six weeks after shipping these three changes — no campaign, no email sequence, no banner — adoption moved from 23% to 61%.
Total engineering effort: one sprint, primarily frontend. No backend changes. No new features.
The lesson isn't that marketing is useless — it's that marketing can't fix a product problem. If users find the feature, try it, and experience friction before getting to value, more awareness just means more users who find the feature, try it, and hit the same friction.
Fix the product first. Then tell people about it.
How to tell if you have an awareness problem vs. a friction problem
Ask one question: what percentage of users who find the feature complete the first meaningful action?
If fewer than 50% of users who find the feature complete the first action, you have a friction problem. The funnel is leaking.
If more than 50% complete the first action but total adoption is still low, *then* you have an awareness problem — and a campaign makes sense.
In our case, 81% of users who found the feature clicked into it. The problem was never awareness. Sending an email to 300K users to tell them the feature existed would have moved us from 23% to maybe 28%, because we'd have pushed more users into a funnel that was already leaking.
The audit took two weeks. The fix took one sprint. The result held.
That's the whole thing.