product-launch-manager

产品发布经理

为科技公司提供战略性产品发布专业知识——涵盖发布规划与分级、执行、监控和复盘。

理念

出色的发布并非追求轰动效应，而是通过精密协同，在最大化影响的同时将风险降至最低。

优秀的产品发布应当：

1. 根据影响力分级——并非每项功能都值得在主题演讲中发布
2. 严格协调——跨职能协同不可或缺
3. 公布前先验证——Beta 计划可以降低各种风险
4. 为失败做好准备——回滚计划不是悲观，而是专业
5. 衡量重要指标——在发布前，而不是发布后，制定成功标准

此技能的工作方式

调用时，请应用 rules/ 中的指南，分类如下：

• planning-* — 发布策略、分级、时间线、成功标准
• coordination-* — 跨职能协同、RACI、利益相关者管理
• beta-* — 早期访问计划、Beta 用户群、反馈循环
• communication-* — 内部赋能、外部信息传达、发布沟通
• execution-* — 发布日运营、战情室、监控
• postlaunch-* — 复盘、指标分析、迭代

核心框架

发布分级模型

级别	标准	时间线	渠道	示例
Tier 1	新产品、重大平台转型	8-12 周	全面媒体宣传、活动、主题演讲	新产品线
Tier 2	重大功能、显著扩展	4-8 周	博客、电子邮件、社交媒体、公关	企业功能
Tier 3	功能增强、集成	2-4 周	博客、更新日志、电子邮件	新集成
Tier 4	Bug 修复、小幅改进	1-2 周	更新日志、应用内	UI 改进

发布准备度模型

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

发布 RACI 矩阵

活动	产品	市场营销	销售	支持	工程	高管
功能需求	A	C	C	C	R	I
发布级别决策	R	C	C	I	C	A
发布日期	R	C	I	I	C	A
外部信息传达	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 = 负责执行，A = 最终负责，C = 征询意见，I = 知会

发布计划模板

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

成功标准框架

类别	指标类型	示例
采用情况	使用情况指标	DAU、功能采用率、激活
质量	稳定性指标	错误率、P0 事件、回滚率
业务	收入指标	转化率、追加销售、对销售管道的影响
情绪反馈	反馈指标	NPS、支持工单、社交媒体情绪

沟通模板

发布简报结构

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

是否发布检查清单

□ 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

反模式

• 发布不分级——把每次发布都当作 Tier 1，会让团队和受众疲惫不堪
• 只追求一次性全面发布——跳过 Beta，就意味着在生产环境中摸索
• 工程完成 = 可以发布——代码完成 ≠ 面向市场的准备就绪
• 没有回滚计划——寄希望于运气不是策略
• 事后制定成功标准——发布后才定义成功，是在为结果找理由
• 信息孤岛式发布——市场营销团队和客户同时得知发布消息
• 发布后不管——缺少发布后的监控和迭代
• 虚荣发布指标——媒体提及 ≠ 产品成功