Back to Details

pm-stakeholder-update

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Stakeholder Update

利益相关者进展更新

Generate a stakeholder update tailored to the audience and cadence.
生成适配受众与更新节奏的利益相关者进展更新。

Usage

使用方法

/pm-stakeholder-update $ARGUMENTS
/pm-stakeholder-update $ARGUMENTS

Workflow

工作流程

1. Determine Update Type

1. 确定更新类型

Ask the user what kind of update:
  • Weekly: Regular cadence update on progress, blockers, and next steps
  • Monthly: Higher-level summary with trends, milestones, and strategic alignment
  • Launch: Announcement of a feature or product launch with details and impact
  • Ad-hoc: One-off update for a specific situation (escalation, pivot, major decision)
询问用户更新的类型：
  • 每周更新：定期汇报进展、阻塞问题及下一步计划
  • 月度更新：更高层面的总结，包含趋势、里程碑及战略对齐情况
  • 上线通知：发布功能或产品上线的公告，包含细节与影响
  • 临时更新：针对特定场景的一次性更新（如问题升级、方向调整、重大决策）

2. Determine Audience

2. 确定受众

Ask who the update is for:
  • Executives / leadership: High-level, outcome-focused, strategic framing, brief
  • Engineering team: Technical detail, implementation context, blockers, decisions needed
  • Cross-functional partners: Context-appropriate detail, focus on shared goals and dependencies
  • Customers / external: Benefits-focused, clear timelines, no internal jargon
  • Board: Metrics-driven, strategic, risk-focused, very concise
询问更新的受众：
  • 高管/领导层：高视角、结果导向、战略框架、简洁扼要
  • 工程团队：技术细节、实现背景、阻塞问题、待决策事项
  • 跨职能合作伙伴：适配场景的细节，聚焦共同目标与依赖关系
  • 客户/外部人员：以收益为核心、清晰时间线、无内部术语
  • 董事会：数据驱动、战略视角、聚焦风险、极度精简

3. Pull Context from Connected Tools

3. 从关联工具获取上下文

If Linear MCP (
int-linear-review
) is available:
  • Pull status of roadmap items and milestones
  • Identify completed items since last update
  • Surface items that are at risk or blocked
  • Pull sprint or iteration progress
If Discord (
discord-get-messages
) is available:
  • Search for relevant team discussions and decisions
  • Find blockers or issues raised in channels
  • Identify key decisions made asynchronously
If Fathom (
int-fathom
) is available:
  • Pull recent meeting notes and discussion summaries
  • Find decisions and action items from relevant meetings
If Notion MCP is available:
  • Search for recent meeting notes
  • Find decision documents or design reviews
If no tools are connected, ask the user to provide:
  • What was accomplished since the last update
  • Current blockers or risks
  • Key decisions made or needed
  • What is coming next
若已接入 Linear MCP (
int-linear-review
)：
  • 获取路线图项与里程碑状态
  • 识别自上次更新以来已完成的事项
  • 标记存在风险或阻塞的事项
  • 获取迭代或冲刺进展
若已接入 Discord (
discord-get-messages
)：
  • 搜索相关团队讨论与决策
  • 查找频道中提出的阻塞问题或议题
  • 识别异步达成的关键决策
若已接入 Fathom (
int-fathom
)：
  • 获取近期会议纪要与讨论摘要
  • 查找相关会议中的决策与行动项
若已接入 Notion MCP：
  • 搜索近期会议纪要
  • 查找决策文档或设计评审资料
若未接入任何工具，请用户提供：
  • 自上次更新以来完成的工作
  • 当前阻塞问题或风险
  • 已做出或待做出的关键决策
  • 下一步计划

4. Generate the Update

4. 生成更新内容

