Introduce a feature the first time it becomes relevant

What it is

Progressive onboarding splits feature teaching and speaks only when that feature first becomes relevant: the person is already in a situation that needs it, and has not yet found the entry. This is not the same strategy as “class then work” in session one—that timing problem is the door. This one is when later capabilities may open their mouths across the product’s life. Relevant does not mean “the feature shipped.” It means the next step of the current task will fail or detour without it. Speaking before that is using someone else’s task slot to sell the catalog.

Why it happens

Relevance supplies a shared context for encoding and retrieval: people are already hunting “get this to someone else,” so a sentence about share binds to the goal. Spoken early, the sentence can only hang on a ledger of “the product can also…,” with no later cue. Relevance also selects: few features sit on the critical path at once, so the task filters the speaking list instead of a release checklist. The failure mode of speaking too soon is not incomprehension but comprehension with no use—working memory reserved for an action that will not happen, after which the sentence is tagged as noise. Speaking too late lets people invent a clumsy path (download, then email); once that path works, the real one is harder to install. “First relevant” is therefore a narrow window: the task already points at the feature, habit has not formed. The window is recognized from behavior, not from days since install.

Studying it

Give new users tasks that will need share, filter, and export; compare “introduce everything at install,” “introduce each feature the first time the task needs it,” and “never introduce.”

Independent variables: offset of the intro relative to the relevance point (early / on time / late), whether copy sits by the feature’s entry. Dependent variables: first successful use of that feature, rate of invented clumsy paths, how fast irrelevant intros are dismissed.

If the lab scripts “relevance” as a fixed nth step, it overstates how easy recognition is. In a live product relevance is probabilistic; false fires (someone merely passed a menu) turn timely intro into random interruption. Code “entered a relevant situation” separately from “paused or failed in it.”

Where it stops holding

Destructive or irreversible capabilities (bulk delete, public sharing) cannot wait for a relevant failure; risk copy must live by the entry. Platform-mandated capabilities (notification permission, payment) have their own system timing; product copy can only attach there, not hunt a “more relevant” day. For experts and migrating users the relevant window already closed in the old product; speaking on the new-user rule treats them as first-timers. Purely cosmetic features (theme color) have almost no task-relevance point; better a discoverable setting than a forced window.

Applying it

• For each planned intro, write which user behavior counts as first-relevant (opened a multi-person object, first selected an exportable set). Intros with no behavior definition must not auto-fire.
• Put the sentence beside the entry that is visible at that moment, naming the current step it solves; do not pull a catalog tour at the relevant instant.
• The window is one chance: if unused then, leave silent copy by the entry rather than hunting “relevant” another day.
• Verify by listing planned triggers and replaying real sessions: were people actually stuck on that step? If false fires outrun useful use, tighten to failure or pause, not “entered a page.”

Related

• Within the group: H2.03.2 Progressive coaching needs a product-wide frequency budget · H2.03.3 Record that a cue was seen and do not replay it
• Adjacent: H2.01 First-use Guidance · H2.05 Feature Discovery · H4.01 Timing of requests
• Search terms: just-in-time feature · first-relevant moment · progressive onboarding