product-launch-manager

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Product Launch Manager

产品发布经理

Strategic product launch expertise for technology companies — from launch planning and tiering to execution, monitoring, and retrospectives.

为科技公司提供专业的产品发布战略支持——从发布规划、分层到执行、监控及复盘全流程覆盖。

Philosophy

核心理念

Great launches aren't about the big bang. They're about orchestrated precision that maximizes impact while minimizing risk.

The best product launches:

Tier based on impact — Not every feature deserves a keynote
Coordinate ruthlessly — Cross-functional alignment is non-negotiable
Validate before announcing — Beta programs de-risk everything
Plan for failure — Rollback plans aren't pessimism, they're professionalism
Measure what matters — Success criteria before, not after, launch

优秀的产品发布不在于“大爆炸式”的噱头，而在于精准协调，在最大化影响力的同时将风险降至最低。

最佳产品发布具备以下特征：

按影响力分层 —— 并非每个功能都值得举办主题演讲
严格跨职能协调 —— 跨团队对齐是必不可少的要求
官宣前先验证 —— Beta项目能全方位降低风险
为失败做好预案 —— 回滚计划不是悲观，而是专业的体现
衡量关键指标 —— 在发布前就明确成功标准

How This Skill Works

该技能的运作方式

When invoked, apply the guidelines in

rules/

organized by:

```
planning-*
```
— Launch strategy, tiering, timelines, success criteria
```
coordination-*
```
— Cross-functional alignment, RACI, stakeholder management
```
beta-*
```
— Early access programs, beta cohorts, feedback loops
```
communication-*
```
— Internal enablement, external messaging, launch comms
```
execution-*
```
— Launch day operations, war rooms, monitoring
```
postlaunch-*
```
— Retrospectives, metrics analysis, iteration

调用时，需遵循

rules/

目录下的分类指南：

```
planning-*
```
—— 发布策略、分层、时间线、成功标准
```
coordination-*
```
—— 跨职能对齐、RACI、利益相关者管理
```
beta-*
```
—— 早期访问项目、Beta用户群体、反馈闭环
```
communication-*
```
—— 内部赋能、外部 messaging、发布沟通
```
execution-*
```
—— 发布日运营、作战室、监控
```
postlaunch-*
```
—— 复盘、指标分析、迭代

Core Frameworks

核心框架

Launch Tier Model

发布分层模型

Tier	Criteria	Timeline	Channels	Example
Tier 1	New product, major platform shift	8-12 weeks	Full press, event, keynote	New product line
Tier 2	Major feature, significant expansion	4-8 weeks	Blog, email, social, PR	Enterprise feature
Tier 3	Feature enhancement, integration	2-4 weeks	Blog, changelog, email	New integration
Tier 4	Bug fix, minor improvement	1-2 weeks	Changelog, in-app	UI improvement

层级	判定标准	时间周期	渠道	示例
Tier 1	全新产品、重大平台升级	8-12周	全渠道媒体、线下活动、主题演讲	全新产品线
Tier 2	重大功能、显著业务拓展	4-8周	博客、邮件、社交媒体、PR	企业级功能
Tier 3	功能增强、集成对接	2-4周	博客、更新日志、邮件	新集成功能
Tier 4	Bug修复、小幅优化	1-2周	更新日志、应用内通知	UI优化

Launch Readiness Model

发布就绪模型

┌─────────────────────────────────────────────────────────┐
│                    LAUNCH READINESS                      │
├─────────────────────────────────────────────────────────┤
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
│  │ Product │  │Marketing│  │  Sales  │  │ Support │    │
│  │  Ready  │  │  Ready  │  │  Ready  │  │  Ready  │    │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘    │
│       │            │            │            │          │
│       └────────────┴─────┬──────┴────────────┘          │
│                          │                              │
│                    ┌─────▼─────┐                        │
│                    │  GO/NO-GO │                        │
│                    │  DECISION │                        │
│                    └───────────┘                        │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│                    LAUNCH READINESS                      │
├─────────────────────────────────────────────────────────┤
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
│  │ Product │  │Marketing│  │  Sales  │  │ Support │    │
│  │  Ready  │  │  Ready  │  │  Ready  │  │  Ready  │    │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘    │
│       │            │            │            │          │
│       └────────────┴─────┬──────┴────────────┘          │
│                          │                              │
│                    ┌─────▼─────┐                        │
│                    │  GO/NO-GO │                        │
│                    │  DECISION │                        │
│                    └───────────┘                        │
└─────────────────────────────────────────────────────────┘

Launch RACI Matrix

发布RACI矩阵

Activity	Product	Marketing	Sales	Support	Eng	Exec
Feature requirements	A	C	C	C	R	I
Launch tier decision	R	C	C	I	C	A
Launch date	R	C	I	I	C	A
External messaging	C	R	C	I	I	A
Internal enablement	C	R	R	R	I	I
Technical readiness	C	I	I	I	R	A
Support documentation	C	I	I	R	C	I
Go/no-go decision	R	R	R	R	R	A

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

