When a feature is ready to ship, /product-launch-manager builds the launch plan, so you can coordinate every team from one doc. — Claude Skill

---

title: Section Organization

1. Launch Planning (planning)

Impact: CRITICAL Description: Foundational launch decisions — tiering, timelines, success criteria, and strategic alignment. The blueprint for everything that follows.

2. Cross-Functional Coordination (coordination)

Impact: CRITICAL Description: Stakeholder alignment, RACI matrices, and orchestrating multiple teams toward a unified launch. Where most launches fail.

3. Beta & Early Access (beta)

Impact: HIGH Description: Pre-launch validation programs, beta cohort management, and feedback integration. De-risk before you launch.

4. Launch Communications (communication)

Impact: HIGH Description: Internal enablement, external messaging, and multi-channel communication plans. What you say and when you say it.

5. Launch Execution (execution)

Impact: CRITICAL Description: Launch day operations, war rooms, runbooks, and real-time decision making. The moment of truth.

6. Post-Launch Operations (postlaunch)

Impact: HIGH Description: Monitoring, retrospectives, metrics analysis, and iterative improvement. The launch isn't over when it ships.

---

title: Beta and Early Access Programs impact: HIGH tags: beta, early-access, validation, feedback

Beta and Early Access Programs

Impact: HIGH

Beta programs de-risk launches by validating with real users before you announce to the world.

Beta Program Types

Beta Cohort Selection

Ideal Beta Participants:

Good Example: Structured Beta Program

## Beta Program: Workflow Automation

### Program Structure
| Phase | Duration | Cohort Size | Goals |
|-------|----------|-------------|-------|
| Alpha | 2 weeks | 10 users | Core flow validation |
| Closed Beta | 4 weeks | 100 users | Use case coverage |
| Open Beta | 2 weeks | 500 users | Scale + edge cases |

### Cohort Selection Criteria
**Alpha (10 users):**
- Internal power users (5)
- Design partners (3)
- Customer advisory board (2)

**Closed Beta (100 users):**
- Power users from target segment (40)
- Customers who requested feature (30)
- Mix of company sizes (20)
- International users (10)

### Feedback Collection
| Method | Timing | Goal |
|--------|--------|------|
| Kickoff survey | Day 1 | Baseline expectations |
| In-app feedback widget | Continuous | Friction points |
| Weekly survey | End of week | Satisfaction trend |
| User interviews | Week 2, 4 | Deep qualitative |
| Exit survey | Beta end | Overall assessment |

### Success Criteria for GA
- 70% of beta users would be "disappointed" without feature
- < 5% error rate in workflows
- < 3 critical bugs reported
- NPS > 40 from beta cohort
- 3+ validated use cases documented

Bad Example: Unstructured Beta

## Beta Program: New Editor (What Not To Do)

**The Approach:**
- "Let's just ship it to 10% of users"
- No cohort selection criteria
- No feedback mechanism planned
- No success criteria defined
- No timeline or phases

**What Happened:**
- Random users got feature (including churned accounts)
- No feedback received for 2 weeks
- Critical bug discovered by angry customer tweet
- No data to support GA decision
- Launched anyway, 3x support tickets

**Lesson:** Beta without structure isn't beta, it's chaos.

Beta Communication Templates

Invitation Email:

Subject: You're invited: Early access to [Feature]

Hi [Name],

You've been selected for early access to [Feature] -
our new [value prop in one line].

**Why you:**
- You're one of our most engaged [segment] users
- You've [specific behavior that qualified them]

**What you get:**
- Exclusive early access (4 weeks before GA)
- Direct line to product team
- Shape the final product with your feedback

**What we ask:**
- Try the feature within first week
- Complete 2 short surveys (5 min each)
- Report bugs through in-app widget

[Accept Invitation Button]

This beta runs [dates]. Features may change based on feedback.

Weekly Check-in:

Subject: Week [X] Check-in: [Feature] Beta

Hi [Name],

Quick update on the beta:

**This week's improvements:**
- [Improvement based on feedback]
- [Bug fix]

**Your feedback in action:**
- "[Quote from feedback]" → We [action taken]

**This week's ask:**
- Try [specific feature/flow]
- 2-min survey: [link]

Questions? Reply to this email or Slack me directly.

Feedback Collection Framework

Beta Metrics Dashboard

Beta Health Dashboard
═════════════════════

Participation
├── Invited: 100
├── Accepted: 85 (85%)
├── Active (used this week): 62 (73%)
└── Churned from beta: 8 (9%)

Feedback
├── Survey responses: 45 (53%)
├── Bug reports: 23
├── Feature requests: 12
└── Interview volunteers: 18

Quality
├── Critical bugs: 2 (both fixed)
├── Major bugs: 8 (5 fixed)
├── Error rate: 2.3%
└── Performance: 180ms p95

Sentiment
├── NPS: 52
├── "Would be disappointed": 68%
└── Top complaint: "Confusing first setup"

Beta Exit Criteria

GA Decision: APPROVED

Early Access vs. Beta

Anti-Patterns

• Beta as soft launch — No feedback mechanism, just staged rollout
• Too small cohort — 5 users can't find edge cases
• Too large cohort — 1000 users with no feedback structure
• No exit criteria — Beta that never ends
• Ignoring feedback — Collecting data without acting on it
• Random selection — Anyone who raises hand vs. strategic cohort
• No timeline — "We'll see how it goes"
• Beta fatigue — Same users in every beta, burned out

---

title: Internal Enablement for Launches impact: HIGH tags: communication, enablement, sales, support, training

Internal Enablement for Launches

Impact: HIGH

Your internal teams are your first launch audience. If Sales can't explain it and Support can't troubleshoot it, you've already failed.

Enablement Timeline

Sales Enablement Package

Required Materials:

Good Example: Sales One-Pager

# Enterprise SSO - Sales One-Pager

## What It Is
Single Sign-On integration supporting SAML 2.0, OIDC, and
SCIM provisioning for enterprise identity providers.

## Who It's For
- Enterprise companies (500+ employees)
- Security-conscious organizations
- Companies with existing IdP (Okta, Azure AD, etc.)

## Key Value Props
1. **Security compliance** - Meet SOC 2, HIPAA requirements
2. **IT efficiency** - Automated user provisioning/deprovisioning
3. **User experience** - One-click login, no password fatigue

## Discovery Questions
- "How do you currently manage user access across tools?"
- "What's your offboarding process when employees leave?"
- "Are you facing any compliance requirements around access control?"

## Objection Handling
| Objection | Response |
|-----------|----------|
| "Too expensive" | SSO reduces password reset tickets by 40% |
| "We use [competitor]" | We support same IdPs + faster setup |
| "Not a priority" | Security breaches cost avg $4.2M |

## Pricing
- Included in Enterprise plan ($X/user/month)
- Available as add-on for Business plan (+$Y/user/month)

## Demo Environment
- sandbox-sso.company.com
- Credentials: [email protected] / [in 1Password]

Bad Example: No Enablement

## What Happened: Widget 2.0 Launch

**Sales Team Experience:**
- Found out about launch from customer LinkedIn post
- No training provided
- Had to read blog post to understand feature
- Demo environment not set up
- First customer call: "I don't know, let me get back to you"

**Support Team Experience:**
- Received first ticket before documentation existed
- No troubleshooting guide
- Had to reverse-engineer feature from code
- 2-hour average response time (normally 30 min)

**Result:**
- Lost 3 enterprise deals in first week
- Support CSAT dropped 20 points
- Team morale damaged
- Customer trust eroded

Support Enablement Package

Required Materials:

Good Example: Support Troubleshooting Guide

