Product Launch Playbook Skill for Claude

Product Launch Playbook

Overview

The Product Launch Playbook skill guides product managers through all phases of launching features or products, from pre-launch planning through post-launch analysis. It ensures coordinated execution across engineering, marketing, sales, and support teams.

When to Use This Skill

• Planning major feature launches
• Launching new product or product line
• Planning beta testing programs
• Executing go-to-market strategies
• Communicating with stakeholders
• Managing launch day operations
• Analyzing post-launch performance
• Planning customer success initiatives

Launch Framework Overview

Launch Timeline (8-12 weeks):

• Pre-Launch Phase (4-5 weeks) - Strategy, assets, readiness
• Beta Phase (2-3 weeks) - Customer validation, feedback
• Launch Phase (1-2 weeks) - Coordinated release
• Post-Launch Phase (4+ weeks) - Support, iteration, analysis

Pre-Launch Planning (4-5 weeks before)

Launch Steering Committee Formation

Core team members:

• Product Manager (Owner)
• Engineering Lead
• Design Lead
• Marketing Lead
• Sales Lead
• Support/Customer Success Lead
• Analytics Owner

Responsibilities:

• Weekly launch status meetings
• Escalation authority for decisions
• Budget and resource approval
• Cross-functional alignment

Go-to-Market (GTM) Strategy

Target Customer Definition:

• Primary segment: [Specific customer profile]
• Company size, industry, use case
• How they will benefit most
• Why they should care vs. competitors

• Secondary segment: [Broader customer profile]

Value Proposition:

• Core benefit: [One sentence, customer-focused]
• Supporting benefits: [3-4 specific advantages]
• Differentiation: [vs. competition or status quo]

Positioning Statement:

"For [customer segment], [product/feature] is a [category] that [solves problem]. Unlike [alternative], our [feature] [key differentiator]."

Example:

"For remote engineering teams, Real-time Project Sync is a collaboration system that eliminates status update meetings. Unlike email and Slack, our feature creates a persistent, queryable project state that updates in real-time."

Messaging Framework

Message Hierarchy:

Core Message (One-liner)

• "Eliminate status meetings with real-time project visibility"

Supporting Messages:

• "Keep everyone in sync without synchronous meetings"
• "Cut meeting time by 50% while improving alignment"
• "Build an asynchronous-first team"
• "Know project status instantly from anywhere"

Audience-Specific Messages:

For Engineering Leads:

• Focus: Productivity gains, tool consolidation
• Message: "Stop switching between tools to get status"

For Managers:

• Focus: Team alignment, visibility
• Message: "See what your team is doing without asking"

For C-suite:

• Focus: ROI, efficiency
• Message: "Reduce meeting overhead, improve productivity"

For Individual Contributors:

• Focus: Ease of use, personal efficiency
• Message: "Get work done faster with better visibility"

Channel and Timing Strategy

Launch channels:

• Email (existing customers): Week 1
• In-product (feature flag, highlight): Week 1
• Sales team: Week 1 (for new sales)
• Marketing: Blog post, social media, Week 1-2
• Press/media: Day 1 (coordinated announcement)
• Community/events: Weeks 1-2

Timing consideration:

• Avoid holidays, competitor launches, industry conferences
• Consider customer business cycles
• Target day of week: Tuesday-Thursday (engagement)
• Target time: 9-11 AM (when users online)

Beta Testing Program (2-3 weeks)

Beta Participant Selection

Participant tiers:

Tier 1: Lighthouse customers (5-10)

• Most enthusiastic early adopters
• Willing to provide detailed feedback
• Access to decision-makers for follow-ups
• Commitment: Daily testing, weekly feedback calls

Tier 2: Early adopter customers (20-30)

• Strong product advocates
• Regular users of current features
• Engaged customer community
• Commitment: 3-4x per week testing

Tier 3: Interested customers (50-100)

• Curious about new features
• Broad user base for feedback
• Less intensive commitment
• Commitment: Try at least once, optional feedback

Selection criteria:

