Implementation worksheet · 6 min read
A feature adoption campaign handoff checklist
Before anyone builds an in-app announcement or tour for a new feature, the shipping team hands over, in writing: the feature flag and who has it on, stable selectors for every element the campaign will point at, the eligible audience and who must be excluded, the adoption event and its definition, copy constraints (names, limits, what not to promise), a support briefing, what happens to the campaign if the flag is rolled back, the campaign's end date, and a named owner on each side. Test the handoff with the matrix below before launch. Every failing row is a campaign that will point at something users can't see or promise something the feature doesn't do.
Feature launches cross a seam. Engineering ships behind a flag; a growth or product marketing person announces the feature inside the product. The announcement tool doesn't know the flag state, the selector list, or that enterprise accounts get the feature a month later. This checklist sits on that seam. Actor: the feature's product owner handing over to whoever runs in-app adoption. Boundary: one feature, one in-app campaign (announcement, tour, tooltip or checklist item), from handoff to end date.
Put it into practice
1. Tie campaign eligibility to the flag itself
The campaign's audience rule should read the same flag or entitlement the feature uses, not a hand-built segment that approximates it. A user without the feature must never see the announcement, including during a staged rollout when that audience changes daily.
2. Hand over stable selectors, reviewed by engineering
Every element the campaign points at gets a stable data attribute in the markup and a named engineer who knows the campaign depends on it. Generated class names break at the next refactor, and the campaign breaks silently with them.
3. Define adoption as repeated use, not a first click
A first click measures curiosity, and the announcement itself produces it. Define adoption as the feature used, for instance, twice within 14 days, and log it from the product event, not from the campaign's own click.
4. Write the copy constraints down
What the feature does, its limits, which plans get it, and anything the campaign must not claim. Pricing and plan statements go through whoever owns pricing. The campaign copy should never be the first place a limit is discovered.
5. Brief support before the first impression
What users will see, known limits, likely questions, and how to switch the campaign off for a customer who asks. Support learning about a feature from a ticket is a handoff failure, not a support failure.
6. Agree the rollback path and the end date
If the flag is rolled back, the campaign stops in the same change, not when someone notices. Set an end date at handoff so the announcement doesn't become permanent furniture that keeps drawing on the prompt budget.
7. Test the matrix on staging and one production cohort
Run every row below with test accounts that represent each audience, including one that shouldn't qualify. Record results with the date and keep them with the handoff document.
Handoff test matrix
Copy this structure into your review document and record your observed result for each row.
| Check | Handed over by | Test | Pass condition |
|---|---|---|---|
| Flag-aware audience | Engineering | View as a user with the flag off | No announcement shown |
| Excluded accounts | Product owner | View as an account on an excluded plan | No announcement shown |
| Stable selectors | Engineering | Resolve every target on staging and production | All targets found; none by generated class |
| Adoption event | Product owner | Use the feature twice as a test user | Event fires twice; adoption counted once |
| Copy constraints | Product owner | Compare the copy with the feature's documented limits | No claim beyond shipped behavior |
| Support briefing | Product owner | Support lead confirms receipt | Briefing linked in the help desk |
| Prompt priority | Growth | Check against other live prompts for the same users | Fits the shared frequency budget |
| Flag rollback | Engineering | Turn the flag off in staging | Campaign stops by the next session |
| End date | Growth | Move the test clock past the end date | Campaign no longer eligible |
| Named owners | Both | Check the handoff document | One named person on each side |
A failure worth checking
The announcement for a feature half the audience can't use. The feature ships to Pro accounts first, and the in-app announcement targets all active users because that was the default audience. Free users click 'Try it now', land on an upgrade wall nobody mentioned, and support gets tickets titled 'new feature broken'. Meanwhile the campaign's click-through rate looks healthy, because clicks are exactly what a confusing announcement produces.
Common questions
Who owns the campaign after launch?
Growth owns content, timing and the end date; engineering owns the flag and the selectors. If the feature changes, the product owner tells growth before the campaign's next impression. The handoff document names one person for each, not a team.
How long should an adoption campaign run?
Long enough for eligible users to meet it at a natural moment in their work, short enough that it doesn't become background. Set the end date at handoff, review adoption against it, and extend on purpose rather than by forgetting to switch it off.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.