User Activation vs Retention: Diagnose the Right Problem

Your dashboard says users come, use the product a little, and never return, so the roadmap fills up with retention work: win-back emails, streaks, re-engagement pushes. Before you fund any of it, check one thing, because there is a good chance you are not looking at a retention problem at all but at a user activation problem wearing its clothes.

I recently sat down with a founding product designer at a consumer calling app, four years in, who built the product from day one. Her team spent a long time certain they had a retention problem. Then they opened the data, and the diagnosis fell apart in the most useful way possible.

How do you know it's a user activation problem, not retention?

Look at whether new users ever succeed at the core action once, before you measure whether they come back. Retention math only means something for users who reached value at least one time; everyone else is an activation case, whatever your churn chart says.

Her team's numbers made the distinction impossible to ignore. At the consumer calling app whose founding product designer I recently sat down with, only about 20% of new users ever reached the value moment the team had defined, roughly $10 of usage (five to seven minutes of calls), and that small group accounted for about 85% of all the revenue the company had ever made. The other 80% were not "churned users" to win back. Most of them had never experienced the product working even once. Every re-engagement campaign aimed at them would have invited people back to the same wall they already hit.

Before your next retention initiative, split your "churned" cohort by whether each user ever hit your value moment, the milestone growth teams usually call the aha moment. If most never did, you have named the problem wrong, and renaming it will reorder the roadmap more than any single feature.

What does the funnel of a stuck user look like?

It looks like users who try and fail, repeatedly: unanswered outbound calls, missed inbound calls, and daily app opens with zero successes. That is a very different picture from users who lost interest.

In this team's data, 69% of signups placed a call that nobody answered, averaging 2.7 attempts. Another 55% received calls but missed them or didn't pick up, an average of 36 calls per user. And 9% of signups were still opening the app every single day a month after signing up, without one successful call. People who lost interest don't open an app daily for a month. These users wanted the product and could not get through their first success.

The stuck point turned out to be the most obvious step in the flow. A new user signs up, grants contacts and microphone permissions, everything is technically ready, and then the real question lands: who do I actually call? Someone has to answer on the other end, and the caller has to feel comfortable enough to try. Diagnosing a funnel like this, separating "doesn't want it" from "can't get through it", is exactly the discovery muscle I build with product teams in workshops, because almost every team I meet has a wall like this hiding under a churn metric.

Why is removing a decision a feature?

Because the first decision the product asked of a new user, who to call, was the real barrier. So the team made that decision for them. Decision fatigue at the moment of highest uncertainty is a churn machine, and taking the decision away is a shippable fix.

Their answer was a suggestion block on the app's recent-calls screen, replacing what had been a generic empty state. It held a small title reading "Ready when you are", a line offering "Call someone you know, or try a test call with us", three suggested contacts from the user's own address book with a call button next to each, and underneath, a demo call with the app's bot: a safe first call with no human on the other end and no pressure. The block adapts to how many calls the user has already made (none, one to three, four or more) and to whether contacts permission was granted, because without that permission the feature cannot exist.

Just as telling is what they chose not to ship. They considered moving the suggestions into a popup sheet right after signup, so the block wouldn't be "buried" in a secondary screen, and dropped the idea: too pushy, and these are the user's own contacts, reachable anyway. The gentle version fixed the empty state and respected the user in the same move.

When is a simple heuristic better than AI?

When transparency wins: a scoring system you can open, understand, debug, and tune ships faster and fails in ways you can see. The team's most significant decision was what not to build. They did not wait for an AI model that would guess contacts from call data (which regulation ruled out for them anyway). They wrote a plain, additive scoring system for ranking contacts:

They tuned the weights by dogfooding: the team ran the beta and answered one question, "are these people you would actually call?", and the feedback reshaped the scores. The heuristic still hit edge cases after launch, recommending emoji-only names and even surfacing a contact with no phone number. Each failure was visible, explainable, and fixable by adjusting a weight, the kind of bug you can see and correct rather than a model behavior you research for a quarter.

What should you instrument before you ship?

The exact event that proves the feature works, verified end-to-end, because this team lost their measurement window when their dedicated event silently failed. They had done the right thing on paper, defining a purpose-built event on day one to count calls started from the suggestion block. After launch it turned out the event wasn't being collected properly, leaving only about two weeks of usable data. To evaluate the feature at all, they fell back on counting all calls started from the surrounding screen, a proxy that also captures calls the block had nothing to do with.

Do the cheap version of what they learned: in launch week, pull your proving event's data and check it matches reality end-to-end, device to dashboard. A feature you cannot cleanly measure is a feature you will be defending with anecdotes in the next prioritization meeting.

Key takeaways

• Name the problem before you solve it. "Retention" and "user activation" prescribe opposite roadmaps; split churned users by whether they ever reached the value moment to see which one you have.
• Concentration makes activation urgent: at this app, the ~20% of users who activated produced ~85% of all revenue ever.
• Stuck is not the same as gone. Repeated failed attempts and daily opens with zero successes mean the product, not the motivation, is the blocker.
• Removing a decision is a feature. Suggesting who to call, plus a safe practice call, dissolved the first-use barrier better than asking users to choose.
• Transparent beats clever. A debuggable scoring heuristic delivered most of the value now, instead of an AI model later.
• Verify your proving event in week one, or you'll be estimating impact from a proxy.

If your churn dashboard has been funding retention work all year while activation sits unexamined, that is worth a hard look with fresh eyes. Finding the wall your new users actually hit is the kind of work I run with product teams in a hands-on workshop: real funnel, real cohorts, one clearly named problem at the end. Book a workshop conversation and bring your funnel, or start with the discovery guides in our resources.