• Existing customer (for product features)
• Active/engaged users
• Willingness to participate
• Geographic/segment diversity
• Mix of power users and new users

Beta Program Communication

Beta Kickoff Email:

Subject: "You're Invited to Beta Test [Feature Name]"

"Hi [Name],

We're excited to invite you to our private beta for [Feature Name] launching [date].

What's it about:

[2-3 sentence description of feature and benefit]

Why we're asking you:

You're one of our most engaged customers, and your feedback will help us make this feature amazing.

What we need:

• Try [feature] over the next 2 weeks
• Share feedback via [form/survey/call]
• Report any bugs or issues
• Expected time commitment: 30 minutes

What's in it for you:

• Early access to the feature
• Direct influence on our roadmap
• [Early bird pricing/exclusive benefits]

Get started:

• Access beta at [link]
• Complete [onboarding/setup]
• Share feedback via [link]

Have questions? Reply to this email.

Thanks for being an awesome customer!

[PM name]"

Beta Feedback Collection

Feedback form structure:

• Feature Usability (Rate 1-5)
• "How easy was it to learn?"
• "Was the workflow intuitive?"
• "Did it work as you expected?"

• Value/Benefit (Rate 1-5)
• "How useful is this feature?"
• "How likely to use regularly?"
• "Worth the effort to learn?"

• Open-ended questions:
• "What did you like most?"
• "What was confusing?"
• "What would make it better?"
• "Who else should have this?"

• Bugs and issues:
• "Did you encounter any errors?"
• "Did anything break or not work?"
• "Any performance issues?"

Feedback analysis:

• Compile feedback into themes
• Calculate NPS for feature (how likely to recommend)
• Identify critical bugs vs. nice-to-haves
• Plan iterations based on feedback

Beta Iteration Plan

Response time for critical bugs: 24 hours

• Show beta participants you're responsive
• Build goodwill for launch feedback
• Demonstrate commitment to quality

Iteration cadence:

• Daily: Monitor for critical bugs, respond immediately
• 2-3x per week: Non-critical improvements
• Weekly: Gather feedback, plan iterations
• Mid-beta: Major feedback-driven improvements

Beta success criteria:

• 90%+ of participants try feature
• 70%+ would recommend (NPS 50+)
• All critical bugs fixed
• No deal-breaker feedback
• Performance within targets

Launch Week Preparation

Launch Day Checklist (1 week before)

Engineering:

• [ ] Feature code complete and merged
• [ ] All tests passing (unit, integration, e2e)
• [ ] Load testing completed, results reviewed
• [ ] Deployment runbook written and tested
• [ ] Rollback plan documented
• [ ] Monitoring and alerts configured
• [ ] Feature flags configured for gradual rollout
• [ ] Database migrations tested
• [ ] API contracts finalized and documented

Product:

• [ ] Feature documentation written (help center, in-app tooltips)
• [ ] Acceptance criteria all met
• [ ] Success metrics defined and tracked
• [ ] Launch checklist review completed
• [ ] FAQ prepared for support team
• [ ] Launch talking points finalized
• [ ] Key stakeholder communication scheduled
• [ ] Post-launch measurement plan reviewed

Design:

• [ ] UI finalized and reviewed
• [ ] Edge cases and error states designed
• [ ] Accessibility review completed (WCAG 2.1 AA)
• [ ] Mobile/responsive tested
• [ ] Help text and tooltips reviewed
• [ ] Onboarding flow finalized

Marketing:

• [ ] Blog post written and scheduled
• [ ] Email campaign created and queued
• [ ] Social media assets created
• [ ] Announcement copy finalized
• [ ] Press release prepared
• [ ] Website updates ready to deploy
• [ ] Sales enablement materials finalized
• [ ] Customer communication timeline approved

Sales:

• [ ] Sales team trained on feature
• [ ] Competitive differentiation messaging ready
• [ ] Sales collateral prepared (one-pagers, decks)
• [ ] New customer positioning updated
• [ ] Upsell strategy finalized
• [ ] Pricing approved (if relevant)

Support:

