name: stakeholder-comms description: 草拟针对不同受众的利益相关者更新 — 高管、工程团队、客户或跨职能合作伙伴。适用于撰写每周状态更新、月度报告、发布公告、风险沟通或决策文档时。
利益相关者沟通技能
您是产品管理通信方面的专家 — 包括状态更新、利益相关者管理、风险沟通、决策文档和会议促进。您帮助产品经理清晰有效地与多样化受众进行沟通。
按受众划分的更新模板
高管/领导更新
高管需要：战略背景、目标进展、需要他们帮助的风险、需要他们输入的决策。
格式：
状态：[绿色 / 黄色 / 红色]
TL;DR：[一句话 — 最重要的事情]
进展：
- [已实现的成果，与目标/OKR相关]
- [达到的里程碑，包括影响]
- [关键指标变化]
风险：
- [风险]：[缓解计划]。[如果需要，提出请求]。
需要决策：
- [决策]：[选项与建议]。截止日期：[日期]。
下一个里程碑：
- [里程碑] — [日期]
高管更新技巧：
- 以结论开头，而非过程。高管需要“我们发布了X并推动了Y指标”，而不是“我们开了14次站会，解决了23个工单”。
- 保持简洁，不超过200字。如果他们需要更多，他们会询问。
- 状态颜色应反映您的真实评估，而非您认为他们想听的。黄色不代表失败 — 它是良好的风险管理。
- 只包括您需要帮助的风险。除非他们需要知道，否则不要列出您正在处理的风险。
- 请求必须具体：“周五前决策X”，而不是“需要支持”。
工程团队更新
工程师需要：清晰优先级、技术背景、解决的阻塞项、影响他们工作的决策。
格式：
已发布：
- [功能/修复] — [链接到PR/工单]。[如有显著影响，说明]
进行中：
- [项目] — [负责人]。[预计完成时间]。[如有阻塞项，说明]
决策：
- [已做决策]：[理由]。[如有ADR，链接]
- [需要决策]：[背景]。[选项]。[建议]
优先级变化：
- [变化内容及原因]
即将开始：
- [下一项] — [为什么这些是下一步的背景]
工程更新技巧：
- 链接到具体工单、PR和文档。工程师希望点击查看详情。
- 当优先级变化时，解释原因。工程师在理解原因后会更有投入感。
- 明确说明是什么阻塞了他们，以及您正在如何解决。
- 不要浪费他们的时间，提供不影响他们工作的信息。
跨职能合作伙伴更新
合作伙伴（设计、营销、销售、支持）需要：即将影响他们的内容、他们需要准备什么、如何提供输入。
格式：
即将到来：
- [功能/发布] — [日期]。[这对您的团队意味着什么]
我们需要您：
- [具体请求] — [背景]。截止日期：[日期]
已做决策：
- [决策] — [如何影响您的团队]
开放输入：
- [我们希望反馈的主题] — [如何提供]
客户/外部更新
客户需要：新功能、即将发布内容、如何受益、如何开始使用。
格式：
新功能：
- [功能] — [客户角度的收益]。[如何使用 / 链接]
即将发布：
- [功能] — [预计时间]。[为什么对您重要]
已知问题：
- [问题] — [状态]。[如有可用解决方案，说明]
反馈：
- [如何分享反馈或请求功能]
客户更新技巧：
- 不使用内部术语。不提工单号或技术实现细节。
- 一切以客户能做什么为中心，而非您构建了什么。
- 诚实地说明时间线但不过度承诺。“本季度晚些时候”比可能错过的日期更好。
- 只提客户影响且有计划解决的风险问题。
状态报告框架
绿色/黄色/红色状态
绿色（按计划进行）：
- 按计划进展
- 无重大风险或阻塞
- 预计能按时完成承诺和截止日期
- 当事情真正顺利时使用绿色 — 而非默认值
黄色（有风险）：
- 进展慢于计划，或风险已出现
- 缓解措施正在进行但结果不确定
- 可能错过承诺，需要干预或范围调整
- 提前使用黄色 — 越早标记风险，选择越多
红色（偏离计划）：
- 显著落后于计划
- 重大阻塞或风险，无明确缓解措施
- 将错过承诺，需要重大干预（削减范围、增加资源、延长时限）
- 当您真正需要帮助时使用红色。不要等到太晚。
何时更改状态
- 在第一个风险迹象时移至黄色，而非确定事情恶化
- 当您耗尽自身选项需要升级时移至红色
- 只有当风险真正解决，而非暂停时，移回绿色
- 记录状态更改原因 — “移至黄色因为[原因]”
风险沟通
风险管理的ROAM框架
- 已解决：风险不再受关注。记录如何解决。
- 已分配：风险被确认且有人主动管理。说明所有人和缓解计划。
- 已接受：风险已知但我们选择继续，不缓解。记录理由。
- 已缓解：行动将风险降低到可接受水平。记录所做措施。
有效沟通风险
- 清晰陈述风险：“存在风险，[事情]发生因为[原因]”
- 量化影响：“如果发生，后果是[影响]”
- 说明可能性：“这是[很可能/可能/不太可能]因为[证据]”
- 呈现缓解措施：“我们通过[行动]管理此风险”
- 提出请求：“我们需要[具体帮助]以进一步减少此风险”
风险沟通常见错误
- 将风险埋没在好消息中。重要风险应领先提出。
- 模糊不清：“可能会有一些延迟”— 具体说明什么、多久、为什么。
- 提出风险无缓解措施。每个风险应有计划。
- 等待过久。早期沟通的风险是规划输入，晚期沟通则成紧急事件。
决策文档（ADRs）
架构决策记录格式
记录重要决策以供未来参考：
# [决策标题]
## 状态
[提议 / 接受 / 弃用 / 被ADR-XXX取代]
## 背景
需要决策的情况是什么？有哪些因素在起作用？
## 决策
我们决定了什么？清晰直接地陈述决策。
## 后果
这个决策的隐含意义是什么？
- 积极后果
- 负面后果或接受的权衡
- 这在未来允许或阻止什么
## 考虑过的替代方案
评估了哪些其他选项？
对于每个：它是什么，为什么被拒绝？
何时编写ADR
- 战略性产品决策（目标市场、支持平台）
- 重要技术决策（架构选择、供应商选择、构建vs购买）
- 有争议的决策（记录理由供未来参考）
- 限制未来选择的决策（选择技术、签署合作伙伴）
- 您预期将来会被质疑的决策（在上下文新鲜时捕捉）
决策文档技巧
- 在决策做出时编写ADR，而非几周后
- 包括参与决策的人员和最终决定者
- 慷慨记录背景 — 未来读者将不具备当前上下文
- 可以记录事后错误的决策 — 添加“被取代”链接
- 保持简短。一页优于五页。
会议促进
站会/每日同步
目的：突出阻塞项、协调工作、保持动力。 格式：每人分享：
- 自上次同步以来的完成事项
- 下一步工作内容
- 阻塞事项
促进技巧：
- 限制到15分钟。如果出现讨论，线下处理。
- 聚焦阻塞项 — 这是站会的最高价值部分
- 跟踪阻塞项并跟进解决
- 如无事同步，取消站会。尊重人们的时间。
冲刺/迭代规划
目的：承诺下个冲刺工作。对齐优先级和范围。 格式：
- 回顾：上冲刺发布内容、遗留内容、削减内容
- 优先级：本冲刺最重要完成事项
- 容量：团队能承担多少（考虑休假、值班、会议）
- 承诺：从待办事项中选择符合容量和优先级的项
- 依赖：标记任何跨团队或外部依赖
促进技巧：
- 提出优先顺序建议。不要让团队从头开始优先级排序。
- 抵制过度承诺。承诺更少并可靠交付更好。
- 确保每个项目有明确所有人和接受标准。
- 标记范围不足或隐藏复杂性的项。
回顾
目的：反思好的、不好的和需要改变的方面。 格式：
- 设定场景：提醒团队目标并创造心理安全
- 收集数据：什么做得好、什么不好、什么令人困惑
- 产生见解：识别模式和根本原因
- 决定行动：选择1-3个下冲刺要尝试的具体改进
- 关闭：感谢诚实反馈
促进技巧：
- 创造心理安全。人们必须感到安全才能诚实。
- 聚焦系统和流程，而非个人。
- 限制到1-3个行动项。过多则无变化。
- 跟进先前回顾行动项。如不跟进，人们会失去参与度。
- 偶尔变换回顾格式，防止僵化。
利益相关者审查/演示
目的：展示进展、收集反馈、建立对齐。 格式：
- 背景：提醒利益相关者目标及上次所见
- 演示：展示构建内容。使用真实产品，而非幻灯片。
- 指标：分享任何早期数据或反馈
- 反馈：结构化时间和空间供提问和输入
- 下一步：接下来是什么及下次审查时间
促进技巧：
- 尽可能演示真实产品。幻灯片不是演示。
- 框架反馈收集：“您对X有什么反馈？”优于“有任何想法吗？”
- 可视化捕获反馈并承诺处理（或解释为什么不）
- 设定关于此阶段哪些反馈可执行的期望