technical-launch-planner skill

---
name: technical-launch-planner
description: Plan and execute technical product launches for developer tools, APIs, and technical products. Use this skill when technical PMMs need to "plan a launch", "create a launch strategy", "coordinate a product release", or "prepare for GA/beta launch".
---

# Technical Launch Planner

## Overview

Plan and execute successful launches for technical products, developer tools, APIs, SDKs, and platforms. This skill provides frameworks, checklists, and templates specifically designed for technical audiences and developer-focused products.

**Built for:**
- Developer tools and platforms
- APIs and SDKs
- Technical infrastructure products
- B2D (Business-to-Developer) products
- SaaS with technical buyers

---

## Quick Start

### 1. Assess Your Launch Tier

Run the interactive assessment:

```bash
scripts/assess_launch_tier.sh
```

This determines if your launch is:
- **Tier 1** (Major/GA) - New product, major version, significant expansion
- **Tier 2** (Standard) - New features, integrations, regional expansion
- **Tier 3** (Minor) - Updates, improvements, small features

### 2. Generate Launch Plan

Create your comprehensive launch plan:

```bash
scripts/generate_launch_plan.sh
```

Provides structured plan with:
- Timeline and milestones
- Stakeholder responsibilities
- Developer enablement checklist
- Go-to-market activities
- Launch day playbook

### 3. Validate Readiness

Before launch, check readiness:

```bash
scripts/validate_readiness.sh
```

Validates:
- Documentation completeness
- Technical assets ready
- Stakeholder alignment
- Messaging finalized
- Metrics instrumentation

---

## Core Launch Framework

### Launch Tiers

Different launches require different levels of investment:

| Tier | Type | Examples | Investment |
|------|------|----------|------------|
| **Tier 1** | Major | GA launch, new product, major version | Full GTM, events, PR |
| **Tier 2** | Standard | New features, integrations, SDKs | Selective GTM, blog, docs |
| **Tier 3** | Minor | Updates, improvements, patches | Changelog, in-app |

See `references/launch_tiers.md` for complete framework.

---

## Developer-Focused Launch Components

### 1. Developer Enablement

**Critical for technical launches:**

**Documentation:**
- Getting started guide
- API reference
- Code samples
- Integration guides
- Migration guides (if applicable)

**Code Assets:**
- SDKs/client libraries
- Sample applications
- Starter templates
- Code snippets

**Developer Experience:**
- Sandbox/playground environment
- Interactive tutorials
- API explorer
- Debugging tools

See `references/developer_enablement.md` for complete checklist.

---

### 2. Technical Messaging

**Speak developer language:**

**Avoid:**
- Marketing jargon
- Vague benefits
- Non-technical superlatives

**Include:**
- Concrete technical details
- Performance metrics
- Code examples
- Architecture diagrams
- Integration patterns

See `references/launch_messaging.md` for templates.

---

### 3. Launch Channels for Developers

**Where developers discover new tools:**

**Primary:**
- Developer documentation
- GitHub/GitLab
- Developer blog
- API changelog
- Release notes

**Secondary:**
- Dev.to, Hacker News, Reddit
- Technical Twitter/X
- Discord/Slack communities
- YouTube (tutorials)
- Developer newsletters

**Tertiary:**
- Webinars/workshops
- Conferences
- Podcasts
- Case studies

---

## Launch Planning Workflow

### Phase 1: Planning (T-12 to T-8 weeks)

**Objectives:**
- Define launch tier
- Set success criteria
- Align stakeholders
- Create timeline

**Activities:**
1. **Launch Tier Assessment**
   ```bash
   scripts/assess_launch_tier.sh
   ```

2. **Stakeholder Kickoff**
   - Product/Engineering
   - Developer Relations
   - Sales Engineering
   - Marketing/Comms
   - Partners (if applicable)

3. **Define Success Metrics**
   - Developer adoption metrics
   - API usage/calls
   - SDK downloads
   - Documentation traffic
   - Community engagement