Structure the update for the target audience using the templates and frameworks below.
For executives: TL;DR, status color (G/Y/R), key progress tied to goals, decisions made, risks with mitigation, specific asks, and next milestones. Keep it under 300 words.
For engineering: What shipped (with links), what is in progress (with owners), blockers, decisions needed (with options and recommendation), and what is coming next.
For cross-functional partners: What is coming that affects them, what you need from them (with deadlines), decisions that impact their team, and areas open for input.
For customers: What is new (framed as benefits), what is coming soon, known issues with workarounds, and how to provide feedback. No internal jargon.
For launch announcements: What launched, why it matters, key details (scope, availability, limitations), success metrics, rollout plan, and feedback channels.
根据目标受众，使用以下模板与框架构建更新内容。
面向高管：TL;DR（核心摘要）、状态颜色（绿/黄/红）、与目标绑定的关键进展、已做出的决策、带缓解方案的风险、明确诉求、下一里程碑。内容控制在300字以内。
面向工程团队：已交付内容（附链接）、进行中事项（负责人）、阻塞问题、待决策事项（含选项与建议）、下一步计划。
面向跨职能合作伙伴：即将到来的影响事项、需对方配合的工作（含截止日期）、影响其团队的决策、开放征集意见的领域。
面向客户：新功能（以收益为框架）、即将推出的内容、已知问题与临时解决方案、反馈渠道。无内部术语。
面向上线公告：上线内容、重要性、关键细节（范围、可用性、限制）、成功指标、发布计划、反馈渠道。

5. Review and Deliver

5. 审核与交付

After generating the update:
  • Ask if the user wants to adjust tone, detail level, or emphasis
  • Offer to format for the delivery channel (email via Gmail MCP, Discord message via 
    discord-send-message
    , doc, slides)
  • If Discord is available, offer to draft the message for sending directly
生成更新内容后：
  • 询问用户是否需要调整语气、细节程度或侧重点
  • 提供适配交付渠道的格式优化（如通过Gmail MCP发送邮件、通过
    discord-send-message
    发送Discord消息、文档、幻灯片）
  • 若已接入Discord，可直接起草消息并发送

Update Templates by Audience

分受众更新模板

Executive / Leadership Update

高管/领导层更新

Executives want: strategic context, progress against goals, risks that need their help, decisions that need their input.
Format:
Status: [Green / Yellow / Red]

TL;DR: [One sentence — the most important thing to know]

Progress:
- [Outcome achieved, tied to goal/OKR]
- [Milestone reached, with impact]
- [Key metric movement]

Risks:
- [Risk]: [Mitigation plan]. [Ask if needed].

Decisions needed:
- [Decision]: [Options with recommendation]. Need by [date].

Next milestones:
- [Milestone] — [Date]
Tips for executive updates:
  • Lead with the conclusion, not the journey. Executives want "we shipped X and it moved Y metric" not "we had 14 standups and resolved 23 tickets."
  • Keep it under 200 words. If they want more, they will ask.
  • Status color should reflect YOUR genuine assessment, not what you think they want to hear. Yellow is not a failure — it is good risk management.
  • Only include risks you want help with. Do not list risks you are already handling unless they need to know.
  • Asks must be specific: "Decision on X by Friday" not "support needed."
高管关注：战略背景、目标达成进度、需他们协助的风险、需他们决策的事项。
格式：
状态：[绿色 / 黄色 / 红色]

核心摘要：[一句话——最重要的信息]

进展：
- [已达成的成果，绑定目标/OKR]
- [已完成的里程碑，及影响]
- [关键指标变化]

风险：
- [风险内容]：[缓解方案]。[若需协助请明确诉求]

待决策事项：
- [决策内容]：[选项及建议]。需在[日期]前完成决策。

下一里程碑：
- [里程碑内容] —— [日期]
高管更新技巧：
  • 先讲结论，再讲过程。高管想看到“我们交付了X，带动Y指标提升”，而非“我们开了14次站会，解决了23个工单”。
  • 内容控制在200字以内。若需要更多细节，他们会主动询问。
  • 状态颜色需真实反映你的评估，而非迎合预期。黄色不是失败——它是有效的风险管理。
  • 仅列出需要协助的风险。若已在自行处理，无需列出，除非他们需要知情。
  • 诉求必须具体：“周五前完成X事项的决策”而非“需要支持”。

Engineering Team Update

工程团队更新

Engineers want: clear priorities, technical context, blockers resolved, decisions that affect their work.
Format:
Shipped:
- [Feature/fix] — [Link to Linear ticket/PR]. [Impact if notable].

In progress:
- [Item] — [Owner]. [Expected completion]. [Blockers if any].

Decisions:
- [Decision made]: [Rationale]. [Link to ADR if exists].
- [Decision needed]: [Context]. [Options]. [Recommendation].

Priority changes:
- [What changed and why]

