ENGAGE

[drop_cap]N[/drop_cap]othing you send matters until they have seen the product work once. A signup is not a customer. It’s a person who has, at most, granted you an email address and ninety seconds of attention, and the only thing that converts that grant into something durable is the product itself doing the one thing it was built to do, in front of them, before they close the tab.

This is Stage 4 of the Convert band, and it is the stage most SaaS teams skip, because it looks like a product problem rather than a marketing problem. It isn’t. Onboarding is the highest-leverage marketing you will ever do, and most of it happens with no marketer in the room.

Activation Is Not a Feeling, It’s an Event

Every team that has ever shipped a product has an opinion about when a user “gets it.” Almost none of them have looked at their own data to check. The opinion is usually wrong, or at least too vague to build anything on top of — “engaged,” “onboarded,” “activated” are words, not events, and you cannot write a day-1 email that fires off a word.

An activation event is a single, specific, loggable action: created a project, invited a teammate, connected an integration, sent the first message, imported the first file. Not a session count, not a login streak — one thing a user does inside the product that correlates with staying. Find it by pulling the accounts that are still paying at day 90 and asking what almost all of them did in their first week that the accounts who churned did not. It is rarely the action product intuition guesses. It is often something small and specific — not “used the dashboard” but “connected their first data source,” not “explored the app” but “invited a second seat.”

Write it down as a sentence you could hand to an engineer to log:

Activation = account has ≥1 [specific object] created
             AND ≥1 [specific action] completed
             within [X] days of signup

Fill in your own object, your own action, your own window. Until this sentence exists and something in your stack can answer “yes” or “no” for a given account, every other section in this chapter is guessing.

Time-to-First-Value, Measured Honestly

Time-to-first-value is the gap between signup and the activation event — and it is worth measuring with more suspicion than most teams bring to it. The number product teams report is usually the time from signup to the first screen that could show value, not the time to the moment a real user actually reached it. Those are different numbers, and the gap between them is where most trial accounts quietly die.

Pull the real distribution, not the average. A median time-to-first-value of ten minutes with a long tail stretching to three days tells you something an average alone hides: most people either get there fast or never get there at all. That shape — fast or never — is the normal shape, and it means the fix is rarely “make the fast path faster.” It’s closing the gap for the users currently in “never.”

State your own number and treat it as a target, not a boast: X minutes to first value for the median account, measured from the timestamp of signup to the timestamp of the activation event, re-measured every time onboarding changes — not assumed to have improved because the onboarding flow got prettier.

The Empty State Is Where Trials Go to Die

A brand-new account looking at an empty dashboard is not looking at a blank canvas full of possibility. It’s looking at a wall. Nothing to click that leads anywhere interesting, no proof the product does what the homepage said it does, and every next action requires the user to already know what they’re doing — which is exactly the thing they signed up to find out.

There are three honest ways out of an empty state, and most products need at least one of them:

Sample data. Load the account with realistic, clearly-labeled example content — a demo project, a populated dashboard, a sample workspace — so the first thing a new user sees is the product working, not the product waiting. The tradeoff: sample data that never gets replaced with real data is its own failure mode, so pair it with a visible, one-click “start fresh” or a nudge that appears once the user has looked at the sample long enough to understand it.

Import. If the user already has data living somewhere else — a spreadsheet, a competitor’s export, a CSV of contacts — let the product’s value show up against their data on the first screen, not a hypothetical. This is usually the highest-converting of the three because it collapses time-to-first-value to the length of the import itself.

A guided first object. Walk the user through creating one real, specific thing — not a tour of the interface, a completed task. “Watch me click five buttons” teaches nothing; “here is the one project you now own” does. The guided path should end at the activation event itself, not near it.

Pick based on what your product actually needs to demonstrate value: a tool that analyzes existing data wants import, a tool that’s better understood by using it wants a guided first object, a tool whose value is in seeing a fully-populated state wants sample data. Some products need two of the three.