4. **Create Launch Timeline**
   ```bash
   scripts/generate_launch_plan.sh
   ```

---

### Phase 2: Build (T-8 to T-4 weeks)

**Objectives:**
- Create all launch assets
- Prepare documentation
- Build demos and samples

**Activities:**

**Documentation:**
- [ ] Getting started guide written
- [ ] API reference complete
- [ ] Integration guides ready
- [ ] Migration guide (if needed)
- [ ] Troubleshooting FAQ

**Code Assets:**
- [ ] SDKs built and tested
- [ ] Sample apps created
- [ ] Code snippets prepared
- [ ] Sandbox environment ready

**Marketing Assets:**
- [ ] Technical blog post written
- [ ] Demo video recorded
- [ ] Announcement email drafted
- [ ] Social media plan
- [ ] Press release (Tier 1)

**Sales Enablement:**
- [ ] Technical battlecard
- [ ] Demo script
- [ ] FAQ/objection handling
- [ ] Pricing materials
- [ ] Competitive positioning

---

### Phase 3: Prepare (T-4 to T-1 weeks)

**Objectives:**
- Review and refine all assets
- Train teams
- Pre-launch validation

**Activities:**

**Internal Enablement:**
- [ ] Sales team training
- [ ] Support team training
- [ ] Partner briefings
- [ ] Internal demo day

**External Prep:**
- [ ] Beta customers briefed
- [ ] Partners coordinated
- [ ] Developer advocates prepared
- [ ] Community moderators ready

**Technical Validation:**
```bash
scripts/validate_readiness.sh
```

**Pre-Launch Checklist:**
- [ ] All docs published to staging
- [ ] SDKs tagged and ready
- [ ] Demo environment tested
- [ ] Monitoring/analytics configured
- [ ] Support escalation path defined

---

### Phase 4: Launch (Launch Day)

**Launch Day Playbook:**

**Morning (9 AM):**
- [ ] Publish documentation
- [ ] Release SDKs/packages
- [ ] Deploy blog post
- [ ] Send announcement email
- [ ] Post to social media
- [ ] Update website/product pages

**Midday (12 PM):**
- [ ] Monitor metrics dashboard
- [ ] Respond to community questions
- [ ] Share to external communities
- [ ] Engage with social mentions

**Afternoon (3 PM):**
- [ ] Post to Hacker News/Reddit (if Tier 1)
- [ ] Developer advocate content
- [ ] Partner announcements

**End of Day:**
- [ ] Day 1 metrics report
- [ ] Team debrief
- [ ] Issue triage

---

### Phase 5: Post-Launch (T+1 week to T+4 weeks)

**Objectives:**
- Monitor adoption
- Gather feedback
- Iterate on messaging
- Report results

**Activities:**

**Week 1:**
- [ ] Daily metrics monitoring
- [ ] Community Q&A
- [ ] Bug fixes prioritized
- [ ] Feedback synthesis

**Week 2:**
- [ ] First adoption metrics
- [ ] Customer feedback interviews
- [ ] Documentation updates
- [ ] Follow-up content

**Week 4:**
- [ ] Launch retrospective
- [ ] Success metrics report
- [ ] Lessons learned doc
- [ ] Update launch playbook

---

## Launch Tier Details

### Tier 1: Major Launch

**When:**
- New product GA
- Major version release (v2.0, v3.0)
- Significant platform expansion
- Game-changing feature

**Timeline:** 12-16 weeks

**Investment:**
- Full cross-functional GTM
- PR/media outreach
- Developer events
- Partner coordination
- Paid promotion

**Deliverables:**
- Complete documentation
- Multiple SDKs
- Sample applications
- Video tutorials
- Interactive demos
- Press release
- Analyst briefings
- Launch event/webinar
- Partner co-marketing

---

### Tier 2: Standard Launch

**When:**
- New features
- New integrations
- Additional SDKs
- Regional expansion

**Timeline:** 6-8 weeks

**Investment:**
- Selective GTM activities
- Blog and social
- Email to developer list
- Documentation updates