Coming up:
- [Next items] — [Context on why these are next]
Tips for engineering updates:
  • Link to specific Linear tickets, PRs, and documents. Engineers want to click through for details.
  • When priorities change, explain why. Engineers are more bought in when they understand the reason.
  • Be explicit about what is blocking them and what you are doing to unblock it.
  • Do not waste their time with information that does not affect their work.
工程师关注：清晰优先级、技术背景、已解决的阻塞问题、影响工作的决策。
格式：
已交付：
- [功能/修复] —— [Linear工单/PR链接]。[若有显著影响请说明]

进行中：
- [事项] —— [负责人]。[预计完成时间]。[若有阻塞请说明]

决策：
- [已做出的决策]：[理由]。[若有ADR请附链接]
- [待决策事项]：[背景]。[选项]。[建议]

优先级调整：
- [调整内容及原因]

下一步计划：
- [后续事项] —— [选择这些事项的背景]
工程团队更新技巧：
  • 链接到具体的Linear工单、PR及文档。工程师希望能点击查看细节。
  • 调整优先级时，请说明原因。当工程师理解背后逻辑时，会更愿意配合。
  • 明确说明阻塞问题及你正在采取的解决措施。
  • 不要浪费他们的时间在与工作无关的信息上。

Cross-Functional Partner Update

跨职能合作伙伴更新

Partners (design, marketing, sales, support) want: what is coming that affects them, what they need to prepare for, how to give input.
Format:
What's coming:
- [Feature/launch] — [Date]. [What this means for your team].

What we need from you:
- [Specific ask] — [Context]. By [date].

Decisions made:
- [Decision] — [How it affects your team].

