feature-launch-playbook

功能发布实战指南

一位资深产品经理领导者撰写的实战指南，教你如何做好功能发布，而不只是把功能交付出去。

大多数团队会混淆交付、上线和发布。交付意味着工程工作已完成。上线意味着用户可以使用该功能，即使它只通过功能开关向 1% 的用户开放。发布则是一套完整的工作方法，涵盖定位、内部协同、客户沟通、销售赋能、支持准备、灰度策略、监控和发布后衡量，将“功能已经存在”变成“功能真正发挥了作用”。

功能交付后若没有做好发布，投入的工程成本不会减少，但获得的价值却只有一小部分。销售不知道如何推销它。支持团队不知道如何帮助用户。客户没有注意到它。你承诺要推动的指标没有变化，因为没人知道这个功能已经上线。

本技能是一套实操指南。它假设你已经编写了规格文档（pm-spec-writing）、将其排入路线图（roadmap-planning）、完成了埋点（product-analytics-setup），并且可能已经测试过它（experiment-design）。发布是接下来要掌握的工作方法：如何真正将功能呈现给合适的用户，提供恰当的背景信息，并以便衡量它是否奏效的方式进行发布。

适用场景：规划发布（任何规模、任何用户群体）、审查现有发布流程、解决“功能上线了，但指标没有变化”的问题，或为团队制定发布清单。

---

本技能的用途

本技能涵盖发布的实操工作方法，并与其他产品技能配合使用。

• pm-spec-writing 定义发布假设；本技能负责验证这些假设。
• roadmap-planning 提供发布背景（之前做了什么，接下来做什么）。
• product-analytics-setup 是埋点的前置条件；没有它，就无法衡量发布效果。
• experiment-design 和 data-warehouse-experimentation 提供测试发布是否奏效的方法论。
• feature-flagging 提供本技能所依赖的灰度基础设施。

本技能不涵盖定价决策、品牌营销活动或完整的 GTM 战略。这些需要与营销团队合作；本技能是面向工程和产品团队的产品经理实操指南。

适用对象广泛：每位产品经理都会交付功能，每位产品经理至少有过一次发布不顺利的经历，而每位产品经理都能从一份清单中受益，避免最严重的问题再次发生。以资深产品经理领导者对产品经理的口吻撰写，具体、有主见，并坦诚说明各个阶段最需要哪些工作方法。

---

Ship、release 与 launch

这是最关键的区别。三个定义。

**Ship（交付）**指工程团队完成工作。代码已部署到生产环境。用户尚无法访问，或只有内部用户能通过功能标志访问。PR 已合并并部署。

**Release（开放使用）**指用户可以访问。可能面向 1% 的用户逐步开放，也可能面向 100% 的用户开放。从某种技术意义上说，该功能已“上线”。至少有一位用户可以使用该功能标志。

**Launch（正式推出）**指定位、内部协调、客户沟通、销售赋能、支持准备、发布策略、监控和发布后衡量都已启动。该功能已介绍给可能从中受益的人，并提供了他们使用它所需的背景信息。

问题所在。PM 报告说“我们交付了功能 X”，但实际发生的只是工程团队完成了工作。该功能可能只对 1% 的用户开放，没有公告、文档、销售赋能或衡量计划。从价值获取的角度看，这就是一个未正式推出的功能。

规范。使用准确的术语。“工程团队周二完成交付。我们周四将向 25% 的用户开放。我们计划下个月面向公众正式推出。”这些术语能促使大家如实说明哪些事情已经发生，哪些还没有。

大多数“功能失败”的诊断，最终都会发现问题其实是“功能未正式推出”。这项技能围绕发布维度展开，因为大多数团队在这方面投入不足。

---

发布层级

并非每项功能都需要完整的操作手册。应根据功能匹配相应的工作。

Tier 1（完整发布）。 全新产品、重塑产品叙事的重大功能、定价变更、破坏性变更。使用完整操作手册：定位、所有沟通渠道、销售赋能、客户成功团队简报、专门的发布后衡量、高管公告。

Tier 2（重点发布）。 能显著影响用户价值或竞争定位的重要改进。使用操作手册的部分内容：应用内沟通、博客文章或发布说明、支持准备、发布策略、发布后衡量。

Tier 3（发布说明）。 渐进式改进、修复后效果良好的缺陷、打磨优化。最低限度：更新日志条目、发布说明、轻量级监控。

两种极端都容易踩坑。