# SSO Troubleshooting Guide

## Common Issues & Resolutions

### Issue: SAML assertion error
**Symptoms:** User sees "Invalid SAML response" on login
**Likely Causes:**
1. Clock skew between IdP and our servers
2. Incorrect assertion consumer URL
3. Certificate mismatch

**Resolution Steps:**
1. Check IdP configuration matches our setup guide
2. Verify assertion URL is `https://app.company.com/sso/callback`
3. Compare certificate thumbprint in Admin > SSO settings
4. If persists, collect SAML trace (instructions below)

**Escalation:** If unresolved after 3 attempts, escalate to
Tier 2 with SAML trace attached.

### Issue: SCIM sync failing
**Symptoms:** Users not provisioning/deprovisioning
**Likely Causes:**
1. SCIM token expired
2. Rate limiting
3. User attribute mapping mismatch

**Resolution Steps:**
1. Verify SCIM token in Admin > Integrations
2. Check our status page for rate limit issues
3. Review attribute mapping in IdP
4. Run manual sync from Admin panel

**Escalation:** If sync queue > 1000 users, escalate to
Engineering with org ID.

Customer Success Enablement

Enablement Delivery Methods

Enablement Certification

For Tier 1/2 launches, consider requiring certification:

Sales Certification Checklist
─────────────────────────────
□ Completed training video (15 min)
□ Passed quiz (80% minimum)
□ Delivered practice demo to manager
□ Reviewed battlecard
□ Shadowed one customer call

Certification valid until: [Date]

Enablement Feedback Loop

Week 1 Post-Launch:
├── "What questions are customers asking?"
├── "What objections are you hearing?"
├── "What's missing from materials?"
└── "What's confusing in documentation?"

Action: Update materials based on feedback

Anti-Patterns

• Launch day enablement — Training the day of launch
• Email-only enablement — No one reads long emails
• No certification — Assuming everyone will self-enable
• One-and-done — No iteration based on feedback
• PMM creates alone — Sales and Support not involved in creation
• Different versions — Sales and Support telling different stories
• No demo environment — "Just describe it to customers"
• Technical-only docs — No business context for Sales

---

title: External Launch Communications impact: HIGH tags: communication, messaging, pr, marketing

External Launch Communications

Impact: HIGH

Your launch message reaches customers once. Make it count with clear, compelling communication across all channels.