活动	产品团队	营销团队	销售团队	支持团队	工程团队	高管团队
功能需求	A	C	C	C	R	I
发布层级决策	R	C	C	I	C	A
发布日期	R	C	I	I	C	A
外部messaging	C	R	C	I	I	A
内部赋能	C	R	R	R	I	I
技术就绪	C	I	I	I	R	A
支持文档	C	I	I	R	C	I
发布与否决策	R	R	R	R	R	A

R = 负责（Responsible），A = 问责（Accountable），C = 咨询（Consulted），I = 告知（Informed）

Launch Timeline Template

发布时间线模板

Week -8: Launch brief, tier decision, stakeholder alignment
Week -6: Beta program begins, messaging draft
Week -4: Sales/support enablement starts, PR outreach
Week -2: Go/no-go checkpoint, final content review
Week -1: War room setup, monitoring configured, runbook complete
Day 0:   LAUNCH
Week +1: Post-launch monitoring, quick fixes
Week +2: Launch retrospective, metrics review

第-8周：发布 brief、层级决策、利益相关者对齐
第-6周：Beta项目启动、messaging初稿
第-4周：销售/支持赋能启动、PR推广
第-2周：发布与否 checkpoint、最终内容审核
第-1周：作战室搭建、监控配置完成、运行手册定稿
第0天：正式发布
第+1周：发布后监控、快速修复
第+2周：发布复盘、指标回顾

Success Criteria Framework

成功标准框架

Category	Metric Type	Example
Adoption	Usage metrics	DAU, feature adoption rate, activation
Quality	Stability metrics	Error rate, P0 incidents, rollback rate
Business	Revenue metrics	Conversion, upsell, pipeline influence
Sentiment	Feedback metrics	NPS, support tickets, social sentiment

类别	指标类型	示例
用户采用	使用指标	DAU、功能采用率、激活率
产品质量	稳定性指标	错误率、P0级故障、回滚率
业务价值	营收指标	转化率、增购率、销售线索影响力
用户反馈	舆情指标	NPS、支持工单量、社交舆情

Communication Templates

沟通模板

Launch Brief Structure

发布Brief结构

1. Executive Summary
2. Launch Tier & Rationale
3. Target Audience
4. Key Messages (3 max)
5. Success Criteria
6. Timeline & Milestones
7. RACI & Stakeholders
8. Risks & Mitigations
9. Budget (if applicable)
10. Approval Sign-offs

1. 执行摘要
2. 发布层级及理由
3. 目标受众
4. 核心Messages（最多3条）
5. 成功标准
6. 时间线及里程碑
7. RACI及利益相关者
8. 风险及缓解方案
9. 预算（如适用）
10. 审批签字

Go/No-Go Checklist

发布与否 checklist

□ Product: Feature complete and tested
□ Product: Performance benchmarks met
□ Engineering: Rollback plan documented
□ Engineering: Monitoring/alerts configured
□ Marketing: All content published/scheduled
□ Marketing: PR embargo lifted
□ Sales: Enablement complete, battlecards ready
□ Support: Documentation live, team trained
□ Legal: Compliance review complete
□ Exec: Final approval received

□ 产品团队：功能开发完成并通过测试
□ 产品团队：性能基准达标
□ 工程团队：回滚计划已文档化
□ 工程团队：监控/告警已配置
□ 营销团队：所有内容已发布/排期
□ 营销团队：PR embargo已解除
□ 销售团队：赋能完成、作战卡片就绪
□ 支持团队：文档已上线、团队已培训
□ 法务团队：合规审核完成
□ 高管团队：最终审批已获取

Anti-Patterns

反模式

Launch without tiers — Treating every release like a Tier 1 burns out teams and audiences
Big bang only — Skipping beta means learning in production
Engineering complete = launch ready — Code done ≠ market ready
No rollback plan — Hope is not a strategy
Post-hoc success criteria — Defining success after launch is rationalization
Siloed launches — Marketing finds out when customers do
Launch and leave — No post-launch monitoring or iteration
Vanity launch metrics — Press mentions ≠ product success

无分层发布 —— 把每个版本都当成Tier 1发布，会让团队和受众疲惫不堪
仅依赖大爆炸式发布 —— 跳过Beta阶段意味着在生产环境中试错
认为开发完成=发布就绪 —— 代码完成≠市场就绪
无回滚计划 —— 指望运气不是策略
事后定义成功标准 —— 发布后再定义成功只是自我合理化
孤岛式发布 —— 营销团队和客户同时得知发布消息
发布后不管不问 —— 没有发布后监控或迭代
虚荣发布指标 —— 媒体提及≠产品成功