• 将每次发布都当作 Tier 1，会造成沟通疲劳。客户会对铺天盖地的公告视而不见；真正的 Tier 1 发布也会淹没在噪声中，失去传播效果。
• 将每次发布都当作 Tier 3，会导致功能未正式推出。功能已交付，指标却没有变化，团队得出“用户不想要它”的结论，但实际原因是“用户根本没被告知”。

根据功能匹配发布层级。这项技能主要涵盖 Tier 1 和 Tier 2。Tier 3 主要是更新日志规范；发布操作手册同样适用，但需精简为更新日志条目和轻量级监控。

详见 references/launch-tier-decision.md。

---

上线前：定位

定位要回答：目标用户是谁、要解决什么问题、为什么是现在，以及用户可感知的承诺是什么。

定位画布。在起草任何传播材料之前，先用一页内容填写完整。

• 目标用户。 用户细分、角色、待完成的工作。描述要足够具体，让销售代表能用一句话说清客户画像。
• 解决的问题。 要具体，用用户的话来描述。不要说“我们提升了生产力”，而要说“每天需要分流 200 张工单的客户支持经理，不逐张打开工单就无法判断哪些情况紧急。”
• 当前替代方案。 用户现在不用这项功能时会怎么做。现状才是真正的竞争对手。
• 用户可感知的承诺。 一句话。用户在实际使用中接触到这项功能时会听到的承诺。
• 证明要点。 三到五项具体能力或成果。要具体，不要只用形容词。
• 反向定位。 明确这是什么、又不是什么，以及它不打算做什么，以免过度承诺。

最常见的定位失败，是目标用户定义得含糊。“这是给 PM 用的”不是目标用户。“这是给客户数在 50 到 500 家之间、需要协调工程和客户成功团队共同讨论路线图的 B2B SaaS PM 用的”才是目标用户。只有足够具体，销售、营销和支持团队才能用同一种语言描述目标用户。

详情见 references/positioning-canvas.md。

---

上线前：内部协同

上线前需要了解相关信息的利益相关方。

• 工程领导层。 后续工作的承接能力、支持升级处理、上线后修复。
• 销售领导层。 更新收入预测、指导交易、评估对销售管道的影响。
• 客户成功领导层。 主动通知客户、挽回有风险的交易、开展扩展对话。
• 营销领导层。 协调付费推广、博客日历、社交媒体发布时间。
• 支持领导层。 培训、常见问题解答、升级处理路径。
• 执行发起人。 了解情况、公开沟通、向投资者或董事会汇报。

执行规范：准备一份统一的内部上线简报，在上线前两到四周（Tier 1）或一周（Tier 2）分发。简报包含一页摘要、常见问题解答、已做出决策的记录，以及上线日历。简报应回答：“这次上线会让我在哪些方面需要改变做法？”

最常见的内部协同失败：上线时销售团队毫不知情。销售团队从询问相关事项的客户那里才得知消息。这会损害大家对下一次上线的信任。解决方法是准备上线简报，并在面向客户上线前一到两周向销售团队进行专项说明。

详情见 references/internal-alignment-checklist.md。

上线前：客户沟通计划

渠道和决策因素。

• 应用内。 覆盖活跃用户的范围最大；适用于产品内部功能。工具提示、横幅、模态框。
• 电子邮件（事务性或营销活动）。 覆盖活跃和非活跃用户的范围都很广；适用于影响现有工作流的重大变更。
• 博客文章。 兼具 SEO、潜在客户开发和叙事传播；适用于有外部宣传内容的 Tier 1 发布。
• 发行说明。 易于发现、归档和查询；适用于所有 Tier 2 及以上发布。通常是客户日后找到的权威参考。
• 社交媒体（LinkedIn、X、Bluesky）。 覆盖现有客户以外的人群；适用于发布具有外部宣传内容或竞争角度的情况。
• 网络研讨会或客户电话会议。 为企业客户提供深入交流；适用于对客户有重大影响的 Tier 1 发布。
• 销售主导的简报。 面向重点客户提供高接触度服务；适用于影响定价、合同或战略定位的发布。

对每个渠道，明确由谁起草、由谁审批、时间安排以及行动号召。

沟通日历的模式。使用一份文档列出所有渠道和日期，并随内部发布简报一同分发。这样可以避免“博客文章已经发布，销售团队却还没收到简报”这类问题。通常的顺序是：先向销售团队简报，再培训支持团队，然后由客户成功团队联系重点客户，最后发布公开沟通内容。

详情见 references/customer-comms-playbook.md。

---

上线前：销售赋能（B2B）

对于 B2B 产品，Tier 1 和大多数 Tier 2 发布都必须进行销售赋能。交付内容如下。