**Deliverables:**
- Feature documentation
- Code samples
- Blog post
- Demo video
- Email announcement
- Social media
- Changelog entry

---

### Tier 3: Minor Launch

**When:**
- Incremental improvements
- Bug fixes
- Performance enhancements
- Small feature additions

**Timeline:** 2-4 weeks

**Investment:**
- Minimal marketing
- Documentation only
- Changelog

**Deliverables:**
- Release notes
- Updated docs
- Changelog entry
- In-app notification (if applicable)

---

## Developer Launch Best Practices

### 1. Documentation First

**Launch is NOT ready without:**
- ✅ Getting started guide
- ✅ API reference
- ✅ At least 3 code samples
- ✅ Integration guide

**Developer rule:** "If it's not documented, it doesn't exist"

---

### 2. Show, Don't Tell

**Developers want to see code:**

**Good:**
```python
# Initialize the SDK
import acme_sdk

client = acme_sdk.Client(api_key="your_key")
result = client.widgets.create(name="My Widget")
print(result.id)
```

**Bad:**
"Our SDK makes it easy to create widgets with just a few lines of code"

---

### 3. Interactive > Passive

**Engagement hierarchy:**
1. 🥇 Interactive tutorial/playground
2. 🥈 Live demo
3. 🥉 Demo video
4. ❌ Static screenshots

---

### 4. Honest Technical Communication

**Developers appreciate:**
- Limitations clearly stated
- Performance characteristics
- Pricing transparency
- Migration complexity
- Breaking changes

**Developers hate:**
- Overpromising
- Hidden limitations
- Surprise breaking changes
- Vendor lock-in

---

### 5. Community-First Approach

**Engage where developers are:**
- Answer questions on Stack Overflow
- Be active in GitHub discussions
- Respond on Hacker News
- Join relevant Discord/Slack
- Participate in Reddit AMAs

**Don't:**
- Spam communities
- Ignore negative feedback
- Delete critical comments
- Only show up for launches

---

## Technical Metrics

### Developer Adoption Metrics

**Activation:**
- Sandbox/trial sign-ups
- First API call within 24 hours
- SDK downloads
- "Hello World" completions

**Engagement:**
- Daily/Weekly Active Developers
- API calls per developer
- Features adopted
- Integration depth

**Retention:**
- Day 7, 30, 90 developer retention
- Churn rate
- NPS (Developer)

See `references/metrics_frameworks.md` for complete guide.

---

## Launch Templates

### Technical Blog Post Template

```markdown
# Introducing [Feature/Product]

## The Problem

[Describe the developer pain point in technical detail]

## The Solution

[High-level technical overview]

## How It Works

[Technical architecture, with diagram]

## Getting Started

[Code sample showing basic usage]

## What's Next

[Roadmap tease]

[Link to full documentation]
```

---

### Launch Email Template

**Subject:** [Feature] is now available

**Body:**
```
Hi [Developer Name],

We're excited to announce [Feature] is now generally available.

What it does:
[One sentence technical description]

Why it matters:
[Developer benefit]

Get started in 5 minutes:
[Code snippet or quick start link]

Key resources:
- Documentation: [link]
- Sample code: [link]
- API reference: [link]

Questions? Reply to this email or join us in [Discord/Slack].

Happy building!
[Your Name]
```

---

### Changelog Entry Template

```markdown
## [Version] - YYYY-MM-DD

### Added
- [New feature]: [Technical description]
  - Example: `client.newMethod(params)`
  - [Link to docs]

### Changed
- [Breaking change]: [What changed and why]
  - Migration guide: [link]

### Fixed
- [Bug fix]: [What was fixed]

### Deprecated
- [Feature]: [Timeline for removal]
```

---

## Partner/Integration Launches

### When You Have Partners

**Coordination needed:**
- Joint messaging
- Co-marketing plan
- Technical validation
- Mutual customer references

**Partner Enablement:**
- [ ] Technical integration tested
- [ ] Partner documentation
- [ ] Joint case study
- [ ] Co-branded assets
- [ ] Sales team training

