marketing-skill/skills/onboarding-cro/SKILL.md
When the user wants to optimize post-signup onboarding, user activation, first-run experience, or time-to-value. Also use when the user mentions "onboarding flow," "activation rate," "user activation," "first-run experience," "empty states," "onboarding checklist," "aha moment," or "new user experience." For signup/registration optimization, see signup-flow-cro. For ongoing email sequences, see email-sequence.
npx skillsauth add alirezarezvani/claude-skills onboarding-croInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You are an expert in user onboarding and activation. Your goal is to help users reach their "aha moment" as quickly as possible and establish habits that lead to long-term retention.
Check for product marketing context first:
If .claude/product-marketing-context.md exists, read it before asking questions. Use that context and only ask for information not already covered or specific to this task.
Before providing recommendations, understand:
Remove every step between signup and experiencing core value.
Focus first session on one successful outcome. Save advanced features for later.
Interactive > Tutorial. Doing the thing > Learning about the thing.
Show advancement. Celebrate completions. Make the path visible.
The action that correlates most strongly with retention:
Examples by product type:
| Approach | Best For | Risk | |----------|----------|------| | Product-first | Simple products, B2C, mobile | Blank slate overwhelm | | Guided setup | Products needing personalization | Adds friction before value | | Value-first | Products with demo data | May not feel "real" |
Whatever you choose:
When to use:
Best practices:
Empty states are onboarding opportunities, not dead ends.
Good empty state:
When to use: Complex UI, features that aren't self-evident, power features users might miss
Best practices:
Trigger-based emails:
Email should:
Define "stalled" criteria (X days inactive, incomplete setup)
| Metric | Description | |--------|-------------| | Activation rate | % reaching activation event | | Time to activation | How long to first value | | Onboarding completion | % completing setup | | Day 1/7/30 retention | Return rate by timeframe |
Track drop-off at each step:
Signup → Step 1 → Step 2 → Activation → Retention
100% 80% 60% 40% 25%
Identify biggest drops and focus there.
For each issue: Finding → Impact → Recommendation → Priority
| Product Type | Key Steps | |--------------|-----------| | B2B SaaS | Setup wizard → First value action → Team invite → Deep setup | | Marketplace | Complete profile → Browse → First transaction → Repeat loop | | Mobile App | Permissions → Quick win → Push setup → Habit loop | | Content Platform | Follow/customize → Consume → Create → Engage |
When recommending experiments, consider tests for:
Deliver recommendations following the output quality standard: lead with the highest-leverage finding, provide a clear activation definition, then prioritize experiments by expected impact. Avoid vague advice — every recommendation should name a specific onboarding step, metric, or trigger. When writing onboarding copy or flows, ensure tone matches the product's brand voice (load marketing-context if available).
| Artifact | Description | |----------|-------------| | Activation Definition Doc | Clearly defined aha moment, correlated action, and success metric | | Onboarding Flow Diagram | Step-by-step post-signup flow with drop-off points and decision branches | | Checklist Copy | 3–7 onboarding checklist items ordered by value, with completion messaging | | Email Trigger Map | Trigger conditions, timing, and goals for each onboarding email in the sequence | | Experiment Backlog | Prioritized A/B test ideas for onboarding steps, sorted by expected impact |
tools
Code review automation for TypeScript, JavaScript, Python, Go, Swift, Kotlin, C#, .NET, Java, C, C++, Rust, Ruby, PHP, and Dart/Flutter. Analyzes PRs for complexity and risk, checks code quality for SOLID violations and code smells, generates review reports. Use when reviewing pull requests, analyzing code quality, identifying issues, generating review checklists.
tools
Use when planning, funding, scoping, or synthesizing enterprise research across workstreams — clinical study design, R&D program finance, market sizing/surveys, or product/user research. Triggers on "design this clinical study", "what sample size", "R&D budget", "burn rate", "capitalize or expense", "TAM SAM SOM", "market sizing", "survey design", "segment the market", "plan user interviews", "usability test", "synthesize research insights". Forks context to route to one of four Research-Operations sub-skills (clinical-research, research-finance, market-research, product-research) and returns a digest. Distinct from ra-qm-team (regulatory submission), finance (corporate close/valuation), research/grants (funding discovery), product-team (persona/journey/live experiments), and marketing-skill (campaign analytics).
development
Use when managing the money for an internal R&D program or portfolio — building a multi-period program budget with the F&A (indirect) split, tracking burn rate and runway against value-inflection milestones, or routing R&D cost items to a capitalize-vs-expense determination. Every budget output surfaces its assumptions block; capitalize-vs-expense is decision-support only and routes to a named finance owner — it never books an entry or decides accounting treatment. Distinct from finance/financial-analysis (corporate DCF, close, valuation) and research/grants (funding discovery — this manages money already won).
development
Use when planning and synthesizing product/user research as a method-and-repository discipline — selecting the right method for the goal (generative interviews vs usability test vs concept test vs validation), computing method-based saturation/sample size with an explicit confidence level, or synthesizing coded observations into insights while flagging single-source anecdotes. Never fabricates user insight; an insight requires recurrence across independent participants. Distinct from product-team/ux-researcher-designer (persona/journey artifacts), product-discovery (discovery-sprint planning), and experiment-designer (live A/B) — this is the research-ops method + insight-repository layer.