Message Hierarchy

                ┌─────────────────────┐
                │   POSITIONING       │
                │   (Why we exist)    │
                └──────────┬──────────┘
                           │
                ┌──────────▼──────────┐
                │   KEY MESSAGE       │
                │   (What's new)      │
                └──────────┬──────────┘
                           │
          ┌────────────────┼────────────────┐
          │                │                │
    ┌─────▼─────┐    ┌─────▼─────┐    ┌─────▼─────┐
    │  Proof    │    │  Proof    │    │  Proof    │
    │  Point 1  │    │  Point 2  │    │  Point 3  │
    └───────────┘    └───────────┘    └───────────┘

Channel Strategy by Tier

Messaging Framework

The 3-Part Launch Message:

Good Example: Launch Blog Post

# Introducing Enterprise SSO: Secure Your Team with One-Click Login

Your security team has been asking. Your IT team has been waiting.
Today, we're launching Enterprise SSO - making [Product] as secure
as it is powerful.

## What's New

Enterprise SSO brings:
- **SAML 2.0 & OIDC support** - Works with Okta, Azure AD, OneLogin,
  and any standards-compliant identity provider
- **SCIM provisioning** - Automatically sync users from your IdP
- **Just-in-time provisioning** - New users created on first login

## Why It Matters

[Quote from Security Leader at beta customer]

**For IT teams:** No more manual user management. When someone leaves,
they're automatically deprovisioned. No forgotten accounts, no security gaps.

**For employees:** One click to log in. No more password to remember.
No more "forgot password" flows.

**For security teams:** Audit every login. Enforce MFA through your IdP.
Meet compliance requirements for SOC 2, HIPAA, and more.

## How to Get Started

1. Navigate to Admin > Security > SSO
2. Select your identity provider
3. Follow our step-by-step guide (average setup: 15 minutes)

[CTA Button: Enable SSO Now]

## Pricing

Enterprise SSO is included in our Enterprise plan at no additional cost.
Business plan customers can add SSO for $X/user/month.

## Learn More

- [Documentation: SSO Setup Guide]
- [Webinar: SSO Best Practices (register)]
- [Talk to Sales about Enterprise]

Bad Example: Weak Launch Communication

# New Feature: SSO

We added SSO to our product. You can now use SSO to log in.

SSO stands for Single Sign-On. It lets you log in with your
company credentials.

To use it, go to settings and turn it on.

Thanks,
The Team

**Why This Fails:**
- No value proposition
- No differentiation
- No specific capabilities mentioned
- No social proof
- Weak CTA
- Forgettable

Email Campaign Structure

Tier 1 Launch Email Sequence:

Social Media Launch Plan

LinkedIn (B2B focus):

Post 1 (Launch day, 8am):
[Announcement + key visual]
"Today we're launching Enterprise SSO..."

Post 2 (Launch day, 2pm):
[Founder perspective]
"Why we built SSO: [personal story]..."

Post 3 (Day 2):
[Customer quote card]
"[Quote from beta customer]..."

Post 4 (Day 3):
[How-to carousel]
"Set up SSO in 4 steps..."

Twitter/X (Tech community):

Thread (Launch day):
1/ Big news: Enterprise SSO is live

Here's what's included:
- SAML 2.0 & OIDC
- SCIM provisioning
- All major IdPs supported

2/ The best part? Setup takes 15 minutes.

We worked with 50 beta customers to make configuration dead simple.

3/ [Screenshot of setup flow]

4/ Available now for Enterprise customers.
Business customers can add it for $X/user/mo.

Link: [launch blog]

Press Release Structure

FOR IMMEDIATE RELEASE

# [Company] Launches Enterprise SSO, Enabling Secure
# One-Click Access for Organizations

[City, Date] - [Company], the leading [category], today
announced the launch of Enterprise Single Sign-On (SSO),
enabling organizations to [key benefit].

## Key capabilities include:
- [Capability 1]
- [Capability 2]
- [Capability 3]

"[Quote from company executive about why this matters]"
- [Name], [Title], [Company]

## Customer validation
"[Quote from beta customer about value]"
- [Name], [Title], [Customer Company]

## Availability
[Pricing and availability details]

## About [Company]
[Boilerplate]

## Media Contact
[Contact info]

Communication Timing

Anti-Patterns

• Jargon-heavy — "Leveraging synergies" instead of clear benefits
• Feature-first — Leading with what, not why
• No CTA — Announcement without action
• One channel — Blog only, no distribution
• Bad timing — Friday afternoon or holiday launch
• No visuals — Text-only announcements
• Inconsistent message — Different story on each channel
• Premature PR — Press release for Tier 3 feature

---

title: Cross-Functional Launch Coordination impact: CRITICAL tags: coordination, stakeholders, raci, alignment

Cross-Functional Launch Coordination

Impact: CRITICAL

Launches fail at the seams between teams. Relentless coordination is the difference between success and chaos.

The Launch Coordination Triad

              ┌─────────────┐
              │   PRODUCT   │
              │  (Captain)  │
              └──────┬──────┘
                     │
         ┌───────────┴───────────┐
         │                       │
    ┌────▼────┐             ┌────▼────┐
    │MARKETING│◄───────────►│ENGINEER │
    │         │             │  -ING   │
    └─────────┘             └─────────┘

Product is the captain, but Marketing and Engineering have veto power on their domains.

RACI Matrix by Launch Phase

Planning Phase (T-8 to T-4 weeks)

Preparation Phase (T-4 to T-1 weeks)

Execution Phase (T-1 week to Launch)

R = Responsible, A = Accountable, C = Consulted, I = Informed

Stakeholder Communication Cadence

Good Example: Effective Coordination

## Launch Coordination Plan: Enterprise SSO

### Core Team (Weekly Sync - Thursdays 2pm)
- PM: Sarah Chen (Captain)
- PMM: Mike Rodriguez
- Eng Lead: Priya Patel
- Sales Enablement: Tom Walsh
- Support Lead: Lisa Kim

### Extended Team (Informed via Slack #sso-launch)
- DevRel: James Wu
- Legal: Amanda Foster
- Security: David Park
- CS: Regional leads

### Communication Rhythm
| Cadence | Audience | Channel | Owner |
|---------|----------|---------|-------|
| Daily (T-2 weeks) | Core team | Standup | PM |
| Weekly | Extended team | Slack digest | PM |
| Bi-weekly | Exec sponsors | Email + 15min | PM |
| As needed | All-hands | Slack announcement | PM |

### Decision Rights
| Decision | Who Decides | Who Must Approve |
|----------|-------------|------------------|
| Launch date change | PM | Exec sponsor |
| Scope change | PM + Eng Lead | PM |
| Messaging change | PMM | PM |
| Go/no-go | Core team vote | Exec sponsor |

### Escalation Path
1. Core team member → PM (same day)
2. PM → Exec sponsor (within 24 hours)
3. Cross-functional conflict → Exec sponsor mediation

Bad Example: Coordination Failure

## What Went Wrong: Widget 2.0 Launch

### Red Flags Ignored:
- No single owner identified
- Marketing found out about features 1 week before launch
- Sales not trained until launch day
- Support documentation written by engineering
- No regular sync meetings scheduled
- Decisions made in hallway conversations

### Results:
- Support tickets 5x normal (untrained team)
- Sales couldn't answer customer questions
- Marketing blog post had wrong feature descriptions
- Launch delayed 2 weeks after "go" decision
- Exec blindsided by customer complaints

### Root Cause: No coordination framework

Dependency Tracking

Launch Dependencies Map
═══════════════════════

Feature Complete (Eng)
        │
        ├──► Documentation Ready (Support)
        │           │
        │           └──► Support Training Complete
        │
        ├──► Demo Environment Ready (Eng)
        │           │
        │           └──► Sales Enablement Complete
        │
        └──► API Finalized (Eng)
                    │
                    └──► Integration Partner Ready

All paths must complete before Go/No-Go

Handoff Protocols

Conflict Resolution Framework

Conflict Type           Resolution Path
─────────────           ───────────────
Timeline disagreement → PM arbitrates, exec approves
Scope disagreement    → PM decides with eng input
Messaging disagreement→ PMM decides with PM input
Resource conflict     → Exec sponsor decides
Quality vs. speed     → Eng lead has veto on quality

Coordination Tooling

Anti-Patterns

• No single owner — Shared ownership = no ownership
• Siloed planning — Teams discover conflicts at launch
• Meeting overload — 5 hours of syncs per day
• Async only — Some decisions need real-time discussion
• No escalation path — Conflicts fester
• Late stakeholder inclusion — "I didn't know about this launch"
• Decision by committee — Endless debate, no action
• Verbal agreements — Undocumented decisions create confusion

---

title: Launch Day Execution impact: CRITICAL tags: execution, launch-day, war-room, operations

Launch Day Execution

Impact: CRITICAL

Launch day is the culmination of weeks of preparation. Execute with precision through clear runbooks, war rooms, and real-time coordination.

Launch Day Timeline Template

LAUNCH DAY SCHEDULE (Tier 1/2)
══════════════════════════════

06:00  War room opens, monitoring begins
06:30  Engineering: Final deployment verification
07:00  PR embargo lifts, press coverage begins
08:00  Blog post goes live
08:30  Marketing: Social media campaign starts
09:00  Email campaign sends
09:30  In-app notifications enabled
10:00  Sales team notified to begin outreach
10:30  First status check (all teams)
12:00  Midday status check
14:00  Afternoon status check
16:00  End-of-day status check
18:00  War room closes (or as needed)
T+1    Morning debrief, overnight monitoring review

War Room Setup

Virtual War Room (Slack/Teams):

#launch-war-room
├── Purpose: Real-time coordination
├── Who: Core launch team + on-call
├── Rules:
│   ├── All issues posted here immediately
│   ├── Use threads for discussion
│   ├── Pin critical updates
│   └── No side conversations
│
├── Pinned Messages:
│   ├── Launch runbook link
│   ├── Escalation contacts
│   ├── Status page link
│   └── Rollback command

Physical War Room (if applicable):

Launch Runbook Template

# [Feature] Launch Runbook

## Pre-Launch Checklist (T-1 hour)
□ All deployments complete
□ Feature flags ready to enable
□ Monitoring dashboards open
□ On-call engineers confirmed
□ Support team briefed
□ Rollback plan reviewed

## Launch Sequence
| Time | Action | Owner | Verify |
|------|--------|-------|--------|
| 08:00 | Enable feature flag | @eng-lead | [link] |
| 08:05 | Verify metrics baseline | @pm | [link] |
| 08:10 | Publish blog post | @pmm | [link] |
| 08:15 | Verify blog live | @pmm | [link] |
| 08:30 | Send email campaign | @pmm | [link] |
| 08:35 | Verify emails sending | @pmm | [link] |
| 09:00 | Enable in-app notification | @eng | [link] |
| 09:05 | Post to social channels | @pmm | [links] |
| 09:30 | First health check | @all | [checklist] |

## Health Check Protocol
Every 2 hours, verify:
□ Error rate < 0.1%
□ Latency p95 < 200ms
□ Support tickets < threshold
□ Social sentiment neutral/positive
□ Feature adoption tracking

## Escalation Matrix
| Issue Type | First Contact | Escalate To | SLA |
|------------|---------------|-------------|-----|
| P0 (system down) | @eng-oncall | @eng-lead | 5 min |
| P1 (degraded) | @eng-oncall | @eng-lead | 15 min |
| Support spike | @support-lead | @pm | 30 min |
| PR issue | @pmm | @comms-lead | 15 min |
| Exec escalation | @pm | @exec-sponsor | Immediate |

## Rollback Procedure
If rollback needed:
1. PM announces in #launch-war-room
2. Eng lead confirms with "ROLLBACK CONFIRMED"
3. Execute: `./scripts/rollback-feature.sh`
4. Verify rollback complete
5. PM notifies stakeholders
6. Marketing pauses campaigns
7. Support sends holding response

## Emergency Contacts
| Role | Name | Phone | Slack |
|------|------|-------|-------|
| PM | [Name] | [Phone] | @handle |
| Eng Lead | [Name] | [Phone] | @handle |
| Exec Sponsor | [Name] | [Phone] | @handle |

Good Example: Smooth Launch Execution

## Launch Day Log: Enterprise SSO

**08:00** - Feature flag enabled. All systems green.
**08:05** - Baseline metrics captured. Error rate 0.02%.
**08:10** - Blog published. [link verified]
**08:32** - Email campaign started. 50K recipients.
**09:00** - In-app notification live.
**09:15** - First support ticket: user confused by setup.
           FAQ updated. Not escalated.
**09:30** - Health check: All green.
           - Error rate: 0.03%
           - First 10 SSO setups successful
           - Social sentiment: Positive
**10:30** - 47 SSO setups completed (target: 30).
**12:00** - Midday check: All green.
           - Error rate: 0.02%
           - 89 SSO setups
           - 3 support tickets (all resolved)
**14:00** - Press coverage starting to appear.
**16:00** - EOD check:
           - 156 SSO setups (target: 100)
           - 0 P0/P1 incidents
           - 8 support tickets (all resolved)
           - NPS from early users: 62
**17:00** - War room closed. Overnight monitoring enabled.

**Status: SUCCESSFUL LAUNCH**

Bad Example: Chaotic Launch

## Launch Day Disaster: Widget 2.0

**08:00** - Feature supposed to launch. Deployment stuck.
**08:15** - Blog post goes live anyway (premature).
**08:20** - Customers seeing "feature not found" errors.
**08:30** - Twitter complaints start.
**08:45** - Deployment finally completes.
**09:00** - Email sends to customers who already saw errors.
**09:15** - Support queue at 50 tickets, team not briefed.
**09:30** - No health check performed. PM in meetings.
**10:00** - Exec asks for status. No one has update.
**11:00** - Error rate discovered at 5% (limit was 0.1%).
**11:30** - Rollback decision debated for 30 minutes.
**12:00** - Rollback executed. Customers confused.
**12:30** - Blog post still live describing feature.
**14:00** - Press article published about "botched launch."

**Root Causes:**
- No deployment verification step
- No coordination between eng and marketing
- No war room or communication channel
- No health check protocol
- No clear rollback decision authority

Real-Time Decision Framework

Communication Templates

War Room Status Update:

🟢 STATUS CHECK [10:30]

Metrics:
- Error rate: 0.03% (limit: 0.1%)
- Adoption: 47 setups (target: 30)
- Support: 3 tickets (all resolved)

No blockers. Next check: 12:00.

Escalation Message:

🟡 ESCALATION [11:15]

Issue: Error rate at 0.8%, trending up
Impact: ~50 users affected
Cause: Database connection pooling
Action: Eng investigating, ETA 15 min
Decision needed: None yet

Next update: 11:30 or sooner if change

Rollback Announcement:

🔴 ROLLBACK INITIATED [11:45]

Decision: Rollback due to error rate > 2%
Status: In progress
ETA: 15 minutes

Actions:
- @marketing: Pause all campaigns
- @support: Send holding response template
- @eng: Execute rollback
- @pm: Notify exec sponsor

Will confirm completion.

Post-Launch Day Checklist

End of Day:
□ Final metrics captured
□ All incidents documented
□ Support queue cleared or handed off
□ Marketing campaigns assessed
□ Overnight monitoring confirmed
□ Key wins/issues summarized for exec
□ War room closed or transitioned

Day 2 Morning:
□ Overnight alerts reviewed
□ Metrics trend assessed
□ Support volume checked
□ Social sentiment reviewed
□ Quick wins identified
□ Follow-up actions assigned

Anti-Patterns

• No runbook — Making it up as you go
• No war room — Communication scattered across channels
• Premature publishing — Marketing goes before engineering confirms
• No health checks — Assuming green until someone complains
• Unclear rollback authority — Debate during crisis
• PM unavailable — Captain leaves the ship
• No escalation path — Issues fester
• Launch and leave — War room closes at 5pm sharp

---

title: Rollback and Contingency Planning impact: CRITICAL tags: execution, rollback, contingency, risk

Rollback and Contingency Planning

Impact: CRITICAL

Hope is not a strategy. Every launch needs a clear rollback plan and contingencies for when things go wrong.

Rollback Decision Matrix

Rollback Types

Rollback Readiness Checklist

## Pre-Launch Rollback Verification

□ Feature flag configured and tested
□ Rollback command documented
□ Rollback tested in staging
□ Database rollback tested (if applicable)
□ Rollback runbook reviewed by on-call
□ Monitoring alerts set for rollback triggers
□ Communication templates ready
□ Decision authority clear

## Rollback Command
Feature flag: `./scripts/toggle-feature.sh sso-launch off`
Verify: Check [dashboard link] for flag status

## Estimated Rollback Time
- Feature flag: < 1 minute
- Full effect: < 5 minutes
- Verification: 10 minutes

Good Example: Clean Rollback

## Rollback Incident Report: Workflow Automation

**Timeline:**
- 09:15 - Feature launched, all green
- 09:45 - Error rate climbing (0.2% → 0.8%)
- 10:00 - Identified: Edge case in EU data center
- 10:05 - Decision: Attempt hotfix, 15 min timeout
- 10:20 - Hotfix not ready, error rate at 1.5%
- 10:22 - PM: "Initiating rollback"
- 10:23 - Eng Lead: "ROLLBACK CONFIRMED"
- 10:24 - Feature flag disabled
- 10:25 - Marketing campaigns paused
- 10:27 - Support team notified, canned response activated
- 10:30 - Error rate returning to baseline
- 10:35 - Rollback verified complete
- 10:40 - Customer communication sent

**What Went Well:**
- Clear decision criteria (1.5% > 1% threshold)
- Fast rollback execution (< 5 minutes)
- Good communication throughout
- No customer-facing outage

**Root Cause:**
- EU data center timezone handling edge case
- Not covered in beta (no EU beta users)

**Relaunch Plan:**
- Fix deployed to staging: 10/15
- EU-specific beta: 10/16-10/18
- Relaunch: 10/19

Bad Example: Rollback Chaos

## Rollback Disaster: Report Builder

**What Happened:**
- 09:00 - Launch
- 10:00 - Error rate at 3%, rising
- 10:15 - Support: "Should we rollback?"
- 10:20 - PM in meeting, no response
- 10:30 - Eng: "I could rollback but need approval"
- 10:45 - Error rate at 7%
- 11:00 - Exec: "Why is Twitter angry?"
- 11:10 - PM: "Who can make the rollback decision?"
- 11:20 - Rollback attempted, failed (untested)
- 11:45 - Rollback finally successful
- 12:00 - No customer communication prepared

**Impact:**
- 2.5 hours of degraded experience
- 47 angry support tickets
- 3 enterprise customers escalated to exec
- 2 tweets from tech press

**Root Causes:**
- No clear rollback authority
- Rollback never tested
- No pre-written communication
- PM not available during launch

Contingency Planning Matrix

Contingency Communication Templates

Internal Rollback Announcement:

🔴 ROLLBACK COMPLETE

The [Feature] launch has been rolled back due to [brief reason].

What happened:
- [1-2 sentence description]

What we're doing:
- Engineering investigating root cause
- ETA for fix assessment: [time]
- Relaunch target: TBD pending fix

What you should do:
- Sales: Pause outreach about [Feature]
- Support: Use canned response #rollback-[feature]
- Marketing: Campaigns paused automatically

Next update: [time]

Customer Communication (Major Issue):

Subject: Update on [Feature] - Temporary Availability

Hi [Name],

Earlier today we launched [Feature]. Some users experienced
[brief issue description], so we've temporarily rolled back
the feature while we make it right.

What this means for you:
- [Feature] is temporarily unavailable
- Your existing data/settings are unaffected
- We expect to relaunch within [timeframe]

We'll notify you when [Feature] is available again.
We apologize for any inconvenience.

[Name]
[Title]

Gradual Rollback Strategy

If issues detected but not critical:

Phase 1 (immediate):
├── Pause new user exposure
└── Current users unaffected

Phase 2 (if issues persist):
├── Reduce to 50% of users
└── Monitor for 30 minutes

Phase 3 (if no improvement):
├── Reduce to 10% of users
└── Monitor for 30 minutes

Phase 4 (if still problematic):
├── Full rollback
└── Root cause analysis

Benefits:
- Minimizes customer disruption
- Provides debugging opportunity
- Maintains some launch momentum

Relaunch Protocol

## Relaunch Checklist: [Feature]

### Before Scheduling Relaunch
□ Root cause identified and documented
□ Fix implemented and code-reviewed
□ Fix verified in staging environment
□ Additional test cases added for failure scenario
□ Rollback tested again

### Relaunch Communication
□ Internal teams notified of new date
□ Customer communication drafted (if needed)
□ Press/analyst update (if covered)
□ Sales re-enabled with update

### Relaunch Execution
□ Same runbook with additional monitoring
□ Lower thresholds for first 24 hours
□ Extended war room hours
□ Faster escalation paths

Anti-Patterns

• No rollback plan — "We'll figure it out if we need to"
• Untested rollback — Script that fails when needed
• Unclear authority — Debate during crisis
• No feature flags — Rollback requires full deployment
• No templates — Writing communications during incident
• Optimism bias — "It won't happen to us"
• Rollback shame — Treating rollback as failure vs. professionalism
• No relaunch plan — Rollback becomes permanent

---

title: Launch Tiering Strategy impact: CRITICAL tags: planning, tiers, strategy, prioritization

Launch Tiering Strategy

Impact: CRITICAL

Not every launch deserves a keynote. Tiering ensures you invest the right resources for the right impact.

The Four Launch Tiers

Tier Decision Matrix

Use this matrix to determine the appropriate tier:

Tier 1: Flagship Launch Checklist

□ Executive sponsor assigned
□ Cross-functional launch team formed
□ 12-week timeline established
□ Press/analyst strategy defined
□ Event or major moment identified
□ Full marketing campaign planned
□ Sales enablement program designed
□ Customer advisory board briefed
□ Success metrics with exec alignment
□ Post-launch monitoring plan

Tier 2: Major Launch Checklist

□ Product marketing owner assigned
□ 6-week timeline established
□ Blog post and supporting content
□ Email campaign to relevant segments
□ Social media campaign
□ Sales one-pager and talking points
□ Support documentation updated
□ In-app announcement planned
□ Success metrics defined

Good Example: Proper Tiering

## Launch Brief: Enterprise SSO

**Proposed Tier: 2 (Major)**

**Justification:**
- Revenue: Enables $500K pipeline in enterprise segment
- User Impact: Top requested feature from enterprise prospects
- Competitive: Achieves parity with market leaders
- Strategic: Key to enterprise expansion strategy

**Approved Resources:**
- 6-week timeline
- Dedicated PMM owner
- Blog + email + social campaign
- Sales enablement session
- Updated security whitepaper
- Support team training

Bad Example: Over-Tiered Launch

## Launch Brief: Dashboard Dark Mode

**Proposed Tier: 1 (Flagship)**  ← WRONG

**Justification:**
- "Users have been asking for this for years"
- "It looks really cool"
- "We should do a big splash"

**Why This Fails:**
- Dark mode is a Tier 3 or 4 feature
- Minimal revenue impact
- No competitive differentiation
- Wastes resources, burns out team
- Dilutes impact of actual Tier 1 launches

Good Example: Under-Tiered Recognition

## Launch Review: API v2.0

**Initial Tier: 3 (Standard)**
**Revised Tier: 2 (Major)**

**Why Upgrade:**
- Discovered 40% of enterprise pipeline blocked on API limitations
- Competitive analysis shows this is differentiating capability
- Developer community engagement opportunity
- Platform ecosystem enablement

**Added Resources:**
- Developer-focused blog series
- API documentation revamp
- Developer community event
- Integration partner outreach

Tiering Escalation Triggers

Upgrade tier when:

• Executive visibility increases
• Competitive landscape shifts
• Customer demand exceeds expectations
• Strategic priority changes
• Partner/press interest emerges

Downgrade tier when:

• Scope reduces significantly
• Timeline compresses
• Resources become constrained
• Market window passes
• Feature becomes table stakes

Anti-Patterns

• Everything is Tier 1 — Launch fatigue destroys impact and burns teams
• No tiering system — Every launch reinvents the wheel
• Tier by politics — Exec pet projects get over-resourced
• Static tiers — Refusing to adjust as circumstances change
• Tier without criteria — Gut feel instead of structured decision
• Tiering too late — Deciding resources after work begins

---

title: Launch Success Criteria impact: CRITICAL tags: planning, metrics, success, measurement

Launch Success Criteria

Impact: CRITICAL

Define success before launch, not after. Post-hoc success criteria is rationalization, not measurement.

Success Criteria Framework

Every launch needs metrics across four dimensions:

Adoption Metrics by Tier

Quality Metrics (All Tiers)

Error Rate:        < 0.1% of requests
Latency:          < 200ms p95 (or no regression)
Availability:      99.9% uptime
Incidents:         Zero P0/P1 in first 48 hours
Rollback:          Zero rollbacks required

Good Example: Comprehensive Success Criteria

## Success Criteria: Enterprise SSO Launch

### Adoption (Product owns)
| Metric | Target | Measurement |
|--------|--------|-------------|
| Enterprise accounts enabling SSO | 25% in 30 days | Product analytics |
| Time to SSO setup | < 30 minutes | Instrumentation |
| SSO login rate post-setup | > 90% | Auth logs |

### Quality (Engineering owns)
| Metric | Target | Measurement |
|--------|--------|-------------|
| SSO auth latency | < 500ms p95 | APM |
| Auth error rate | < 0.01% | Error tracking |
| Availability | 99.99% | Uptime monitoring |

### Business (Sales/Product owns)
| Metric | Target | Measurement |
|--------|--------|-------------|
| Pipeline influenced | $500K in 90 days | CRM attribution |
| Enterprise close rate | +5% improvement | Sales analytics |
| Competitive win rate | +10% vs SSO objection | Win/loss analysis |

### Sentiment (Product/Support owns)
| Metric | Target | Measurement |
|--------|--------|-------------|
| Setup NPS | > 50 | Post-setup survey |
| Support tickets | < 10% of enablements | Zendesk |
| Admin feedback | Qualitative positive | Customer calls |

Bad Example: Vague Success Criteria

## Success Criteria: New Dashboard

- Users should like it
- It should be fast
- We want lots of adoption
- Good feedback from customers

**Why This Fails:**
- No specific numbers
- No timeline for measurement
- No owners assigned
- No measurement method defined
- "Lots" and "good" are not metrics

The SMART Criteria Test

Every metric should pass SMART:

Baseline Requirements

Before setting targets, establish baselines:

Current State Analysis:
┌─────────────────────────────────────────┐
│ Comparable Feature Launch (6 months ago) │
│ - Day 1 adoption: 2%                     │
│ - Week 1 activation: 8%                  │
│ - Month 1 retention: 18%                 │
│                                          │
│ Target for This Launch:                  │
│ - Day 1 adoption: 3% (+50%)              │
│ - Week 1 activation: 10% (+25%)          │
│ - Month 1 retention: 25% (+38%)          │
└─────────────────────────────────────────┘

Success Criteria Sign-off

Post-Launch Success Review Template

## Launch Success Review: [Feature Name]

**Launch Date:** [Date]
**Review Date:** [Date]

### Adoption Results
| Metric | Target | Actual | Status |
|--------|--------|--------|--------|
| [Metric] | [Target] | [Actual] | [Met/Missed] |

### Quality Results
| Metric | Target | Actual | Status |
|--------|--------|--------|--------|

### Business Results
| Metric | Target | Actual | Status |
|--------|--------|--------|--------|

### Sentiment Results
| Metric | Target | Actual | Status |
|--------|--------|--------|--------|

### Overall Assessment: [SUCCESS / PARTIAL / MISSED]

### Key Learnings:
1. [Learning]
2. [Learning]

### Follow-up Actions:
1. [Action] - Owner: [Name] - Due: [Date]

Anti-Patterns

• Post-launch metrics — Deciding what success looks like after you know results
• Vanity metrics only — Page views without activation
• No baseline — Targets with no reference point
• Moving goalposts — Changing targets when you're missing them
• Single dimension — Measuring adoption but not quality
• No owner — Metrics without accountability
• Unmeasurable targets — "Improved customer satisfaction"

---

title: Launch Timeline Planning impact: HIGH tags: planning, timeline, milestones, scheduling

Launch Timeline Planning

Impact: HIGH

Great launches work backwards from the date. A well-structured timeline prevents last-minute chaos and ensures every team is ready.

Timeline Templates by Tier

Tier 1: Flagship Launch (12 weeks)

Week -12: Kickoff
├── Launch brief drafted
├── Stakeholder alignment meeting
├── Tier confirmed by exec sponsor
└── Core team identified

Week -10: Strategy
├── Messaging framework complete
├── Competitive positioning defined
├── Press/analyst strategy finalized
└── Event/moment identified

Week -8: Beta Launch
├── Alpha complete, closed beta begins
├── Sales enablement content drafted
├── PR outreach starts
└── Success criteria locked

Week -6: Content Development
├── All marketing content in review
├── Support documentation drafted
├── Demo environment ready
└── Beta feedback incorporated

Week -4: Enablement
├── Sales training complete
├── Support training complete
├── CS playbook ready
├── Final content approved
└── Go/no-go checkpoint #1

Week -2: Final Prep
├── All systems tested
├── Monitoring configured
├── Runbook reviewed
├── Communication scheduled
└── War room setup
└── Go/no-go checkpoint #2

Week -1: Hypercare Prep
├── Final deployment to production
├── On-call schedule confirmed
├── Rollback tested
└── Final walkthrough

LAUNCH DAY

Week +1: Hypercare
├── Daily monitoring
├── Rapid response to issues
└── Quick wins identified

Week +2: Retrospective
├── Success criteria review
├── Launch retrospective
└── Learnings documented

Tier 2: Major Launch (6 weeks)

Week -6: Kickoff + Strategy
├── Launch brief approved
├── Messaging complete
└── Team aligned

Week -4: Content + Beta
├── Beta program active
├── Content development
├── Enablement drafts
└── Go/no-go checkpoint

Week -2: Enablement + Prep
├── All training complete
├── Content approved
├── Systems tested
└── Final go/no-go

Week -1: Final Prep
├── Deployment ready
├── War room setup
└── Runbook reviewed

LAUNCH DAY

Week +1: Monitor + Retro
├── Monitoring
└── Retrospective

Tier 3: Standard Launch (3 weeks)

Week -3: Planning
├── Launch brief
├── Content assignment
└── Success criteria

Week -2: Development
├── Content complete
├── Documentation ready
└── Go/no-go

Week -1: Prep
├── Final review
└── Scheduled deployment

LAUNCH DAY

Week +1: Monitor
└── Quick check

Milestone Dependencies

DEPENDENCY MAP
══════════════

Feature Complete
        │
        ├──► Beta Can Begin
        │           │
        │           └──► Beta Feedback
        │                     │
        │                     └──► Final Feature Adjustments
        │
        ├──► Documentation Drafted
        │           │
        │           └──► Support Training
        │
        ├──► Demo Environment
        │           │
        │           └──► Sales Enablement
        │
        └──► API Finalized
                    │
                    └──► Partner Integration


Messaging Approved
        │
        ├──► Content Creation
        │           │
        │           └──► Content Review
        │                     │
        │                     └──► Content Published
        │
        └──► PR Outreach
                    │
                    └──► Press Coverage

Good Example: Well-Planned Timeline

## Launch Timeline: Enterprise SSO

### Phase 1: Foundation (Weeks -8 to -6)
| Date | Milestone | Owner | Dependencies |
|------|-----------|-------|--------------|
| Aug 15 | Launch brief approved | Sarah | None |
| Aug 17 | Tier 2 confirmed | Sarah | Launch brief |
| Aug 19 | Core team kickoff | Sarah | Tier decision |
| Aug 22 | Messaging framework v1 | Mike | Launch brief |
| Aug 26 | Beta cohort selected | Sarah | Feature stable |
| Aug 29 | Success criteria locked | Sarah | Stakeholder input |

### Phase 2: Development (Weeks -5 to -3)
| Date | Milestone | Owner | Dependencies |
|------|-----------|-------|--------------|
| Sep 1 | Closed beta begins | Sarah | Beta cohort, feature |
| Sep 5 | Sales one-pager draft | Mike | Messaging |
| Sep 8 | Support docs draft | Lisa | Feature specs |
| Sep 12 | Demo environment ready | Priya | Feature stable |
| Sep 15 | Messaging approved | Mike | Exec review |
| Sep 19 | Go/no-go #1 | Sarah | Multiple |

### Phase 3: Enablement (Weeks -2 to -1)
| Date | Milestone | Owner | Dependencies |
|------|-----------|-------|--------------|
| Sep 22 | Sales training | Mike | Demo env, materials |
| Sep 24 | Support training | Lisa | Docs, demo env |
| Sep 26 | All content approved | Mike | Reviews complete |
| Sep 28 | CS playbook ready | CS Lead | Training complete |
| Sep 29 | Monitoring configured | Priya | Feature deployed |
| Sep 30 | Go/no-go #2 | Sarah | All prep complete |

### Phase 4: Launch (Week 0)
| Date | Milestone | Owner | Dependencies |
|------|-----------|-------|--------------|
| Oct 1 | War room setup | Sarah | Go/no-go passed |
| Oct 2 | Final deployment | Priya | All clear |
| Oct 3 | LAUNCH DAY | Sarah | Everything ready |

### Phase 5: Post-Launch (Weeks +1 to +2)
| Date | Milestone | Owner | Dependencies |
|------|-----------|-------|--------------|
| Oct 3-6 | Hypercare monitoring | Sarah/Priya | Launch |
| Oct 10 | Stabilization check | Sarah | Hypercare clear |
| Oct 17 | Launch retrospective | Sarah | Metrics available |

Bad Example: Unrealistic Timeline

## Launch Timeline: API v2 (What Not To Do)

Week -2:
- Decide we're launching
- Start everything at once

Week -1:
- Feature still being built
- Marketing asks "what are we launching?"
- Sales finds out from Slack
- Support: "What documentation?"

Week 0:
- Deploy morning of launch
- Marketing scrambles to publish blog
- Launch "on time"

Week +1:
- Support overwhelmed
- Sales can't answer questions
- 3 critical bugs discovered
- "Why didn't we plan better?"

**What went wrong:**
- 2 weeks for a Tier 2 launch (needed 6)
- No parallel workstreams
- No checkpoints
- No dependency mapping
- Feature not complete before enablement

Go/No-Go Checkpoints

Checkpoint 1 (T-4 weeks for Tier 2):

□ Feature development on track
□ Beta feedback positive
□ Messaging approved
□ No major blockers

Decision: Continue / Delay / Scope Reduce

Checkpoint 2 (T-1 week):

□ Feature complete and tested
□ All content approved and scheduled
□ All enablement complete
□ Monitoring configured
□ Rollback plan ready
□ On-call scheduled

Decision: Go / No-Go

Timeline Risk Management

Buffer Time Guidelines

Timeline Communication

Weekly Status Update Template:

## Launch Status: [Feature] - Week of [Date]

**Overall Status:** 🟢 On Track / 🟡 At Risk / 🔴 Blocked

**This Week:**
- [Completed milestone]
- [Completed milestone]

**Next Week:**
- [Upcoming milestone]
- [Upcoming milestone]

**Risks/Blockers:**
- [Risk] - Mitigation: [Action]

**Decisions Needed:**
- [Decision] - From: [Person] - By: [Date]

Anti-Patterns

• No timeline — "We'll launch when it's ready"
• Unrealistic compression — Tier 1 launch in 2 weeks
• Serial planning — Not starting parallel workstreams
• No checkpoints — All-or-nothing at launch
• No buffer — Every day scheduled
• Feature-first only — Marketing starts when code complete
• No dependencies — Enabling sales before demo ready
• Fixed date, variable scope — Date matters, quality doesn't

---

title: Post-Launch Monitoring impact: HIGH tags: postlaunch, monitoring, metrics, operations

Post-Launch Monitoring

Impact: HIGH

The launch isn't over when it ships. Systematic monitoring catches issues early and validates success.

Monitoring Phases

Hypercare Dashboard

POST-LAUNCH HYPERCARE DASHBOARD
═══════════════════════════════

System Health
├── Error Rate:     0.03% [✓] (threshold: 0.1%)
├── Latency p95:    145ms [✓] (threshold: 200ms)
├── Availability:   100%  [✓] (threshold: 99.9%)
└── Queue Depth:    12    [✓] (threshold: 1000)

Adoption (T+24 hours)
├── Feature Views:  2,847
├── Feature Usage:  1,203 (42% activation)
├── Unique Users:   891
└── Target:         500   [✓] EXCEEDED

Quality
├── P0 Incidents:   0     [✓]
├── P1 Incidents:   0     [✓]
├── Bug Reports:    7     [!] (investigating 2)
└── Rollbacks:      0     [✓]

Support
├── Tickets (feature):    23
├── Avg Response Time:    12 min [✓]
├── Escalations:          1
└── CSAT:                 4.2/5 [✓]

Sentiment
├── Social Mentions:      47
├── Positive:            38 (81%)
├── Neutral:             7  (15%)
└── Negative:            2  (4%)

Alert Configuration

Good Example: Effective Monitoring

## Post-Launch Monitoring Report: Enterprise SSO
### Day 3 Summary

**Executive Summary:**
SSO launch performing above expectations. No critical issues.
Adoption 40% ahead of target. Recommend moving to stabilization phase.

**System Health:**
| Metric | Day 1 | Day 2 | Day 3 | Target |
|--------|-------|-------|-------|--------|
| Error rate | 0.05% | 0.03% | 0.02% | < 0.1% |
| Latency | 180ms | 165ms | 155ms | < 200ms |
| Uptime | 100% | 100% | 100% | 99.9% |

**Adoption Metrics:**
| Metric | Day 1 | Day 2 | Day 3 | Target |
|--------|-------|-------|-------|--------|
| SSO setups | 89 | 67 | 54 | 50/day |
| Active SSO users | 2,340 | 4,120 | 5,890 | 3,000 |
| Setup success rate | 94% | 96% | 97% | > 90% |

**Issues Identified:**
1. Minor: Setup wizard confusing for Azure AD (12 tickets)
   - Action: UX improvement scheduled for next sprint
   - Workaround: Updated documentation

2. Edge case: SCIM sync delay for > 500 user orgs
   - Action: Engineering investigating
   - Impact: 3 customers, all contacted

**Support Analysis:**
- Total tickets: 47 (expected ~60)
- Most common: "How do I set up?" (18) - Resolved with docs link
- Top issue: Azure AD confusion (12) - Action item above

**Recommendation:** Exit hypercare, enter stabilization phase

Bad Example: No Monitoring

## What Happened: Reporting 2.0 Launch

**Week 1:**
- PM: "Launch went great!"
- No dashboard, no tracking

**Week 2:**
- Support: "We're getting a lot of tickets about reports"
- PM: "How many?"
- Support: "I don't know, a lot"

**Week 3:**
- Exec: "Customer X says reports are broken"
- PM: "First I'm hearing of this"
- Discovered: 15% error rate for 2 weeks
- Discovered: 340 support tickets about feature
- Discovered: 3 enterprise customers considering churn

**Root Cause:**
- No error monitoring configured
- No feature-specific dashboards
- No support ticket categorization
- No regular review cadence

Monitoring Checklist by Role

Engineering:

Daily (Hypercare):
□ Review error rate trends
□ Check latency percentiles
□ Verify no P0/P1 incidents
□ Review bug reports
□ Check infrastructure capacity

Weekly (Stabilization):
□ Performance trend analysis
□ Edge case identification
□ Technical debt assessment
□ Scaling projections

Product:

Daily (Hypercare):
□ Review adoption metrics
□ Check support trends
□ Triage bug reports
□ Customer feedback review

Weekly (Stabilization):
□ Adoption funnel analysis
□ Success criteria assessment
□ Feature iteration planning
□ Stakeholder update

Marketing:

Daily (Hypercare):
□ Social sentiment monitoring
□ Press coverage tracking
□ Campaign performance

Weekly (Stabilization):
□ Content performance analysis
□ Lead attribution review
□ Campaign optimization

Success Criteria Tracking

## Success Criteria Dashboard: SSO Launch

### Adoption (Target: Week 4)
| Metric | Target | Week 1 | Week 2 | Week 3 | Week 4 |
|--------|--------|--------|--------|--------|--------|
| Setups | 200 | 210 ✓ | 285 ✓ | 340 ✓ | 390 ✓ |
| Active | 5,000 | 3,800 | 6,200 ✓ | 8,100 ✓ | 9,500 ✓ |
| Activation % | 30% | 25% | 32% ✓ | 35% ✓ | 38% ✓ |

### Quality (Target: Ongoing)
| Metric | Target | Week 1 | Week 2 | Week 3 | Week 4 |
|--------|--------|--------|--------|--------|--------|
| Error rate | < 0.1% | 0.03% ✓ | 0.02% ✓ | 0.02% ✓ | 0.01% ✓ |
| P0 incidents | 0 | 0 ✓ | 0 ✓ | 0 ✓ | 0 ✓ |
| Setup NPS | > 50 | 52 ✓ | 58 ✓ | 61 ✓ | 64 ✓ |

### Business (Target: Quarter)
| Metric | Target | Month 1 | Month 2 | Month 3 |
|--------|--------|---------|---------|---------|
| Pipeline | $500K | $180K | $380K | $620K ✓ |
| Won deals | 5 | 2 | 4 | 7 ✓ |

**Overall Status: ON TRACK FOR SUCCESS**

Escalation Triggers

Transition Criteria

Hypercare → Stabilization:

□ Zero P0/P1 incidents for 48 hours
□ Error rate < threshold for 48 hours
□ Support volume trending down
□ No unresolved critical bugs

Stabilization → Steady State:

□ No incidents for 2 weeks
□ Support volume at normal levels
□ Adoption tracking to targets
□ All launch bugs resolved or scheduled

Anti-Patterns

• No monitoring — Assuming it works until someone complains
• Vanity dashboards — Tracking page views, not activation
• Alert fatigue — So many alerts, real issues ignored
• No thresholds — Looking at numbers without targets
• PM absence — Engineering monitors alone
• Snapshot only — Checking once, not trending
• No support integration — Tickets not linked to feature
• Too short hypercare — Ending monitoring after 24 hours

---

title: Launch Retrospectives impact: HIGH tags: postlaunch, retrospective, learning, improvement

Launch Retrospectives

Impact: HIGH

Every launch is a learning opportunity. Structured retrospectives turn experience into institutional knowledge.

Retrospective Timeline

Retrospective Framework

THE 4L RETROSPECTIVE
════════════════════

┌─────────────────┬─────────────────┐
│    LIKED        │    LEARNED      │
│                 │                 │
│  What went well │  New insights   │
│  that we should │  and knowledge  │
│  repeat         │  gained         │
│                 │                 │
├─────────────────┼─────────────────┤
│    LACKED       │    LONGED FOR   │
│                 │                 │
│  What was       │  What we wish   │
│  missing or     │  we had done    │
│  insufficient   │  differently    │
│                 │                 │
└─────────────────┴─────────────────┘

Retrospective Agenda Template

## Launch Retrospective: [Feature Name]

**Date:** [Date]
**Facilitator:** [Name]
**Attendees:** [List]

### Agenda (60-90 minutes)

1. **Context Setting** (5 min)
   - Launch goals recap
   - Success criteria recap
   - Key metrics summary

2. **Success Criteria Review** (10 min)
   - Did we hit our targets?
   - What do the numbers tell us?

3. **Timeline Review** (10 min)
   - Walk through major milestones
   - Where did we get ahead/behind?

4. **4Ls Exercise** (25 min)
   - 5 min silent brainstorming
   - 20 min group discussion

5. **Action Items** (15 min)
   - What will we do differently?
   - Who owns each action?

6. **Kudos** (5 min)
   - Recognize contributions

Good Example: Comprehensive Retrospective

## Launch Retrospective: Enterprise SSO

**Date:** October 28, 2024
**Facilitator:** Sarah Chen (PM)
**Attendees:** Mike (PMM), Priya (Eng), Tom (Sales), Lisa (Support)

### Success Criteria Results

| Metric | Target | Actual | Status |
|--------|--------|--------|--------|
| SSO setups (30d) | 200 | 390 | EXCEEDED |
| Active SSO users | 5,000 | 9,500 | EXCEEDED |
| Error rate | < 0.1% | 0.02% | MET |
| Setup NPS | > 50 | 64 | EXCEEDED |
| Pipeline influenced | $500K | $620K | EXCEEDED |

**Overall: SUCCESSFUL LAUNCH**

### Liked (What went well)

1. **Cross-functional coordination**
   - Weekly syncs kept everyone aligned
   - Slack channel was invaluable for real-time updates
   - "Best coordinated launch I've been part of" - Tom

2. **Beta program**
   - Caught the Azure AD issue before GA
   - Customer quotes ready for launch day
   - Created internal champions

3. **Enablement materials**
   - Sales one-pager was "actually useful" (Tom's words)
   - Support troubleshooting guide prevented escalations
   - 90% of support tickets resolved with existing docs

4. **Launch day execution**
   - War room worked smoothly
   - No deployment issues
   - Marketing timing was perfect

### Learned (New insights)

1. **Beta cohort diversity matters**
   - Almost missed Azure AD edge case
   - Need to ensure geographic + IdP diversity

2. **Sales enablement timing**
   - 2 weeks before launch was right
   - Too early = forgotten, too late = unprepared

3. **In-app messaging impact**
   - In-app notification drove 40% of setups
   - Higher than email (25%) or blog (15%)

4. **Enterprise sales cycle**
   - Feature announcement → close takes 45-60 days
   - Should set 90-day pipeline targets, not 30-day

### Lacked (What was missing)

1. **International readiness**
   - No GDPR-specific documentation at launch
   - EU customers asked questions we couldn't answer

2. **Partner enablement**
   - Okta partnership team found out from blog post
   - Should have briefed integration partners

3. **Video content**
   - Multiple requests for setup walkthrough video
   - Added friction for visual learners

4. **Customer success playbook**
   - CS team wasn't sure how to position SSO in renewals
   - Created after launch, should have been ready

### Longed For (What we'd do differently)

1. **Earlier executive alignment**
   - Tier decision debated for 2 weeks
   - Should lock this at kickoff

2. **Longer beta for enterprise features**
   - 4 weeks felt rushed for enterprise IT teams
   - 6-8 weeks for enterprise-focused features

3. **Pre-written FAQ expansion**
   - First week support was reactive
   - Should anticipate more edge case questions

4. **Competitive response plan**
   - Competitor launched similar feature 2 weeks later
   - Were caught flat-footed on positioning

### Action Items

| Action | Owner | Due Date | Priority |
|--------|-------|----------|----------|
| Add GDPR docs to launch checklist | Lisa | Nov 5 | High |
| Create partner briefing template | Mike | Nov 10 | High |
| Add video to enablement checklist | Mike | Nov 10 | Medium |
| CS playbook required for Tier 1-2 | Sarah | Nov 15 | High |
| Extend enterprise beta standard to 6 weeks | Sarah | Next launch | Medium |
| Add competitive response to launch brief | Mike | Next launch | Medium |

### Kudos

- **Priya:** Flawless deployment, zero incidents
- **Tom:** Closed first SSO deal in 3 weeks
- **Lisa:** Support NPS highest ever for a launch
- **Mike:** Blog post generated 3 press pickups
- **Everyone:** Best cross-functional collab in 2024

Bad Example: Superficial Retrospective

## Retro: Widget 2.0

**Date:** Friday 5pm (30 min scheduled, 15 min actual)
**Who showed up:** PM, 1 engineer

### What happened:
- We launched
- Some bugs
- Customers complained

### What we learned:
- Test more
- Communicate better

### Action items:
- None assigned

**Why This Failed:**
- Rushed timing (Friday 5pm)
- Missing key stakeholders
- No metrics reviewed
- Vague insights ("communicate better")
- No ownership of actions
- Will repeat same mistakes

Retrospective Facilitation Tips

Before:

□ Schedule 2+ weeks in advance (calendars fill up)
□ Send pre-work: metrics summary, timeline, 4Ls template
□ Book 30 min buffer after for overflow
□ Ensure all key roles can attend
□ Prepare metrics dashboard

During:

□ Start with metrics (ground the conversation in data)
□ Use silent brainstorming (prevents groupthink)
□ Timebox each section
□ Capture everything (assign note-taker)
□ End with action items + owners + dates
□ Always include kudos

After:

□ Send notes within 24 hours
□ Add action items to project tracker
□ Follow up on action items at next team meeting
□ Archive retro for future reference

Retrospective Metrics to Review

Institutional Knowledge Capture

## Launch Playbook Update: Learnings from SSO Launch

### Added to Standard Checklist:
□ GDPR documentation (for EU-facing features)
□ Partner briefing (for integration features)
□ Setup video (for complex features)
□ CS playbook (for Tier 1-2 launches)

### Updated Standards:
- Enterprise feature beta: 6-8 weeks (was 4 weeks)
- Partner notification: T-2 weeks (was T-1 week)
- Competitive response plan: Required for Tier 1-2

### Templates Updated:
- Launch brief: Added competitive section
- Enablement checklist: Added video requirement
- Support prep: Expanded FAQ template

Anti-Patterns

• Skipping the retro — "We're too busy with the next thing"
• Blame game — Focusing on who, not what
• No metrics — Opinions without data
• Too soon — Before results are measurable
• Too late — Details forgotten
• No actions — Insights without follow-through
• Same mistakes — Not consulting past retros
• Missing stakeholders — Only PM attends
• Rushed timing — Friday 5pm, everyone checked out