• 单页竞争手册。 包括定位、目标客户、主要异议和佐证材料。销售人员两分钟内即可读完，并能在五分钟内介绍该功能。
• 演示脚本和录制演示。 销售代表可用来向客户进行可复现演示；录制版本可供发布后加入的销售代表使用。
• 定价变更文档（如适用）。没有明确指导，销售代表就无法准确回答定价问题。
• 交易辅导指南。 明确哪些交易会因此推进，哪些会变复杂。适当时列出具体客户名称。
• 内部培训课程（现场或录制），并归档问答内容。销售代表在向客户介绍该功能前，需要有机会提问。

“影子发布”问题：功能已经上线，销售团队却是从产品团队的 Slack 得知此事；没有竞争手册，销售代表要么忽视该功能，要么向客户错误描述。客户因功能承诺与实际情况不符而流失。

对于 B2C 和 PLG 产品，本节大多可跳过。用户就是买家，不存在销售流程。请明确注明这一点，以免相关场景中的 PM 觉得自己漏掉了必要环节。

详情见 references/sales-enablement-template.md。

---

上线前：支持就绪

支持团队往往最先遇到新功能的故障模式。他们需要以下内容。

• 培训（现场或录制），并提供问答环节。内容与销售培训相同，但需针对支持工作流进行调整。
• 常见问题文档，涵盖已知问题、已知限制和上线时的已知 Bug。首周每天更新 FAQ，补充新出现的问题。
• 升级处理路径，用于处理需要工程团队或 PM 介入的问题。明确负责人和响应时限承诺。
• 监控权限，或申请权限的方式。支持代表应能够核实客户的问题是否与该功能有关。

这项规范的要点：支持团队的困惑，就是测试客户的困惑。如果支持团队不了解该功能，客户也不会了解。面向客户的上线沟通发出前，先培训支持团队。

详情见 references/support-readiness-checklist.md。

---

发布日：推出策略

与功能类型相匹配的四种常见模式。

一次性全面推出（大爆发式）。 在单次部署中从 0％ 推进到 100％。适用于与营销活动协调、且公告本身就是推出行动的场景。若漏洞会影响大量客户，则风险很高。谨慎使用。

按百分比逐步推出。 在数小时或数天内，依次推进到 1％、10％、25％、50％、100％，并在每个阶段进行监控。适用于大多数功能发布；除非有理由采用其他方式，否则应将其作为默认方案。

按标记分群推出。 针对特定用户群体。先面向免费套餐用户，再面向付费用户；先面向小型账户，再面向企业客户。适用于不同用户群体风险特征各异的功能。

分阶段发布（数周）。 先向部分用户、地区或客户推出；收集反馈；迭代；再逐步扩大范围。适用于用户接受度不确定性较高的 Tier 1 发布。

决策框架：功能影响范围 × 对正确性的信心 × 外部承诺。

• 影响范围大、信心低且没有外部承诺：分阶段发布。
• 影响范围小、信心高且有外部发布日期：一次性全面推出。
• 介于两者之间（大多数发布）：按百分比逐步推出。

详情见 references/rollout-strategy-patterns.md。

---

发布日：监控

发布前，确定要监控的指标以及触发警报的条件。常见维度如下。

• 错误率。 总体错误率和功能特定错误率。
• 延迟。 总体延迟和功能特定延迟。
• 功能使用率。 确认应该使用该功能的人确实在使用。
• 漏斗完成率。 用户完成新的流程。
• 支持工单量。 尤其关注带有功能特定标签的工单。
• 客户满意度信号。 NPS 评论、反馈小组件中的提及。

发布前明确设定回滚触发条件。例如：

• “错误率持续 5 分钟高于 1％时，触发回滚。”
• “首小时内提及该功能的支持工单超过 50 个时，触发升级处理。”
• “任何用户群体的漏斗完成率低于发布前基线的 50％时，暂停推出。”

“没有回滚触发条件”的失败情形：发布出现问题。问题不断扩大，团队却花一小时讨论是否回滚。预先设定触发条件可消除争论；规则会自动触发，团队执行回滚。

详情见 references/monitoring-readiness-checklist.md。

---

发布日：沟通执行

客户沟通部分制定的沟通日历将在发布日执行。每个渠道都有明确的负责人、时间和顺序。

• 推出范围达到 X％ 时，启用应用内横幅。
• 稳定运行 4 小时后发送邮件。
• 在内部公布的时间发布博客文章。
• 在公开沟通前一天进行销售简报。
• 在发布前一周进行支持团队培训。

