Launch Planning
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]."
Checklist
You MUST create a task for each of these items and complete them in order:
- Define launch goals and success criteria — What does success look like?
- Define target audience and launch segments — Who gets this, and in what order?
- Plan the go-to-market strategy — Pricing, positioning, channels, messaging
- Complete the Pre-Launch Checklist — Everything that must happen before launch
- Design the beta program — Who tests early, how do we collect feedback?
- Choose rollout strategy — Phased? Feature flags? Canary? All at once?
- Complete the Launch Week Checklist — What happens during launch
- Complete the Post-Launch Checklist — Monitoring and iteration after launch
- Define kill criteria — When do we roll back or deprecate?
Step 1: Define Launch Goals and Success Criteria
| 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 |
Step 2: Define Target Audience and Launch Segments
| 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 |
Email |
"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?" |
Step 3: Plan the Go-to-Market Strategy
| 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].
Step 4: Pre-Launch Checklist
4–8 Weeks Before:
1 Week Before:
Step 5: Design the Beta Program
| 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.
Step 6: Choose Rollout Strategy
| 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 |
Step 7: Launch Week Checklist
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.
Step 8: Post-Launch Checklist
| 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? |
Step 9: Define Kill Criteria
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.
Key Principles
- Decouple deployment from release — Use feature flags. Ship code anytime, release when ready.
- Launch is a process, not a moment — Pre-launch starts weeks before. Post-launch continues months.
- Progressive exposure — Start small, monitor, expand. Never 100% at once unless forced.
- Kill criteria before launch — Know what "failure" looks like before you ship.
- War room discipline — During launch, monitoring is someone's full-time job.
- Close the feedback loop — Tell beta users what you changed because of their input.
- Launch retrospective — Always. Every launch. No exceptions.
Common Mistakes
- No defined success metrics ("we'll know it's successful when we see it")
- Launching to 100% on day one without staged rollout
- No rollback plan; analytics not instrumented before launch
- Support team not trained; no war room (everyone assumes someone else is watching)
- Feature flags left in code forever (flag debt)
- Marketing launches before the feature is actually available to users
- Ignoring early feedback; no kill criteria (zombie features accumulate)
Key References
- LaunchDarkly feature management and feature flag best practices
- "Loved" by Martina Lauchengco (product marketing)
- "Obviously Awesome" by April Dunford (product positioning)
- "Product-Led Growth" by Wes Bush
1---2name: launch-planning3description: Use when planning a product or feature launch and preparing go-to-market execution.4---56# Launch Planning78Plan and execute successful product launches using staged rollouts, feature flags, beta programs, and go-to-market strategy.910**Announce at start:** "I'm using the launch-planning skill to plan the launch for [feature/product]."1112## Checklist1314You MUST create a task for each of these items and complete them in order:15161. **Define launch goals and success criteria** — What does success look like?172. **Define target audience and launch segments** — Who gets this, and in what order?183. **Plan the go-to-market strategy** — Pricing, positioning, channels, messaging194. **Complete the Pre-Launch Checklist** — Everything that must happen before launch205. **Design the beta program** — Who tests early, how do we collect feedback?216. **Choose rollout strategy** — Phased? Feature flags? Canary? All at once?227. **Complete the Launch Week Checklist** — What happens during launch238. **Complete the Post-Launch Checklist** — Monitoring and iteration after launch249. **Define kill criteria** — When do we roll back or deprecate?2526## Step 1: Define Launch Goals and Success Criteria2728| Question | Example Answer |29|----------|---------------|30| Primary success metric | Feature adopted by 30% of target users within 30 days |31| Secondary metrics | NPS increases 5 points, support tickets stay below 50/week |32| Counter metrics (guardrails) | Core flow conversion does not decrease, crash rate below 0.1% |33| Evaluation timeframe | 30 days post-launch, with 7/14/30-day checkpoints |3435## Step 2: Define Target Audience and Launch Segments3637| Segment | Who | % of Users | When |38|---------|-----|-----------|------|39| Internal alpha | Company employees | 100% of employees | 4 weeks before launch |40| Closed beta | Invited power users (50) | <1% | 2–3 weeks before launch |41| Phase 1 rollout | New users (low risk) | 5% | Launch day |42| Phase 2 rollout | All users in primary region | 25% | Launch + 3 days |43| Phase 3 rollout | All users | 100% | Launch + 7 days |4445**User communication plan:**4647| Touchpoint | Timing | Channel | Message |48|------------|--------|---------|---------|49| Beta invite | 3 weeks before | Email | "You're invited to try our new..." |50| Coming soon | 1 week before | In-app banner | "A new way to [benefit] is coming" |51| Launch | Launch day | Email, blog, social | "Introducing [feature] — now you can..." |52| Follow-up | Launch + 7 days | In-app tooltip | "Have you tried [feature] yet?" |5354## Step 3: Plan the Go-to-Market Strategy5556| Element | Key Questions |57|---------|--------------|58| **Pricing** | Free? Premium add-on? Included in existing plan? New tier? |59| **Positioning** | How do we describe this against competitors? One-sentence value prop? |60| **Channels** | In-app, email, blog, social, PR, paid ads, events? |61| **Sales enablement** | Do sales teams need training? Pitch decks? Battle cards? |62| **Support readiness** | Is support trained? Help docs ready? Expected ticket volume? |63| **Legal/compliance** | Regulatory approvals? Terms of service updates? Privacy review? |6465**Messaging framework:** For [target audience] who [have this problem], [product/feature] is a [category] that [key benefit]. Unlike [alternatives], our product [unique differentiator].6667## Step 4: Pre-Launch Checklist6869**4–8 Weeks Before:**70- [ ] Launch goals and success metrics defined; target segments identified71- [ ] Messaging and positioning finalized72- [ ] Marketing collateral created: landing page, blog post draft, email sequence, social posts, screenshots/GIFs, help docs and FAQs73- [ ] Sales enablement materials prepared; support team trained74- [ ] Analytics and tracking instrumented; monitoring dashboard created75- [ ] Rollback plan defined and tested; legal/compliance review completed76- [ ] Internal announcement ready; beta program recruitment started7778**1 Week Before:**79- [ ] Feature flags configured and tested; all environments verified (staging, production)80- [ ] Load testing completed; war room schedule set (who's on call)81- [ ] Communication channels set up (Slack, incident response)82- [ ] Final stakeholder sign-off obtained; launch day runbook written8384## Step 5: Design the Beta Program8586| Type | Users | Purpose | Duration |87|------|-------|---------|----------|88| **Internal Alpha** | Company employees | Dogfooding, catch obvious bugs | 1–2 weeks |89| **Closed Beta** | Invited customers (20–200) | Controlled testing, deep feedback | 2–4 weeks |90| **Open Beta** | Anyone who opts in | Scale testing, broad feedback | 2–8 weeks |9192**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.9394**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.9596## Step 6: Choose Rollout Strategy9798| Strategy | How It Works | Best For | Risk |99|----------|-------------|----------|------|100| **Phased/Staged** | 1% → 5% → 25% → 50% → 100% | Most features | Low |101| **Feature Flags** | Toggle on/off per user segment | Everything (recommended) | Lowest |102| **Canary** | Route % of traffic to new version | Backend changes, API updates | Low |103| **Blue-Green** | Switch between two environments | Infrastructure changes | Low |104| **Big Bang** | Everyone at once | Urgent fixes, compliance | High |105106**Feature flag types:** release toggle (who sees it), experiment toggle (A/B test), ops toggle (kill switch), permission toggle (entitlement-based access).107108**Staged rollout schedule:**109110| Phase | % of Users | Duration | Gate |111|-------|-----------|----------|------|112| 1 | 1% | 1–2 hours | Error rate < 0.1%, no critical bugs |113| 2 | 5% | 24 hours | Metrics stable, adoption positive |114| 3 | 25% | 48 hours | Support tickets within range |115| 4 | 50% | 24 hours | All systems nominal |116| 5 | 100% | — | Launch complete |117118## Step 7: Launch Week Checklist119120**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.121122**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.123124## Step 8: Post-Launch Checklist125126| Checkpoint | Verify |127|------------|--------|128| **24-hour** | Error rates normal? Core metrics stable? Support tickets within expected range? |129| **48-hour** | Adoption tracking toward target? User feedback trending positive? Unexpected usage patterns? |130| **1-week** | Which segments adopting fastest? Retention/repeat use healthy? UX issues emerging? |131| **2-week** | Deep dive by persona/plan/region. Interview 5–10 adopters AND 5–10 non-adopters. |132| **30-day retrospective** | Hit primary metric? What surprised us? What would we do differently? What's the next iteration? |133| **90-day health check** | Feature being retained or was it novelty? Driving expected outcomes? Invest more, maintain, or deprecate? |134135## Step 9: Define Kill Criteria136137**Roll back** (immediate) if: error rate exceeds X%, core conversion drops >Y%, data loss/security incident, critical P0 bug affecting >Z% of users.138139**Consider deprecation** if: adoption below X% at 30 days, feature retention below Y% at 60 days, maintenance cost exceeds value, user satisfaction significantly lower.140141## Key Principles142143- **Decouple deployment from release** — Use feature flags. Ship code anytime, release when ready.144- **Launch is a process, not a moment** — Pre-launch starts weeks before. Post-launch continues months.145- **Progressive exposure** — Start small, monitor, expand. Never 100% at once unless forced.146- **Kill criteria before launch** — Know what "failure" looks like before you ship.147- **War room discipline** — During launch, monitoring is someone's full-time job.148- **Close the feedback loop** — Tell beta users what you changed because of their input.149- **Launch retrospective** — Always. Every launch. No exceptions.150151## Common Mistakes152153- No defined success metrics ("we'll know it's successful when we see it")154- Launching to 100% on day one without staged rollout155- No rollback plan; analytics not instrumented before launch156- Support team not trained; no war room (everyone assumes someone else is watching)157- Feature flags left in code forever (flag debt)158- Marketing launches before the feature is actually available to users159- Ignoring early feedback; no kill criteria (zombie features accumulate)160161## Key References162163- LaunchDarkly feature management and feature flag best practices164- "Loved" by Martina Lauchengco (product marketing)165- "Obviously Awesome" by April Dunford (product positioning)166- "Product-Led Growth" by Wes Bush
guhcostan