Menu
Use when planning a product or feature launch and preparing go-to-market execution.
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/guhcostan/product-superpowers --skill launch-planningThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing SKILL.md
Use when analyzing competitors, understanding competitive landscape, conducting SWOT analysis, or positioning your product against alternatives.
Use when setting up or improving a continuous product discovery practice with weekly customer interviews.
Use when preparing design specifications for engineering handoff and quality assurance.
Based on SOC occupation classification
| name | launch-planning |
| description | Use when planning a product or feature launch and preparing go-to-market execution. |
Plan and execute successful product launches using staged rollouts, feature flags, beta programs, and go-to-market strategy.
Announce at start: "I'm using the launch-planning skill to plan the launch for [feature/product]."
You MUST create a task for each of these items and complete them in order:
| Question | Example Answer |
|---|---|
| Primary success metric | Feature adopted by 30% of target users within 30 days |
| Secondary metrics | NPS increases 5 points, support tickets stay below 50/week |
| Counter metrics (guardrails) | Core flow conversion does not decrease, crash rate below 0.1% |
| Evaluation timeframe | 30 days post-launch, with 7/14/30-day checkpoints |
| Segment | Who | % of Users | When |
|---|---|---|---|
| Internal alpha | Company employees | 100% of employees | 4 weeks before launch |
| Closed beta | Invited power users (50) | <1% | 2–3 weeks before launch |
| Phase 1 rollout | New users (low risk) | 5% | Launch day |
| Phase 2 rollout | All users in primary region | 25% | Launch + 3 days |
| Phase 3 rollout | All users | 100% | Launch + 7 days |
User communication plan:
| Touchpoint | Timing | Channel | Message |
|---|---|---|---|
| Beta invite | 3 weeks before | "You're invited to try our new..." | |
| Coming soon | 1 week before | In-app banner | "A new way to [benefit] is coming" |
| Launch | Launch day | Email, blog, social | "Introducing [feature] — now you can..." |
| Follow-up | Launch + 7 days | In-app tooltip | "Have you tried [feature] yet?" |
| Element | Key Questions |
|---|---|
| Pricing | Free? Premium add-on? Included in existing plan? New tier? |
| Positioning | How do we describe this against competitors? One-sentence value prop? |
| Channels | In-app, email, blog, social, PR, paid ads, events? |
| Sales enablement | Do sales teams need training? Pitch decks? Battle cards? |
| Support readiness | Is support trained? Help docs ready? Expected ticket volume? |
| Legal/compliance | Regulatory approvals? Terms of service updates? Privacy review? |
Messaging framework: For [target audience] who [have this problem], [product/feature] is a [category] that [key benefit]. Unlike [alternatives], our product [unique differentiator].
4–8 Weeks Before:
1 Week Before:
| Type | Users | Purpose | Duration |
|---|---|---|---|
| Internal Alpha | Company employees | Dogfooding, catch obvious bugs | 1–2 weeks |
| Closed Beta | Invited customers (20–200) | Controlled testing, deep feedback | 2–4 weeks |
| Open Beta | Anyone who opts in | Scale testing, broad feedback | 2–8 weeks |
Feedback collection: in-app widget, NPS/CSAT surveys after key actions, 5–10 beta user interviews, analytics on actual behavior. Triage feedback as bug / UX issue / feature request / confusion.
Beta success criteria: X% of beta users try the feature, Y% continue using it after first try, critical bugs resolved, NPS at or above product average, support load within expected range, no showstopper issues.
| Strategy | How It Works | Best For | Risk |
|---|---|---|---|
| Phased/Staged | 1% → 5% → 25% → 50% → 100% | Most features | Low |
| Feature Flags | Toggle on/off per user segment | Everything (recommended) | Lowest |
| Canary | Route % of traffic to new version | Backend changes, API updates | Low |
| Blue-Green | Switch between two environments | Infrastructure changes | Low |
| Big Bang | Everyone at once | Urgent fixes, compliance | High |
Feature flag types: release toggle (who sees it), experiment toggle (A/B test), ops toggle (kill switch), permission toggle (entitlement-based access).
Staged rollout schedule:
| Phase | % of Users | Duration | Gate |
|---|---|---|---|
| 1 | 1% | 1–2 hours | Error rate < 0.1%, no critical bugs |
| 2 | 5% | 24 hours | Metrics stable, adoption positive |
| 3 | 25% | 48 hours | Support tickets within range |
| 4 | 50% | 24 hours | All systems nominal |
| 5 | 100% | — | Launch complete |
Launch Day: Deploy to production (or flip feature flags). Activate marketing: announcement email, blog post, social media, in-app messaging. War room active (monitor metrics, errors, support). Internal announcement sent. Sales/support notified.
Launch Week: Daily standup with launch team. Monitor dashboards continuously first 48 hours. Triage incoming bugs and feedback. Fix critical issues immediately. Adjust messaging if adoption is low. Escalate blockers to leadership.
| Checkpoint | Verify |
|---|---|
| 24-hour | Error rates normal? Core metrics stable? Support tickets within expected range? |
| 48-hour | Adoption tracking toward target? User feedback trending positive? Unexpected usage patterns? |
| 1-week | Which segments adopting fastest? Retention/repeat use healthy? UX issues emerging? |
| 2-week | Deep dive by persona/plan/region. Interview 5–10 adopters AND 5–10 non-adopters. |
| 30-day retrospective | Hit primary metric? What surprised us? What would we do differently? What's the next iteration? |
| 90-day health check | Feature being retained or was it novelty? Driving expected outcomes? Invest more, maintain, or deprecate? |
Roll back (immediate) if: error rate exceeds X%, core conversion drops >Y%, data loss/security incident, critical P0 bug affecting >Z% of users.
Consider deprecation if: adoption below X% at 30 days, feature retention below Y% at 60 days, maintenance cost exceeds value, user satisfaction significantly lower.