**Launch Activities:**
- Co-authored blog posts
- Joint webinar
- Cross-promotion on social
- Email to both lists
- Mutual press release (Tier 1)

---

## Launch Retrospective

### Post-Launch Review (Within 30 days)

**Metrics Review:**
- Did we hit adoption targets?
- What was Day 1, Week 1, Month 1 usage?
- Developer sentiment (NPS, social, support)?
- Press/analyst coverage (if applicable)?

**What Worked:**
- Which channels drove most adoption?
- What content resonated?
- Which enablement assets were most used?

**What Didn't:**
- Where did developers get stuck?
- What documentation was missing?
- Which assumptions were wrong?

**Action Items:**
- Documentation improvements
- Messaging refinements
- Process improvements for next launch

**Template:** [Document in Notion/Confluence]

---

## Common Pitfalls

### Pitfall 1: Launching Without Complete Docs

**Problem:** "Docs will be ready soon" = Dead launch

**Solution:** Docs are non-negotiable. Delay launch if needed.

---

### Pitfall 2: Marketing-Speak for Developers

**Problem:** "Revolutionary", "Seamless", "Game-changing"

**Solution:** Use concrete technical language, metrics, code.

---

### Pitfall 3: Ignoring Migration Complexity

**Problem:** Breaking changes with no migration guide

**Solution:** Clear migration guide, migration tools, version support plan.

---

### Pitfall 4: Over-Indexing on Launch Day

**Problem:** All effort on Day 1, nothing for ongoing adoption

**Solution:** Plan 4-week post-launch content calendar.

---

### Pitfall 5: No Developer Feedback Loop

**Problem:** Launch and disappear

**Solution:** Active community engagement, regular office hours.

---

## Resources

### Scripts

- **assess_launch_tier.sh** - Determine appropriate launch tier
- **generate_launch_plan.sh** - Create comprehensive launch plan
- **validate_readiness.sh** - Pre-launch readiness check

### References

- **launch_tiers.md** - Complete launch tier framework
- **developer_enablement.md** - Developer enablement checklist
- **launch_messaging.md** - Technical messaging templates
- **metrics_frameworks.md** - Developer product metrics guide

---

## Real-World Examples

### Example 1: API GA Launch (Tier 1)

**Product:** New REST API for developer platform

**Timeline:** 12 weeks

**Key Activities:**
- Complete API documentation
- 5 SDKs (Python, Node, Ruby, Go, Java)
- Interactive API explorer
- 10+ sample applications
- Video tutorial series
- Developer webinar
- Blog post + case studies
- HN/Reddit launch
- Email to 50K developers

**Results:**
- 10K API keys issued Week 1
- 60% activation rate (first API call)
- 40% Day 7 retention
- #1 on Hacker News

---

### Example 2: New Integration (Tier 2)

**Product:** Integration with popular DevOps tool

**Timeline:** 6 weeks

**Key Activities:**
- Integration guide
- Sample workflow
- Blog post
- Partner co-marketing
- Demo video
- Email announcement

**Results:**
- 2K integration activations Month 1
- 25% of existing users tried it
- High engagement metric

---

### Example 3: SDK Update (Tier 3)

**Product:** New SDK version with performance improvements

**Timeline:** 2 weeks

**Key Activities:**
- Release notes
- Migration guide
- Changelog
- Tweet/X post

**Results:**
- 30% upgrade rate Week 1
- Minimal support burden
- Positive community feedback

---

## Summary

Technical launches require:

1. **Complete Documentation** - Non-negotiable
2. **Code Samples** - Show, don't tell
3. **Developer Enablement** - Make it easy to try
4. **Technical Credibility** - Speak the language
5. **Community Engagement** - Be where developers are
6. **Clear Metrics** - Measure what matters
7. **Post-Launch Commitment** - Launch is day 1, not the finish line

Use the scripts to streamline planning, follow the frameworks for consistency, and always put developers first.

**Get started:**
```bash
scripts/assess_launch_tier.sh
```