“沟通失误”的失败情形：博客文章按计划自动发布，但推出流程因问题在两小时前已暂停。客户点击后进入的功能对他们仍被标记拦截。他们失去信任；发布叙事也因此破裂。

解决办法：由人工触发外部沟通，并以推出健康检查作为前提。日历中的沟通时间是计划时间；实际发布取决于推出是否通过健康检查。

---

上线后：根据规格假设进行衡量

规格（按照 pm-spec-writing 的要求）应明确说明该功能会带来哪些变化假设。上线衡量计划用于验证或证伪每项假设。

四个衡量维度。

1. 采用情况。 目标用户是否实际使用了该功能？这是触达问题。目标用户群是否能看到该功能，并且是否在尝试使用。
2. 参与度。 尝试过该功能的用户是否再次使用？这是黏性问题。首次使用是必要条件，但并非充分条件。
3. 结果。 规格称该功能会影响的指标是否真的发生了变化？这是效果问题，也是规格中提出的假设。
4. 副作用。 是否有其他不该变化的指标发生了变化？这是安全性问题。有时功能本身有效，却破坏了其他方面。

时间跨度。大多数上线后需要两到四周的数据来观察参与度信号，四到八周的数据来观察结果信号。不要过早判定成功或失败。

“没有衡量计划”的失败情形：功能上线后，团队转而处理其他工作；六个月后，没人知道它是否有效。该功能变成维护负担；团队无法决定是否继续投入。

详情请参阅 references/post-launch-measurement-framework.md。

---

上线后：迭代与后续工作

上线后的前四周内，预计会发现以下情况。

• 在 QA 或有限范围发布中未发现的 Bug。
• 用户研究中未发现的可用性问题。
• 你未曾预料到采用率会偏低的用户群体中的采用率差距。
• 针对相邻能力的功能请求。

应遵循的原则：记录每个问题，每周进行分级，并根据原始衡量计划确定修复优先级。

如果采用率低于目标，应思考：这是营销问题（用户不知道该功能）？可用性问题（用户尝试后便放弃）？价值问题（用户尝试后没有感受到价值）？目标用户群体有误（目标用户并非我们原先认为的那群人）？

每种诊断都对应不同的修复方式。

• 营销问题：增加沟通、重复沟通、重新激活销售。
• 可用性问题：修复设计或引导流程。
• 价值问题：重新设计功能或重新定位。
• 目标用户群体有误：面向不同受众重新调整沟通对象。

“我们宣布胜利”的失败情形：上线指标在第 1 周达到目标（通常是受到上线公告带来的峰值影响）；团队转而处理其他工作；到了第 4 周，指标又回落到基线。虽然上线被报告为成功，但该功能实际上并未真正落地。

解决方法：根据上线后的稳定趋势，而不是上线周的峰值来判定成功或失败。大多数上线项目至少需要四周的稳定趋势，才能可靠地判断成功或失败。

常见失败模式

功能发布中反复出现 12 种模式。详情见 references/common-launch-failures.md。

• “我们发布了，但什么也没发生。”发布未落实。没有沟通计划、内部协同或衡量方案。
• “销售团队一头雾水，推销方式也不对。”没有做好销售赋能。销售作战卡、演示和培训都被跳过或仓促完成。
• “支持团队不堪重负。”没有培训，也没有常见问题解答。客户提出问题时，支持团队才第一次接触这项功能。
• “我们刚推出就立刻回滚了。”没有发布策略，也没有健康检查。一次性全面部署上线后，导致生产环境故障。
• “博客文章发出去了，但功能坏了。”沟通失误。沟通计划没有以发布健康状况为前提。
• “第 1 周的采用情况很好，现在却停滞了。”把发布带来的短暂峰值当成了成功。指标又回到了基线水平。
• “我们不知道这是否有效。”没有与规格假设挂钩的衡量计划。
• “客户说我们没有通知他们。”沟通没有触达正确的客户群体。邮件只发给了活跃用户；非活跃用户没有收到通知。
• “企业客户过了 3 天才从客户经理那里得知消息。”沟通中没有针对高接触度客户的安排。应由销售团队先向重点客户进行简报，再公开沟通。
• “我们的指标变动了，但其实是因为当周发布了另一个功能。”没有隔离影响。无法判断指标变动究竟由本次发布还是同期的其他变更造成。
• “我们发布了错误的功能。”定位不清晰。客户期待的与实际发布的功能不同；预期与现实之间的差距会让发布显得失败，即使功能本身正常运行。
• “功能有效，但公司内部没人知道。”缺少内部协同。销售团队没有在交易中充分利用这项功能；客户成功团队也没有借助它挽留那些因它现在能解决的问题而准备流失的客户。

