Implementation worksheet · 6 min read
A next-quarter in-app activation roadmap template
Start from one activation goal defined as an event, write down what this quarter's experiments and reviews actually showed, and fill the quarter with at most three bets. Each bet names the evidence behind it, the metric it should move, the engineering dependency it needs and the date it will be judged. Reserve capacity for maintenance (broken targets, library updates, accessibility fixes) before adding new flows, and write a stop list of guidance you'll retire. A roadmap that only adds prompts makes the product noisier every quarter.
In-app activation work tends to grow by accretion: every launch adds a tip and nobody removes one. A quarterly roadmap is the natural point to reverse that. Actor: the product or growth lead who owns activation, with an engineering counterpart. Boundary: in-app guidance for new and early-life users over the next quarter. It sits under the product roadmap and doesn't replace it.
Put it into practice
1. Write the activation goal as an event
One goal, one event definition, the current baseline and the date it was measured. If the team can't agree on the event, stop and settle that; every bet below depends on it.
2. Summarize what this quarter proved and didn't
Pull from the monthly experiment reviews: what shipped, what stopped, what was inconclusive. Inconclusive results don't carry forward as wins, and a null result is information, not a failure to hide.
3. Budget capacity before choosing bets
Reserve maintenance time based on last quarter's actual repair hours, not a hopeful guess. Whatever is left is the capacity for new work, and it's often less than the planning meeting assumes.
4. Pick at most three bets, each with evidence
Evidence might be a teardown score, an experiment result, a support-contact pattern or a time-to-value measurement. A bet without evidence can still go in, labelled as exploratory, with a smaller scope and its own holdout.
5. Map every dependency to engineering's plan
Stable attributes, new events, SDK upgrades, a product change the guidance needs. A bet whose dependency isn't on engineering's plan waits. Guidance that ships ahead of its dependency points at something that isn't there yet.
6. Write the stop list
Guidance with no measured effect, tips pointing at deprecated features, prompts that overlap. Retiring them frees the frequency budget for the bets and removes maintenance, which makes the stop list the cheapest improvement on the page.
7. Set the review dates now
The monthly review dates, and the judge date for each bet. When the quarter gets busy, the reviews that weren't booked are the ones that get skipped.
Quarterly activation roadmap
Copy this structure into your review document and record your observed result for each row.
| Item | Evidence or reason | Metric and judge date | Dependency |
|---|---|---|---|
| Goal: first shared project within 7 days | Baseline 31% as of 30 September (illustrative) | Reviewed 31 December | Event already instrumented |
| Bet 1: import step in the setup checklist | Teardown found import was the main delay | 7-day activation; judged 15 November | Import event needs a success flag |
| Bet 2: invite prompt after the first project | Shared projects need a second person; invites lag | Invites within 7 days; judged 30 November | Stable attribute on the invite button |
| Bet 3: shorter checklist on mobile | September review: shorter checklist won on web (+1.4 points, illustrative) | Mobile 7-day activation; judged 15 December | Mobile SDK upgrade |
| Maintenance reserve | Last quarter's actual repair hours | Hours used vs reserved, monthly | Engineer time agreed |
| Library consolidation | Two AGPL-3.0 tour libraries still in use | Retired by mid-quarter | Licence review with counsel |
| Stop: three tips for retired reports | Point at deprecated features | Removed in week 1 | No dependency |
| Stop: onboarding quiz | No measured effect in two reviews | Removed; frequency budget freed | No dependency |
| Monthly reviews | Fixed agenda, same order every month | Last working day of each month | Analyst time booked |
A failure worth checking
The roadmap that only adds. Each bet is reasonable, each launch adds a prompt, and by the end of the quarter a new user meets a tour, a checklist, two tips, a survey and an announcement in the first ten minutes. Activation doesn't move, and the retrospective blames the latest bet. The stop list and the frequency budget are part of the roadmap, not a clean-up for later.
Common questions
Why at most three bets?
Each needs a holdout, a review and engineering time, and a small team running more than three measured experiments at once often can't read any of them cleanly. Three is a planning default, not a law; raise it if your traffic and team can support more.
How does this relate to the product roadmap?
It's a slice of it. Bets that need product changes, not just guidance, go onto the product roadmap as dependencies. If guidance keeps compensating for a confusing screen, the better bet is often fixing the screen.
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.