stakeholder-communication
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseStakeholder Communication
利益相关者沟通
Get the right information to the right people at the right time, in a form they can act on. Stack-agnostic. Applies to any team operating with cross-functional stakeholders.
在合适的时间,以受众可采取行动的形式,向合适的人传递正确的信息。与技术栈无关,适用于任何有跨职能利益相关者的团队。
When to use
适用场景
- Writing weekly or monthly status updates
- Preparing for an executive review or board update
- Sharing a technical decision with a non-technical audience
- Communicating a delay, miss, or quality problem
- Asking for help, resources, or decisions
- Managing up to a manager or sponsor
- Designing the communication cadence for a project
- Drafting an internal announcement
- 撰写每周或每月状态更新
- 准备高管评审或董事会更新
- 向非技术受众分享技术决策
- 传达延迟、未达标或质量问题
- 请求帮助、资源或决策
- 向上对接经理或项目发起人
- 设计项目沟通节奏
- 起草内部公告
When NOT to use
不适用场景
- Customer-facing communication (use marketing/support skills)
- Public comms or press (different framework, different stakes)
- Incident communication during an active incident (use )
incident-response - Internal documentation that isn't time-sensitive (use )
documentation-strategy - Specific delivery formats (slide deck design, email tone) - this skill is about content and structure
- 面向客户的沟通(使用营销/支持类技能)
- 公开沟通或新闻发布(框架不同,风险不同)
- 事件活跃期间的事件沟通(使用)
incident-response - 非时效性的内部文档(使用)
documentation-strategy - 特定交付格式(幻灯片设计、邮件语气)——本技能专注于内容和结构
Required inputs
必要输入
- The audience (who specifically, what's their context, what do they care about)
- The purpose (inform, decide, escalate, ask, celebrate)
- The substance (what's actually happening)
- The medium (email, doc, meeting, slide, chat)
- Time constraints (when do they need this)
- 受众(具体是谁,他们的背景是什么,关心什么)
- 目的(告知、决策、升级、请求、庆祝)
- 核心内容(实际发生的情况)
- 媒介(邮件、文档、会议、幻灯片、聊天)
- 时间限制(他们何时需要这些信息)
The framework: 5 questions
框架:5个问题
Before any stakeholder communication, answer:
进行任何利益相关者沟通前,先回答以下问题:
Question 1: Who is the audience?
问题1:受众是谁?
Specifically. "Leadership" is too vague. The CFO and the VP of Engineering have different concerns.
For each named audience:
- What do they care about? (revenue, risk, quality, velocity, costs, customers)
- What do they already know? (background you can skip)
- What's their level of detail tolerance? (executives want headlines; ICs want details)
- What action do you want from them? (acknowledgment, decision, help, no action)
要具体。"领导层"过于模糊。CFO和工程副总裁的关注点不同。
针对每个明确的受众:
- 他们关心什么?(收入、风险、质量、速度、成本、客户)
- 他们已经了解什么?(可跳过的背景信息)
- 他们对细节的容忍度如何?(高管想要核心要点;一线员工想要细节)
- 你希望他们采取什么行动?(确认、决策、提供帮助、无需行动)
Question 2: What's the headline?
问题2:核心要点是什么?
If they read only one sentence, what should they take away?
The headline goes first. Always. The narrative supports it; the data confirms it.
This is the biggest gap in most stakeholder communication: people start with context and build to a conclusion. Stakeholders want the conclusion first.
如果他们只看一句话,应该记住什么?
核心要点放在最前面。永远如此。后续内容用来支撑它,数据用来佐证它。
这是大多数利益相关者沟通中最大的缺口:人们从背景开始,逐步推导结论。而利益相关者希望先看到结论。
Question 3: What's the so-what?
问题3:这意味着什么?
Stakeholders ask "and?" implicitly. Answer it explicitly.
- "We hit 80% of the milestone." → so what?
- "We hit 80% of the milestone, which puts the launch one week behind plan." → that's the so-what.
The so-what makes the information actionable.
利益相关者会隐含地问"然后呢?"要明确回答。
- "我们完成了里程碑的80%。"→这意味着什么?
- "我们完成了里程碑的80%,这将导致发布计划推迟一周。"→这才是关键影响。
明确关键影响能让信息具备可操作性。
Question 4: What do you want?
问题4:你想要什么?
Communications generally have one of these requests:
- Inform: no action needed. Just keeping them in the loop.
- Decide: a decision is needed; here are the options and recommendation.
- Escalate: something is stuck; we need help.
- Ask: a specific request (resource, introduction, review).
- Celebrate: a win to share; no action needed but morale matters.
State which. Don't bury the request.
沟通通常有以下请求之一:
- **告知:**无需行动。仅让他们了解情况。
- **决策:**需要做出决策;提供选项和建议。
- **升级:**遇到瓶颈;需要帮助。
- **请求:**具体的需求(资源、介绍、评审)。
- **庆祝:**分享胜利;无需行动但关乎士气。
明确说明。不要隐藏请求。
Question 5: What format?
问题5:采用什么格式?
- Async written (doc, email): rich content, decision trail, easy to reference
- Sync written (chat, ticket comment): quick exchange, conversational
- Sync spoken (meeting, call): nuance, debate, alignment
- Mixed (doc + meeting): the doc is read in advance; meeting is decision
For most updates: async written. Save sync time for actual discussion.
- 异步书面形式(文档、邮件):内容丰富,有决策轨迹,便于查阅
- 同步书面形式(聊天、工单评论):快速交流,风格随意
- 同步口头形式(会议、电话):传递细微差别,便于讨论和对齐
- 混合形式(文档+会议):提前阅读文档,会议用于决策
对于大多数更新:采用异步书面形式。将同步时间留给实际讨论。
The structure: the inverted pyramid
结构:倒金字塔
Stakeholder communication reads like a news article, not an essay.
Headline (one sentence)
The "so what" and the request (one paragraph)
Status / progress (the body)
Risks and asks (what we need)
Detail / appendix (what curious readers want)Cut from the bottom. If your update gets shortened, the top survives.
利益相关者沟通的结构像新闻报道,而非散文。
核心要点(一句话)
关键影响与请求(一段)
状态/进展(正文)
风险与需求(我们需要什么)
细节/附录(供感兴趣的读者查阅)从底部删减。如果更新被缩短,顶部内容仍保留。
Update templates
更新模板
Weekly project update
每周项目更新
**Project:** [Name]
**Status:** [On track / At risk / Off track]
**Headline:** [One-sentence summary]
**This week:**
- [Specific accomplishment]
- [Specific accomplishment]
- [Specific accomplishment]
**Next week:**
- [Specific plan]
- [Specific plan]
**Risks / blockers:**
- [Risk + what we're doing about it / what we need]
**Metrics:**
- [Metric: value vs target]
- [Metric: value vs target]The status indicator (on track / at risk / off track) is essential. Stakeholders scan for it.
**项目:** [名称]
**状态:** [正常进行 / 存在风险 / 偏离轨道]
**核心要点:** [一句话总结]
**本周进展:**
- [具体成果]
- [具体成果]
- [具体成果]
**下周计划:**
- [具体计划]
- [具体计划]
**风险/障碍:**
- [风险 + 我们的应对措施 / 需求]
**指标:**
- [指标:实际值 vs 目标值]
- [指标:实际值 vs 目标值]状态标识(正常进行/存在风险/偏离轨道)至关重要。利益相关者会优先关注它。
Executive review
高管评审
**Headline:** [The summary, one sentence]
**Key points:**
1. [Point with one supporting sentence]
2. [Point with one supporting sentence]
3. [Point with one supporting sentence]
**Decisions needed:**
- [Decision A: options and recommendation]
- [Decision B: options and recommendation]
**Asks:**
- [Specific request]
**Detail:** [Linked doc or appendix]Executives skim. They click into detail when interested.
**核心要点:** [一句话总结]
**关键点:**
1. [要点 + 一句支撑说明]
2. [要点 + 一句支撑说明]
3. [要点 + 一句支撑说明]
**待决策事项:**
- [决策A:选项与建议]
- [决策B:选项与建议]
**需求:**
- [具体请求]
**详情:** [链接文档或附录]高管会快速浏览。他们感兴趣时才会点击查看详情。
Bad news
坏消息沟通
The hardest update to write well.
**Headline:** [The bad news, plainly stated]
**What happened:**
[Specific facts, no euphemisms]
**Impact:**
[Who's affected, how much, by when]
**What we're doing:**
[Specific actions and owners]
**What we need:**
[Specific asks, if any]
**Timeline:**
[When the next update will land]Don't soften the headline. Soft headlines on bad news erode trust faster than the news itself.
最难写好的更新。
**核心要点:** [直白陈述坏消息]
**事件经过:**
[具体事实,不使用委婉语]
**影响:**
[受影响对象、影响程度、时间节点]
**我们的行动:**
[具体措施及负责人]
**我们的需求:**
[如有具体请求]
**时间线:**
[下次更新的时间]不要弱化核心要点。对坏消息使用模糊的核心要点比消息本身更快地侵蚀信任。
Decision request
决策请求
**Decision:** [What needs to be decided]
**Context:** [The minimum needed to understand]
**Options:**
1. [Option A: description, pros, cons]
2. [Option B: description, pros, cons]
3. [Option C: description, pros, cons]
**Recommendation:** [Option X, because...]
**Need by:** [Date]
**Decision rights:** [Who decides]Recommendation matters. Not making one is putting the work back on the decider.
**待决策事项:** [需要做出的决策]
**背景:** [理解决策所需的最少信息]
**选项:**
1. [选项A:描述、优缺点]
2. [选项B:描述、优缺点]
3. [选项C:描述、优缺点]
**建议:** [选项X,原因...]
**截止日期:** [日期]
**决策权限:** [决策者]建议很重要。不给出建议就是把工作推回给决策者。
Tone and register
语气与风格
Across audiences
针对不同受众
| Audience | Tone | Detail | Length |
|---|---|---|---|
| Direct manager | Candid, briefer | Mid | Medium |
| Skip-level / VP | Polished, sharper | Low | Short |
| Cross-functional peer | Collaborative, specific | Mid-high | Medium |
| Executive / board | Headlines, confident | Low (with detail available) | Short |
| Team / IC stakeholders | Detailed, direct | High | Long |
| 受众 | 语气 | 细节程度 | 篇幅 |
|---|---|---|---|
| 直属经理 | 坦诚、简洁 | 中等 | 中等 |
| 隔级领导/副总裁 | 严谨、精炼 | 低 | 短 |
| 跨职能同事 | 协作、具体 | 中高 | 中等 |
| 高管/董事会 | 核心要点、自信 | 低(可提供详情) | 短 |
| 团队/一线利益相关者 | 详细、直接 | 高 | 长 |
What to avoid
需避免的情况
- Hedging when confident. "I think maybe we might be able to..." Just say what you mean.
- Confidence when uncertain. "Definitely launching Friday" when there's risk. Calibrate.
- Jargon for non-technical audiences. Replace with plain language.
- Burying the lede. Headline first.
- Implicit asks. State explicitly what you want.
- Status updates that are 90% activity, 10% outcome. Focus on outcomes; activity is supporting evidence.
- 确定时仍含糊其辞。"我觉得也许我们可能可以……"直接表达你的意思。
- **不确定时过于自信。**存在风险时却说"肯定周五发布"。要校准语气。
- **对非技术受众使用行话。**替换为通俗易懂的语言。
- **隐藏核心要点。**核心要点放在最前面。
- **隐含请求。**明确说明你想要什么。
- **90%是活动、10%是成果的状态更新。**聚焦成果;活动只是支撑证据。
Workflow
工作流程
Step 1: Define the audience and purpose
步骤1:定义受众和目的
Before writing, answer Q1-Q5 above. Often this clarifies the message before any drafting.
撰写前,先回答上述问题1-5。通常这会在动笔前就理清信息。
Step 2: Draft the headline
步骤2:撰写核心要点
One sentence. The takeaway. If you can't write the headline, you don't know yet what you're communicating.
一句话。即核心结论。如果你写不出核心要点,说明你还不清楚要沟通什么。
Step 3: Write inverted pyramid
步骤3:按照倒金字塔撰写
Headline, so-what, body, asks, detail.
核心要点、关键影响、正文、需求、细节。
Step 4: Cut
步骤4:删减内容
A first draft is usually 30-50% too long.
- Cut activities that don't have outcomes
- Cut adjectives (great, awesome, excellent, exciting)
- Cut filler (just, really, very, actually)
- Cut hedging (kind of, sort of, somewhat) when confident
- Cut sentences that don't add information
初稿通常会多出30-50%的内容。
- 删除没有成果的活动描述
- 删除形容词(很棒、极好、优秀、令人兴奋)
- 删除填充词(只是、真的、非常、实际上)
- 确定时删除含糊其辞的表述(有点、稍微、某种程度上)
- 删除无信息增量的句子
Step 5: Verify the request
步骤5:验证请求
Reread. Is the ask clear? Is it specific? Is the deadline named?
重读。请求是否清晰?是否具体?是否标明了截止日期?
Step 6: Check the audience
步骤6:检查受众适配性
Imagine the recipient reading. Will they understand the headline? Have you skipped context they need? Have you given context they don't need?
想象收件人阅读时的场景。他们能理解核心要点吗?你是否跳过了他们需要的背景?是否提供了他们不需要的背景?
Step 7: Send and follow up
步骤7:发送并跟进
After sending:
- Did the right people see it? Acknowledge the right channel.
- Did they understand? Watch for confused replies; address them.
- Did they act? Follow up on stale asks.
发送后:
- 合适的人是否看到了?确认渠道是否正确。
- 他们是否理解?留意困惑的回复并解决。
- 他们是否采取了行动?跟进未响应的请求。
Cadence design
沟通节奏设计
Different audiences need different cadences.
不同受众需要不同的沟通节奏。
High-frequency (weekly or more)
高频(每周或更频繁)
- Direct team, manager, sponsor
- Active project stakeholders
- People making day-to-day decisions
- 直属团队、经理、项目发起人
- 活跃的项目利益相关者
- 做日常决策的人员
Medium-frequency (biweekly to monthly)
中频(每两周至每月)
- Skip-level
- Cross-functional partners
- Adjacent teams
- Strategic stakeholders
- 隔级领导
- 跨职能合作伙伴
- 相关团队
- 战略利益相关者
Low-frequency (quarterly)
低频(每季度)
- Executive review
- Board update
- Wider organization
- External stakeholders (where relevant)
The right cadence is what's needed, not what fills the calendar. Update people when there's something new; don't manufacture updates.
- 高管评审
- 董事会更新
- 更广泛的组织
- 外部利益相关者(如适用)
合适的节奏是按需沟通,而非填满日程。有新内容时再更新;不要刻意制造更新。
Failure patterns
常见错误模式
Long preamble before the point. Three paragraphs of context, then the one sentence that mattered. Lead with the point.
Status: yellow. Same status three weeks in a row. Yellow with no change is red. Be honest about progress.
Update without a clear ask. "We're working on it." OK, what do you want? If nothing, say "no action needed."
Sandwiching bad news in good news. "We've done X and Y, and unfortunately Z is delayed, but we've also done W." The bad news gets lost. Lead with it if it's the headline.
Walls of text. Too long, unread. Cut to the structure.
Activity vs outcome. "Met with team. Reviewed plan. Updated tickets." So what? "Cut scope to hit launch date" is an outcome.
Different update for every audience. Maintaining 5 versions doubles work. Have one core update; tailor the framing.
Status update that's actually a request. Buries an ask in a wall of status. Pull the ask out. Make it visible.
Optimistic projections. "We'll be back on track next week." Then we're not. Then again. Trust erodes. Be honest about the path.
No follow-up on asks. Asked for a decision; didn't get one; moved on. Now the project is stuck. Follow up.
Communicating bad news only when forced to. Stakeholders find out from someone else, or from a missed deadline. Lose trust. Communicate proactively.
Performative comms for the audience of one. Every update reads like a sales pitch to the boss. Stakeholders see through it. Be direct.
No comms when no news. Silence is worse than "no change this week." Set expectations on cadence and stick to it.
**冗长铺垫后才讲重点。**三段背景,然后才是关键的一句话。直接从重点开始。
**状态:黄色。**连续三周都是黄色状态。无变化的黄色等同于红色。如实汇报进展。
没有明确请求的更新。"我们正在推进。"好吧,你想要什么?如果不需要行动,就说"无需行动"。
用好消息包裹坏消息。"我们完成了X和Y,但遗憾的是Z延迟了,不过我们还完成了W。"坏消息会被淹没。如果坏消息是核心要点,就放在最前面。
**大段文字。**太长,没人读。按照结构删减。
活动 vs 成果。"与团队开会。评审计划。更新工单。"这意味着什么?"缩减范围以确保按时发布"才是成果。
**为每个受众单独制作更新。**维护5个版本会加倍工作量。制作一个核心更新,再针对不同受众调整表述方式。
**实则是请求的状态更新。**将请求隐藏在大段状态内容中。把请求单独拎出来,让它显眼。
乐观预测。"我们下周就能回到正轨。"结果没有。再次承诺。信任被侵蚀。如实说明进展路径。
**不跟进请求。**请求决策但未得到回应,就继续推进。现在项目陷入停滞。要跟进。
**被迫时才传达坏消息。**利益相关者从别人那里或从错过的截止日期得知消息。失去信任。要主动沟通。
**为取悦单一受众而做表面沟通。**每次更新都像给老板的销售说辞。利益相关者能看穿。要直接。
**没有消息就不沟通。**沉默比"本周无变化"更糟糕。设定沟通节奏并坚持执行。
Output format
输出格式
A communication plan for a project includes:
- Stakeholder map: named people, their interests, their decision rights
- Cadence: what updates go to whom, how often
- Templates: standardized formats for repeated updates
- Escalation paths: who to involve when something's at risk
- Decision log: running record of decisions made, by whom, why
For individual communications:
- Headline: the takeaway
- Body: the supporting structure
- Ask: the request, explicitly
- Distribution: who gets it, in what form
项目沟通计划包括:
- **利益相关者图谱:**明确的人员、他们的关注点、决策权限
- **沟通节奏:**向谁发送什么更新、频率如何
- **模板:**标准化的重复更新格式
- **升级路径:**出现风险时需联系的人员
- **决策日志:**决策记录、决策者、决策原因
对于单个沟通内容:
- **核心要点:**核心结论
- **正文:**支撑结构
- **请求:**明确的需求
- **分发:**接收人、形式
Reference files
参考文件
- : Ready-to-use templates for the most common stakeholder communications, with annotated examples.
references/update-templates.md
- : 适用于最常见利益相关者沟通的现成模板,附注释示例。
references/update-templates.md