Adoption and churn are usually treated as two problems with two owners. They are one problem observed at two moments. Almost nobody cancels because of something that happened last week — they cancel because the product never became something they would notice the absence of, and that was decided months earlier, often in the first session.
Which means the churn work and the adoption work are the same work, done early. The question is not how to keep people, but whether the product ever became load-bearing in anyone’s week.
The short version
- Churn at month nine was usually decided in week one. Fix adoption and churn stops being a separate project.
- The target is not activation. It is whether someone’s work now depends on the product.
- Design the first real outcome, not a tour. A tour teaches the interface; an outcome creates a reason to return.
- Get the user’s own data in during the first session. Nothing else creates attachment as quickly.
- Returning requires an external trigger tied to a real event, not a nudge on a schedule.
- Single-player, single-seat accounts churn. Spread is the strongest retention mechanism you have.
Why better onboarding is rarely the lever
When adoption is poor, the standard response is to improve onboarding, which in practice means adding a product tour, a checklist and some tooltips. These are usually neutral and occasionally harmful, because they teach the interface rather than produce an outcome. Someone can complete every step of a tour, tick every box on a checklist, and still have no reason to open the product again on Thursday.
The distinction worth holding is between activation — one person did one thing once — and embedding, where their work now routes through the product. Activation is easy to instrument and easy to improve, which is why teams optimise it. Embedding is what the renewal actually depends on.
The clean test for embedding: if the product vanished tonight, would this person notice tomorrow, and what would they have to do instead? If the honest answer is “they would carry on as normal”, nothing about the checklist is going to help.
If the product disappeared tonight, would they notice tomorrow? That question predicts renewal better than any activation metric.
Four windows, four different failures
They never reached a real outcome
The single most common failure, and the most expensive, because everything downstream depends on it. The person arrives with a problem, meets a setup wizard, a tour and an empty dashboard, and leaves having experienced your interface rather than your value.
A real outcome means something they would have wanted even if your product did not exist: a report produced, an invoice sent, a conflict found, a question answered. With their data, not sample data — sample data demonstrates the product, your own data proves it. The fastest route to that outcome usually involves importing, connecting or pasting something in the first two minutes.
Instrument: share of new accounts reaching a defined first outcome, and the median time to it. If you cannot name the outcome, that is the finding.Nothing brought them back
Returning is not a motivation problem. It is a trigger problem. Products that embed have an external event that pulls the person in — something happened, someone commented, the threshold was crossed, the week ended and the report is ready.
Scheduled nudges unrelated to real events get muted quickly and are close to irreversible once they are. The useful trigger refers to something that actually changed in their data, which means designing the trigger and the underlying event together rather than bolting notifications on afterwards.
Instrument: return rate within seven days, split by whether a real-event trigger fired. The gap between those two groups is the value of your trigger design.Nothing accumulated, so leaving stays free
By week four an embedded account has something inside it that did not exist before: data, history, saved views, templates, configurations, a workflow shaped to their team. A non-embedded account is as empty as it was on day one, and the cost of walking away is zero.
This is switching cost built honestly — not by making export difficult, but by making the thing inside genuinely worth keeping. The design question is what the product should accumulate on the user’s behalf, and whether it does so automatically or only if someone remembers to configure it.
Instrument: share of month-old accounts with saved artefacts of any kind. It predicts renewal better than login counts.It stayed with one person
Single-seat accounts churn when that person changes role, goes on leave, or simply gets busy. An account where four people depend on the product survives any one of them leaving, and the renewal conversation stops being a referendum on one champion’s enthusiasm.
Spread is designed, not hoped for. It comes from moments where involving someone else is the natural next step — sharing a result, requesting an approval, assigning something, handing over a draft. If every path in your product can be completed alone, every account will be single-player by default.
Instrument: active users per account at day 90, and the share of accounts still on one seat. The second number is a churn forecast.Where are you losing them?
Set when accounts go quiet, what kind of product you are running, and whether you can name the first real outcome. That last input decides more than the other two.
Adoption diagnostic
Three inputs, one mechanism to work on, and what to instrument to know if it worked.
When do accounts go quiet?
What kind of product is it?
Can you name the first real outcome?
Three inputs, one mechanism
Pick when accounts go quiet, the kind of product, and whether the first outcome is named.
The mechanism to build
—
What to instrument
—
0 of 3 chosen
Eight practices that move the numbers
Each of these is a mechanism rather than a tactic, which is why the middle column matters more than the first.
| Practice | Why it works | Measure |
|---|---|---|
| Make the empty state the onboarding | The empty state is the most-seen screen in a new account. Putting the first action there removes a layer rather than adding one, and it works for people who dismissed the tour. | First-outcome rate for users who skipped onboarding. |
| Import or connect in the first two minutes | Their own data converts a demonstration into proof, and simultaneously creates the first thing worth keeping. | Share of new accounts with imported or connected data on day one. |
| Defer configuration | Setup wizards ask for decisions before the person has enough context to make them. Sensible defaults now, configuration when the need appears. | Drop-off within setup, and the share who later change the default. |
| Trigger on real events | An event in their data earns attention. A scheduled nudge spends it, and mutes are close to permanent. | Return rate by trigger type, and cumulative mute rate. |
| Accumulate something automatically | Saved views, history and templates create honest switching cost. Automatic accumulation reaches people who never configure anything. | Accounts holding saved artefacts at day 30. |
| Design the invite moment | Spread happens at specific points — sharing a result, asking for approval, handing over. If no path requires a second person, none will involve one. | Active users per account at day 90. |
| Surface progress, not usage | “You have cleared forty items this month” reinforces the value. “You logged in twelve times” reinforces nothing. | Engagement with the summary, and retention of those who see it. |
| Make leaving easy | Friction converts a neutral departure into a detractor and often into a chargeback. An easy exit keeps the door open for return, which is a real revenue line. | Chargebacks, support contacts at cancellation, and reactivation rate. |
Two of these pull against instincts that are common in SaaS teams. Deferring configuration feels like leaving the product underpowered, and making leaving easy feels like giving up revenue. Both trade a visible short-term number for a larger and slower one, which is exactly the kind of trade that loses arguments unless the slower number is being measured. If you only instrument one thing from this article, instrument the lagging side of these two.
Instrumenting load-bearing
Most SaaS dashboards measure presence: logins, sessions, monthly active users. Presence is a weak proxy, because a person can be present and entirely unreliant on you. Four measures get closer to the thing that actually predicts renewal.
Depth per session. Not how often, but how much is done when they arrive. Declining depth over a quarter is one of the earliest honest churn signals available, and it usually appears months before login frequency drops.
Breadth of people. Active users per account, and the share of accounts still on one seat. A single-seat account is a forecast, not a status.
Accumulated artefacts. What exists inside the account that did not exist at signup. Empty accounts leave cheaply, whatever their login count says.
Recovery behaviour. What happens after an error or a failed task. Accounts that hit a problem and never return to that area have quietly written off a feature, and nobody logged a ticket about it.
Where this goes wrong
| Failure | Looks like | Prevention |
|---|---|---|
| Tour instead of outcome | A polished walkthrough and no reason to return on Thursday | Define the first real outcome and route the first session straight to it. |
| Sample data in onboarding | A beautiful demo account that proves nothing about their work | Import, connect or paste their own data in the first two minutes. |
| Setup before context | Eleven configuration questions asked before anyone knows what they mean | Defaults now, configuration when the need actually appears. |
| Nudges instead of triggers | Scheduled emails, rising mute rate, falling opens | Trigger on events in their data, and treat the first mute as a failure. |
| Measuring presence | Monthly active users rising while depth per session falls | Track depth, breadth, accumulation and recovery instead. |
| Single-player by design | Every path completable alone, every account on one seat | Design explicit moments where involving someone else is the next step. |
| Retention work starting at renewal | A save campaign ninety days before the date | The decisive window was week one. Spend there instead. |
| Friction as a retention strategy | Churn improves, chargebacks and detraction rise | Make leaving easy and measure reactivation as revenue. |
Where to start this month
Write down, in one sentence, what the first real outcome is for a new user — the thing they would have wanted even if your product did not exist. Then measure what share of new accounts reach it and how long it takes. Most teams discover two things in that exercise: that different people in the company would have written different sentences, and that the median time is considerably longer than anyone assumed.
Then take one cohort from three months ago and sort it by whether anything accumulated in the account. Compare renewal across the two groups. That single comparison usually settles more internal argument than a quarter of advocacy, because it makes the connection between the first week and the ninth month visible in a way a dashboard of monthly active users never will.
How we work at Adi Design. On SaaS engagements we define the first real outcome before touching onboarding, design the trigger and the underlying event together, and instrument depth, breadth and accumulation rather than logins. If your activation numbers look healthy and renewals do not, get in touch.