---

框架：成功发布需考虑的 12 个方面

规划发布时，请逐一考虑以下 12 个方面。跳过任何一项，都可能导致上文所述的失败模式。

1. **划分发布等级。**分为 1 级、2 级或 3 级。根据功能匹配投入。
2. **明确定位。**目标用户、问题、承诺、佐证要点和反向定位。
3. **做好内部协同。**准备一份统一的发布简报，在发布前 2 至 4 周分发。
4. **规划客户沟通。**渠道组合、日程、负责人和关卡。
5. **赋能销售团队。**销售作战卡、演示、培训和交易辅导（仅适用于 B2B）。
6. **做好支持准备。**培训、常见问题解答、升级路径和监控访问权限。
7. **选择发布策略。**一次性全面发布、逐步发布、通过功能标志控制，或分阶段发布。
8. **定义监控方案。**指标、警报和回滚触发条件。预先定义，而不是临时决定。
9. **安排沟通执行顺序。**以健康检查通过为前提。如果发布暂停，绝不能自动触发沟通。
10. **将衡量方案与规格假设挂钩。**采用情况、参与度、结果和副作用。
11. **发布后持续迭代。**每周进行问题分类。区分营销、易用性、价值和客户群体方面的问题。
12. **根据稳定趋势判定成功或失败。**不要依据发布周的峰值。

该框架的产出是一份发布计划文档，其中包括定位画布、内部发布简报、沟通日历、含健康检查关卡的发布策略、含回滚触发条件的监控规格，以及与规格假设挂钩的发布后衡量计划。计划需在发布前 2 周进行评审；发现的缺口必须在发布日期前补齐。

---

所需数据不可用时

此技能的输出取决于其无法自行生成的数据、测量结果或工具结果。如果所需输入、工具或数据源不可用或无法验证，获准的输出方式是提供交付内容并说明缺口：需要什么、实际获取或验证了什么，以及输出中的哪些部分受到影响。绝不允许为了完成交付内容而捏造、估算或插算所需数字。明确说明缺口本身就是完整的答复。

---

参考文件

• references/launch-tier-decision.md - Tier 1、2、3 决策框架及示例。
• references/positioning-canvas.md - 单页定位模板，包含 B2B SaaS、B2C 和开发者功能示例。
• references/internal-alignment-checklist.md - 按层级划分的利益相关者、简报结构和分发时间。
• references/customer-comms-playbook.md - 渠道、日历、负责人和关卡。
• references/sales-enablement-template.md - 竞争对比卡片、演示、交易辅导和培训（B2B）。B2C 和 PLG 可跳过相关说明。
• references/support-readiness-checklist.md - 培训、常见问题、升级处理和监控访问权限。
• references/rollout-strategy-patterns.md - 与功能类型匹配的四种模式。决策框架：影响范围 × 信心度 × 对外承诺。
• references/monitoring-readiness-checklist.md - 指标维度、告警阈值、预先定义的回滚触发条件。
• references/post-launch-measurement-framework.md - 采用率、参与度、结果、副作用、时间范围，以及如何关联到规格假设。
• references/common-launch-failures.md - 十二种失败模式及其诊断和修复方法。

---

总结：大多数失败的发布，其实是根本没发布

当一项功能“失败”时，最常见的诊断并不是功能本身有问题，而是发布并不完整。销售团队不知情，客户没有收到通知，支持团队无法提供帮助。指标没有变化，是因为发布没有触达那些本可以推动指标变化的人。

在宣布功能失败之前，请根据本指南审查发布情况。一半时候，功能本身没有问题；只是发布从未真正发生。

将交付、发布和启动区分开来，是 PM 词汇中最有用的升级。要明确使用这些词，并在每日站会、路线图评审和发布复盘中使用。团队若能准确描述已发生的事情，就能在宣布功能失败之前发现那些尚未真正发布的功能，并将工程投入转向真正能够创造价值的功能。

如果不确定发布是否准备就绪，请问：发布简报是否已经撰写并分发？销售团队是否看过竞争对比卡片？支持团队是否准备好常见问题？是否已选定发布策略并定义回滚触发条件？沟通是否要等健康检查通过后才进行？衡量计划是否与规格假设挂钩？

只要其中任何一项的答案是否定的，发布就尚未准备就绪。推迟一周以弥补这些缺口，成本远低于仓促发布、最终只获得功能本可带来的一小部分价值。