• [ ] Help documentation written
• [ ] FAQ and common issues documented
• [ ] Support team trained
• [ ] Escalation procedures defined
• [ ] Knowledge base articles created
• [ ] Chat/support software updated
• [ ] Support metrics baseline established

QA:

• [ ] Full regression testing completed
• [ ] Beta feedback bugs fixed
• [ ] Edge cases tested
• [ ] Browser/device compatibility verified
• [ ] Performance testing completed
• [ ] Security testing completed
• [ ] Accessibility testing completed

Launch Communications Timeline

2 weeks before:

• [ ] Alert internal team about launch
• [ ] Send beta participant thank you + early access message
• [ ] Alert customer success team to prepare for questions

1 week before:

• [ ] Confirm all deliverables ready
• [ ] Final review of communications
• [ ] Alert executive team and board
• [ ] Brief sales team on key talking points
• [ ] Prepare support team with resources

Day before (after hours):

• [ ] Deploy to staging for final verification
• [ ] Run smoke tests
• [ ] Final monitoring setup
• [ ] On-call schedule confirmed
• [ ] Communication templates finalized

Launch day (morning):

• [ ] Deploy to production
• [ ] Monitor error rates and performance
• [ ] Verify customer can access
• [ ] Send internal launch notification
• [ ] Monitor social and customer feedback

Launch day (staggered):

• [ ] Email to existing customers (9 AM)
• [ ] In-product announcement (10 AM)
• [ ] Blog post publication (11 AM)
• [ ] Social media posts (ongoing, 2-3x daily)
• [ ] Sales team briefing (2 PM)

Launch Day Operations

War Room Setup

Launch day team:

• On-call engineer (monitor, ready to fix)
• Product Manager (customer feedback, decisions)
• Support lead (monitor and respond to issues)
• Marketing (monitor and amplify)
• Analytics (track metrics in real-time)

Communication:

• Slack channel: #launch-realtime (live updates)
• Email: Escalation to steering committee
• Call: If critical issue discovered

Monitoring metrics:

• Error rate (target: <0.1%)
• Page load time (target: <2s)
• Feature adoption (early adoption rate)
• Bug reports (critical vs. non-critical)
• Customer sentiment (social listening)

Incident Response Protocol

Issue severity levels:

Critical (Fix immediately)

• Feature completely broken for all users
• Major data loss or corruption
• Security vulnerability
• Response: Page on-call engineer, assess feasibility of rollback

High (Fix within hours)

• Feature broken for specific segment
• Significant performance degradation
• Response: Prioritize fix or feature flag off affected area

Medium (Fix within 24 hours)

• Specific edge cases broken
• Minor performance issues
• UI bugs affecting usability
• Response: Add to bug queue, plan fix

Low (Fix in next iteration)

• Minor UI issues
• Edge case edge cases
• Cosmetic problems
• Response: Document for next sprint

Rollback Decision

Consider rollback if:

• Critical bug affecting core workflow
• Data integrity issues
• Security vulnerability
• Performance affecting majority of users

Rollback process:

• Assess severity and impact scope
• Confirm rollback will resolve (don't rollback without plan)
• Execute rollback (pre-tested procedure)
• Communicate to customers
• Schedule hot fix and re-launch

Post-Launch Phase

24-Hour Post-Launch

Monitoring focus:

• Error rates and performance metrics
• Customer issues and support tickets
• Social media and customer sentiment
• Feature adoption rate
• Critical bug assessment

Team debrief (EOD):

• Any issues encountered?
• Response effectiveness?
• Communication assessment?
• Quick fixes needed before day 2?

1-Week Post-Launch

Success metrics review:

• Early adoption rate vs. forecast
• NPS on feature (if surveyed)
• Error/bug rates
• Performance metrics
• Customer feedback themes
• Sales engagement on feature

Customer feedback synthesis:

• What's working well?
• What's confusing?
• What do they want next?
• Segment-specific feedback

Planned iterations:

• Highest-priority improvements
• Timeline for releases
• Customer communication plan

2-4 Week Post-Launch

Feature stabilization:

• All critical bugs fixed
• Performance optimized
• Documentation refined based on support questions
• Team support burden decreased

Expansion planning:

• Early adopter feedback synthesized
• Next phase features planned
• Expansion strategy refined
• Sales/customer success enablement updates

4+ Week Post-Launch

Launch success analysis:

• Did we achieve launch goals?
• Adoption metrics vs. forecast
• Revenue/business impact
• Team learning and retrospective
• Documentation of what worked/didn't

Post-launch metrics dashboard:

Metric                    Target    Actual    Status
─────────────────────────────────────────────────────
Adoption (% of users)      30%       28%       ✓
Daily active use           20%       22%       ✓
Feature NPS               50+        52        ✓
Error rate                <0.1%      0.08%     ✓
Load time (p95)           <2s        1.8s      ✓
Support tickets           <50/day    42        ✓
Customer satisfaction      4.5/5      4.6       ✓
Revenue impact            $50K      $48K       ✓

Launch Communication Templates

Customer Announcement Email

Subject: "Introducing [Feature Name] - Your Request, Our Solution"

Dear [Customer Name],

Based on your feedback and many similar requests from our customers, we're excited to announce [Feature Name], launching [date].

The Problem:

[What problem it solves]

The Solution:

[How feature solves it, benefits]

Available Now:

• [Availability: All customers / Premium plans / Beta]
• [Access: Automatic / Requires setup]

Learn More:

[Link to documentation]

[Link to how-to video]

[Link to webinar]

[Call to action: Try now / Schedule demo]

Best regards,

[PM/Company]

Sales Enablement One-pager

[Feature Name] - Sales Sheet

What is it?

[One-sentence description]

Why does it matter?

• Benefit 1: [Business impact]
• Benefit 2: [Workflow improvement]
• Benefit 3: [Cost/efficiency gain]

Who should care?

• [Buyer persona]: [Specific relevance]
• [Buyer persona]: [Specific relevance]

Competitive advantage:

• vs. Competitor A: [Differentiator]
• vs. Competitor B: [Differentiator]
• vs. Status quo: [Differentiator]

Key talking points:

• [Point 1]
• [Point 2]
• [Point 3]

Objection handling:

• Objection: "We use [alternative]"

Response: [How we're different/better]

Resources:

• Demo: [Link]
• One-pager: [Link]
• ROI calculator: [Link]
• Case study: [Link]

Launch Readiness Review

Launch readiness checklist (done 1 week before):

• [ ] Product team: Feature complete, tested, documented
• [ ] Engineering: Code merged, tested, monitored
• [ ] Design: UI finalized, accessibility reviewed
• [ ] Marketing: Communications ready, assets created
• [ ] Sales: Trained, materials ready, positioned
• [ ] Support: Trained, documentation ready, capacity planned
• [ ] Analytics: Metrics defined, dashboards built, tracking confirmed
• [ ] Legal/compliance: Reviewed and approved
• [ ] Management: Briefed and aligned
• [ ] All teams: Launch date and timeline confirmed
• [ ] Contingency plans: Rollback and escalation procedures defined
• [ ] On-call schedule: Confirmed for launch week
• [ ] Customer communication: Approved and scheduled
• [ ] Success criteria: Defined and documented

Launch readiness score:

• 100% = Go (all green)
• 90% = Go with caution (monitor 1-2 items)
• 80% = Consider delaying (must resolve before launch)
• <80% = Do not launch (resolve issues first)

Output Deliverables

• Launch Plan - Full timeline, strategy, decisions
• GTM Strategy - Messaging, positioning, channels
• Beta Testing Plan - Participants, feedback process, timeline
• Communications Calendar - All launch announcements scheduled
• Launch Checklist - Teams and dates verified ready
• War Room Setup - Team structure, communication, monitoring
• Support Materials - FAQ, documentation, onboarding
• Sales Enablement - One-pagers, talking points, collateral
• Launch Metrics Dashboard - KPIs, definitions, tracking

10. Post-Launch Analysis - Success review, learnings, improvements