The Onboarding Checklist as a Commitment Device

A checklist works for a reason that has nothing to do with gamification: each ticked box is a small, self-administered proof that the user is making progress, and an unticked box sitting at 80% complete pulls at a mind more than a blank slate ever could. Build the checklist around the same handful of actions that make up your activation event — not a padded list of ten items where six are busywork, but three to five steps where completing all of them is activation.

[ ] Create your first [object]
[ ] Invite a teammate  (or: connect your first integration)
[ ] Complete your first [core action]
[ ] Set your [notification / preference] (optional, not gating)

Order matters: put the step most likely to be abandoned first, while motivation is highest, not last. And once every gating box is checked, take the checklist off the screen. A checklist that lingers after activation stops being a commitment device and starts being clutter that quietly tells an active user the product still thinks they’re new.

The Messages: Tied to State, Never to the Calendar

Once the activation event is defined, the messaging becomes almost mechanical — which is the point. Every message in this stage answers one question: has this account reached its activation event yet, or hasn’t it? A day-3 email that fires at a user who activated on day 1 isn’t a follow-up, it’s noise that teaches the recipient to stop opening your emails.

The state column is the entire design. A user who activates on day 2 should never receive the day-3 email — they’ve already done the thing the email exists to encourage, and asking again reads as either not paying attention or not caring. Wire the send to a check against the activation event, not to a countdown timer that started at signup.

The One Human Touch Worth Its Cost

Somewhere in this sequence — usually around the day-3 mark, for accounts that look promising by usage but haven’t crossed the line — a real message from a real person outperforms every automated one, and it’s worth knowing when that’s true rather than trying to automate everything. “Promising by usage” means a specific, checkable signal: logged in more than once, created something but didn’t finish it, invited a teammate who hasn’t joined yet — evidence of intent without evidence of completion.

The message that works is short, references something true and specific about that account (not a merge-tag first name — an actual observed behavior), and asks one real question: what got in the way? It is not a scripted “just checking in” — those read as automated even when a human sent them, because they carry no information the sender could only have if they’d actually looked. Reserve this touch for accounts worth the time: a defined ICP fit, a plan tier that justifies the effort, or a usage pattern specific enough that a generic template can’t answer it.

Sending to an Activated User Is How You Teach Them to Ignore You

State this plainly because it is the most common way this stage gets undone: a nurture sequence built for someone who hasn’t activated yet, sent to someone who has, does not read as thorough. It reads as a company that isn’t paying attention to its own customer. The first time that happens, the recipient learns something durable — that your emails are worth skimming, not reading — and every message after that, including the ones that matter, inherits the discount.

The fix isn’t fewer emails. It’s a gate: every scheduled send in this stage checks the activation event first and stops the sequence the moment it fires. That one check is the difference between a nudge sequence that respects the person receiving it and a drip that broadcasts regardless of who’s listening.

AI Earns Its Place Here

Drafting the day-1 / day-3 / day-7 messages, and the in-product nudge copy for each step of the checklist, is exactly the kind of structured writing a model handles well — once you feed it the real inputs instead of asking it to invent them. Give the tutor your defined activation event, your actual checklist steps in order, and the one proof point or short customer line you’d want a hesitant user to see, and ask for the full message set: the immediate in-app nudge, the three emails, and a short-form version of each for a chat or SMS channel.

Ask it, too, to draft the human-touch message for a promising-but-unactivated account, fed the specific signal that account showed — not a generic “checking in,” a message that names what was actually observed. Read every draft the way a stressed, half-attentive new user would: does the first line make the next step obvious, or does it require them to already understand the product? Cut anything that describes a feature instead of pointing at an action, and verify the state logic yourself — that each message is wired to stop the moment the activation event fires, not to a clock that started at signup. The model can draft the whole sequence in minutes. Confirming that it fires on the right event, and stops on the right one, is still your job.