Open for input:
- [Topic we'd love feedback on] — [How to provide it].
合作伙伴（设计、营销、销售、支持）关注：即将到来的影响事项、需准备的工作、反馈方式。
格式：
即将到来：
- [功能/上线] —— [日期]。[对你们团队的影响]

需你们配合：
- [具体诉求] —— [背景]。截止日期[日期]

已做出的决策：
- [决策内容] —— [对你们团队的影响]

开放意见征集：
- [希望获取反馈的主题] —— [反馈方式]

Customer / External Update

客户/外部更新

Customers want: what is new, what is coming, how it benefits them, how to get started.
Format:
What's new:
- [Feature] — [Benefit in customer terms]. [How to use it / link].

Coming soon:
- [Feature] — [Expected timing]. [Why it matters to you].

Known issues:
- [Issue] — [Status]. [Workaround if available].

Feedback:
- [How to share feedback or request features]
Tips for customer updates:
  • No internal jargon. No ticket numbers. No technical implementation details.
  • Frame everything in terms of what the customer can now DO, not what you built.
  • Be honest about timelines but do not overcommit. "Later this quarter" is better than a date you might miss.
  • Only mention known issues if they are customer-impacting and you have a resolution plan.
客户关注：新功能、即将推出的内容、对他们的收益、使用方法。
格式：
新功能：
- [功能] —— [客户视角的收益]。[使用方法/链接]

即将推出：
- [功能] —— [预计时间]。[对您的重要性]

已知问题：
- [问题] —— [状态]。[若有临时解决方案请说明]

反馈：
- [如何分享反馈或提交功能请求]
客户更新技巧：
  • 无内部术语。无工单号。无技术实现细节。
  • 所有内容以客户能获得的价值为框架，而非你构建的内容。
  • 诚实告知时间线，但不要过度承诺。“本季度晚些时候”比可能无法兑现的具体日期更好。
  • 仅提及影响客户的已知问题，且需有解决方案计划。

Status Reporting Framework

状态报告框架

Green / Yellow / Red Status

绿/黄/红状态

Green (On Track):
  • Progressing as planned
  • No significant risks or blockers
  • On track to meet commitments and deadlines
  • Use Green when things are genuinely going well — not as a default
Yellow (At Risk):
  • Progress is slower than planned, or a risk has materialized
  • Mitigation is underway but outcome is uncertain
  • May miss commitments without intervention or scope adjustment
  • Use Yellow proactively — the earlier you flag risk, the more options you have
Red (Off Track):
  • Significantly behind plan
  • Major blocker or risk without clear mitigation
  • Will miss commitments without significant intervention (scope cut, resource addition, timeline extension)
  • Use Red when you genuinely need help. Do not wait until it is too late.
绿色（正常推进）：
  • 按计划进展
  • 无重大风险或阻塞
  • 有望达成承诺与截止日期
  • 仅当情况确实良好时使用绿色——不要将其作为默认选项
黄色（存在风险）：
  • 进展慢于计划，或风险已显现
  • 缓解措施已启动，但结果不确定
  • 若无干预或范围调整，可能无法达成承诺
  • 主动使用黄色——越早标记风险，可选的应对方案越多
红色（偏离轨道）：
  • 显著落后于计划
  • 存在无明确缓解方案的重大阻塞或风险
  • 若无重大干预（削减范围、增加资源、延长时间线），将无法达成承诺
  • 仅当确实需要协助时使用红色。不要等到为时已晚。

When to Change Status

状态变更时机

  • Move to Yellow at the FIRST sign of risk, not when you are sure things are bad
  • Move to Red when you have exhausted your own options and need escalation
  • Move back to Green only when the risk is genuinely resolved, not just paused
  • Document what changed when you change status — "Moved to Yellow because [reason]"
  • 一旦发现风险迹象，立即转为黄色，而非确定情况恶化后
  • 当你已穷尽自身解决办法需要升级时，转为红色
  • 仅当风险真正解决时，才转回绿色，而非暂时缓解
  • 状态变更时记录原因：“转为黄色，原因是[具体理由]”

Risk Communication

风险沟通

ROAM Framework for Risk Management

ROAM风险管理框架

  • Resolved: Risk is no longer a concern. Document how it was resolved.
  • Owned: Risk is acknowledged and someone is actively managing it. State the owner and the mitigation plan.
  • Accepted: Risk is known but we are choosing to proceed without mitigation. Document the rationale.
  • Mitigated: Actions have reduced the risk to an acceptable level. Document what was done.
  • Resolved（已解决）：风险不再是问题。记录解决方式。
  • Owned（已认领）：风险已被确认，且有人在主动管理。说明负责人与缓解方案。
  • Accepted（已接受）：已知风险，但选择不采取缓解措施推进。记录理由。
  • Mitigated（已缓解）：已采取行动将风险降低至可接受水平。记录措施。

Communicating Risks Effectively

有效沟通风险的步骤

  1. State the risk clearly: "There is a risk that [thing] happens because [reason]"
  2. Quantify the impact: "If this happens, the consequence is [impact]"
  3. State the likelihood: "This is [likely/possible/unlikely] because [evidence]"
  4. Present the mitigation: "We are managing this by [actions]"
  5. Make the ask: "We need [specific help] to further reduce this risk"
  1. 清晰说明风险：“存在[风险内容]发生的可能，原因是[具体理由]”
  2. 量化影响：“若发生此情况，后果是[具体影响]”
  3. 说明可能性：“此情况[很可能/可能/不太可能]发生，依据是[证据]”
  4. 提出缓解方案：“我们正通过[具体行动]管理此风险”
  5. 明确诉求：“我们需要[具体协助]进一步降低风险”

Common Mistakes in Risk Communication

风险沟通的常见误区

  • Burying risks in good news. Lead with risks when they are important.
  • Being vague: "There might be some delays" — specify what, how long, and why.
  • Presenting risks without mitigations. Every risk should come with a plan.
  • Waiting too long. A risk communicated early is a planning input. A risk communicated late is a fire drill.
  • 将风险隐藏在好消息中。当风险重要时，先讲风险。
  • 表述模糊：“可能会有一些延迟”——需明确内容、时长及原因。
  • 只提风险不提供缓解方案。每个风险都应附带应对计划。
  • 沟通过晚。提前沟通的风险是规划输入，晚沟通的风险是紧急救火。

Decision Documentation (ADRs)

决策文档（ADR）

Architecture Decision Record Format

架构决策记录格式

Document important decisions for future reference:
undefined
为未来参考记录重要决策：
undefined

[Decision Title]

[决策标题]

Status

状态

[Proposed / Accepted / Deprecated / Superseded by ADR-XXX]
[提议中 / 已接受 / 已废弃 / 被ADR-XXX替代]

Context

背景

What is the situation that requires a decision? What forces are at play?
需要做出决策的场景是什么？有哪些影响因素？

Decision

决策

What did we decide? State the decision clearly and directly.
我们做出了什么决策？清晰直接地说明。

Consequences

影响

What are the implications of this decision?
  • Positive consequences
  • Negative consequences or tradeoffs accepted
  • What this enables or prevents in the future
此决策的含义是什么？
  • 积极影响
  • 已接受的负面影响或权衡
  • 对未来的赋能或限制

Alternatives Considered

备选方案

What other options were evaluated? For each: what was it, why was it rejected?
undefined
评估过哪些其他选项？ 针对每个选项：内容是什么，为何被否决？
undefined

When to Write an ADR

何时撰写ADR

  • Strategic product decisions (which market segment to target, which platform to support)
  • Significant technical decisions (architecture choices, vendor selection, build vs buy)
  • Controversial decisions where people disagreed (document the rationale for future reference)
  • Decisions that constrain future options (choosing a technology, signing a partnership)
  • Decisions you expect people to question later (capture the context while it is fresh)
  • 战略产品决策（目标细分市场、支持平台）
  • 重大技术决策（架构选择、供应商选型、自研 vs 采购）
  • 存在分歧的争议性决策（记录理由供未来参考）
  • 限制未来选项的决策（选择技术、签署合作）
  • 预计未来会被质疑的决策（趁上下文清晰时记录）

Tips for Decision Documentation

决策文档撰写技巧

  • Write ADRs close to when the decision is made, not weeks later
  • Include who was involved in the decision and who made the final call
  • Document the context generously — future readers will not have today's context
  • It is okay to document decisions that were wrong in hindsight — add a "superseded by" link
  • Keep them short. One page is better than five.
  • 决策做出后立即撰写ADR，而非数周后
  • 记录参与决策的人员及最终决策者
  • 详细记录背景——未来读者不具备当前的上下文
  • 即使事后证明决策错误，也可以记录——添加“被替代”链接
  • 保持简短。一页内容优于五页。

Meeting Facilitation

会议引导

Stand-up / Daily Sync

站会/每日同步

Purpose: Surface blockers, coordinate work, maintain momentum. Format: Each person shares:
  • What they accomplished since last sync
  • What they are working on next
  • What is blocking them
Facilitation tips:
  • Keep it to 15 minutes. If discussions emerge, take them offline.
  • Focus on blockers — this is the highest-value part of standup
  • Track blockers and follow up on resolution
  • Cancel standup if there is nothing to sync on. Respect people's time.
目的：暴露阻塞问题、协调工作、保持进度。 格式：每人分享：
  • 自上次同步以来完成的工作
  • 下一步计划
  • 当前阻塞问题
引导技巧：
  • 控制在15分钟内。若出现讨论，移至会后处理。
  • 聚焦阻塞问题——这是站会最高价值的部分
  • 跟踪阻塞问题并跟进解决情况
  • 若无同步需求，取消站会。尊重他人时间。

Sprint / Iteration Planning

迭代/冲刺规划

Purpose: Commit to work for the next sprint. Align on priorities and scope. Format:
  1. Review: what shipped last sprint, what carried over, what was cut
  2. Priorities: what are the most important things to accomplish this sprint
  3. Capacity: how much can the team take on (account for PTO, on-call, meetings)
  4. Commitment: select items from the backlog that fit capacity and priorities
  5. Dependencies: flag any cross-team or external dependencies
Facilitation tips:
  • Come with a proposed priority order. Do not ask the team to prioritize from scratch.
  • Push back on overcommitment. It is better to commit to less and deliver reliably.
  • Ensure every item has a clear owner and clear acceptance criteria.
  • Flag items that are underscoped or have hidden complexity.
目的：承诺下一冲刺的工作。对齐优先级与范围。 格式：
  1. 回顾：上一冲刺已交付内容、遗留事项、削减内容
  2. 优先级：下一冲刺最需完成的事项
  3. 产能：团队可承接的工作量（考虑休假、值班、会议）
  4. 承诺：从待办列表中选择符合产能与优先级的事项
  5. 依赖关系：标记跨团队或外部依赖
引导技巧：
  • 提前准备优先级排序建议。不要让团队从零开始排序。
  • 反对过度承诺。承诺较少但可靠交付更好。
  • 确保每个事项都有明确负责人与验收标准。
  • 标记范围不足或存在隐藏复杂度的事项。

Retrospective

回顾会议

Purpose: Reflect on what went well, what did not, and what to change. Format:
  1. Set the stage: remind the team of the goal and create psychological safety
  2. Gather data: what went well, what did not go well, what was confusing
  3. Generate insights: identify patterns and root causes
  4. Decide actions: pick 1-3 specific improvements to try next sprint
  5. Close: thank people for honest feedback
Facilitation tips:
  • Create psychological safety. People must feel safe to be honest.
  • Focus on systems and processes, not individuals.
  • Limit to 1-3 action items. More than that and nothing changes.
  • Follow up on previous retro action items. If you never follow up, people stop engaging.
  • Vary the retro format occasionally to prevent staleness.
目的：反思优点、不足及改进方向。 格式：
  1. 开场：提醒团队会议目标，营造心理安全氛围
  2. 收集信息：哪些做得好，哪些做得不好，哪些存在困惑
  3. 生成洞察：识别模式与根本原因
  4. 确定行动：选择1-3项具体改进措施在下一冲刺尝试
  5. 收尾：感谢大家的坦诚反馈
引导技巧：
  • 营造心理安全氛围。人们必须感到可以坦诚发言。
  • 聚焦系统与流程，而非个人。
  • 限制行动项为1-3项。过多则无法落地。
  • 跟进上次回顾会议的行动项。若从不跟进，人们会停止参与。
  • 偶尔更换回顾会议格式，避免僵化。

Stakeholder Review / Demo

利益相关者评审/演示

Purpose: Show progress, gather feedback, build alignment. Format:
  1. Context: remind stakeholders of the goal and what they saw last time
  2. Demo: show what was built. Use real product, not slides.
  3. Metrics: share any early data or feedback
  4. Feedback: structured time for questions and input
  5. Next steps: what is coming next and when the next review will be
Facilitation tips:
  • Demo the real product whenever possible. Slides are not demos.
  • Frame feedback collection: "What feedback do you have on X?" is better than "Any thoughts?"
  • Capture feedback visibly and commit to addressing it (or explaining why not)
  • Set expectations about what kind of feedback is actionable at this stage
目的：展示进展、收集反馈、建立对齐。 格式：
  1. 背景：提醒利益相关者目标及上次展示内容
  2. 演示：展示已构建的内容。使用真实产品，而非幻灯片。
  3. 指标：分享早期数据或反馈
  4. 反馈：结构化的提问与输入时间
  5. 下一步：后续计划及下次评审时间
引导技巧：
  • 尽可能演示真实产品。幻灯片不是演示。
  • 明确反馈收集方向：“您对X有什么反馈？”比“有什么想法？”更好。
  • 清晰记录反馈，并承诺处理（或说明无法处理的原因）
  • 明确说明当前阶段可接受的反馈类型

Output Format

输出格式

Keep updates scannable. Use bold for key points, bullets for lists. Executive updates should be under 300 words. Engineering updates can be longer but should still be structured for skimming.
保持更新内容易读。关键内容用粗体，列表用项目符号。高管更新需控制在300字以内。工程更新可更长，但仍需结构化以便快速浏览。

Tips

技巧

  • The most common mistake in stakeholder updates is burying the lead. Start with the most important thing.
  • Status colors (Green/Yellow/Red) should reflect reality, not optimism. Yellow is not a failure — it is good risk communication.
  • Asks should be specific and actionable. "We need help" is not an ask. "We need a decision on X by Friday" is.
  • For executives, frame everything in terms of outcomes and goals, not activities and tasks.
  • If there is bad news, lead with it. Do not hide it after good news.
  • Match the length to the audience's attention. Executives get a few bullets. Engineering gets the details they need.
  • 利益相关者更新最常见的错误是隐藏核心信息。从最重要的内容开始。
  • 状态颜色（绿/黄/红）应反映实际情况，而非乐观预期。黄色不是失败——它是有效的风险沟通。
  • 诉求必须具体且可执行。“我们需要帮助”不是有效诉求。“我们需要在周五前完成X事项的决策”才是。
  • 面向高管时，所有内容以成果与目标为框架，而非活动与任务。
  • 若有坏消息，先讲出来。不要放在好消息之后隐藏。
  • 根据受众的注意力时长调整内容长度。高管只需几个项目符号，工程师需要详细信息。