mcpField
B
board-update

board-update

github.com/shawnpang文档处理371200 次安装32 周前更新
代码仓库

关于 board-update

帮助创业公司创始人撰写投资人更新邮件、董事会材料和季度业务回顾。它提供结构化的指标叙述、坏消息沟通和具体请求框架。

主要功能

  1. 01选择更新形式与发送节奏
  2. 02按框架组织董事会内容
  3. 03突出关键指标与变化
  4. 04透明说明负面进展
  5. 05提出具体可执行请求

适用场景

  1. 01撰写月度投资人邮件
  2. 02准备季度董事会材料
  3. 03说明未达成的业务目标
  4. 04整理董事会需要决策的事项

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/shawnpang/startup-founder-skills --skill board-update

安装后在 Claude Code 中输入/board-update确认已加载。

详细介绍

董事会更新

适用场景

当创始人需要起草投资者更新邮件、准备董事会会议演示文稿或撰写季度业务回顾时启用。适用于“帮我写一份月度投资者更新”“为我们的董事会会议做准备”“起草一份季度回顾”或“我该如何向董事会传达坏消息”等请求。也适用于需要阐述市场和愿景的融资演示文稿。

所需背景信息

  • 来自 startup-context: 公司阶段、融资历史、董事会构成、关键指标(MRR、烧钱速度、资金可支撑时间、员工人数)、当前战略优先事项,以及以往更新的频率。
  • 来自用户: 报告周期、关键成果与失利、指标变化、需要董事会提供意见或批准的具体事项、需要处理的敏感问题,以及此次内容是邮件更新还是幻灯片演示文稿。

工作流

  1. 确定格式和频率 — 月度邮件更新(种子轮/Series A 阶段的常见形式,少于 800 词)、季度董事会演示文稿(Series A 及之后阶段,20-30 张幻灯片,提前 48 小时发送供会前阅读)、月度精简演示文稿(8-12 张幻灯片),或临时更新(一页、一个主题,发生重大事件时立即发送)。早期阶段默认采用月度邮件。
  2. 收集 11 个部分的内容 — 按照下方框架逐一梳理每个部分。每个部分都指定了一位 C-suite 负责人。每个部分均采用“标题 - 数据 - 叙述 - 请求/下一步”结构。
  3. 开篇点明要旨 — 用 1-3 句话撰写执行摘要,概括最重要的一项信息。董事会成员每季度会看 10 份以上的演示文稿。最迟在第 3 张幻灯片呈现关键信息。有些投资者只会阅读摘要。
  4. 采用坏消息传达流程 — 如果任何部分涉及负面进展,请使用透明传达框架。绝不要掩盖坏消息。董事会最终总会知道,拖得越晚,情况就越糟。
  5. 提出具体请求 — 每次更新都应以具体、可执行的请求收尾。尽可能写明相关人员姓名。无法为你提供帮助的投资者也无法创造价值。
  6. 优化浏览体验 — 投资者阅读更新的时间只有 3-5 分钟。将关键数字加粗,用表格呈现指标,每段控制在 2-3 句话。指标仪表板最多列出 6-8 项 KPI,并附上目标和状态。

输出格式

邮件更新应输出为可直接粘贴到邮件中的 Markdown。董事会演示文稿应输出为结构化 Markdown,每张幻灯片对应一个 H3 标题。

11 部分框架
#部分负责人应包含的内容
1执行摘要CEO三句话:当前状况、重大事件、下一步方向
2关键指标仪表板COO以表格形式列出 6-8 项 KPI,并附目标和状态标识
3财务更新CFO损益摘要、现金可支撑时间、烧钱倍数趋势、计划偏差
4收入与销售管线CROARR 瀑布图、NRR、销售管线阶段,以及附置信度的重点交易
5产品更新CPO已发布功能、后续工作、用户影响证据、PMF 信号
6增长与营销CMO各渠道 CAC、对销售管线的贡献、渠道测试结果
7工程与技术CTO开发速度趋势、技术债务比率、正常运行时间、安全状态
8团队与人员CHRO实际员工人数与计划的对比、招聘管线、人员流失率、员工敬业度评分
9风险与安全CISO安全控制状态、合规截止日期、事件、前三大风险
10战略展望CEO按优先级排序的下季度重点、需要董事会作出的决策、具体请求
11附录—详细财务数据、完整销售管线、留存率图表、员工人数明细

每个部分都遵循:标题 - 数据 - 叙述 - 请求/下一步。

框架与最佳实践

四幕叙事结构

将此结构应用于每个部分,尤其是在解释偏差时:

  1. 此前的目标 — 我们承诺要做什么
  2. 当前的实际情况 — 实际发生了什么
  3. 差距说明 — 原因是什么(承担责任,而非找借口)
  4. 补救措施 — 具体修正方案及时间线

此结构适用于正面和负面情况。

坦诚传达坏消息
  1. 直接陈述事实。“我们的第三季度收入目标未达成,差了 22%。”不要委婉其辞。
  2. 承担责任。“两笔价值 18 万美元 ARR 的企业交易因我们未预料到的采购延迟推迟到了第四季度。”不要先讲背景或找借口。
  3. **证明你理解问题。**展示能够解释根本原因的分析。
  4. 提出具体的修正方案。“我们已在销售流程中加入采购跟踪,并为企业交易时间线增加了 30 天的缓冲。”
  5. 更新预测。“修订后的第四季度目标为 $X。”提供置信度,而非单点估算:“高置信度为 260 万美元;若两笔后期交易成交,最高可达 290 万美元。”
  6. 如有需要,请求帮助。“如果能帮忙引荐他们的 CFO,采购流程会更快。”

投资者会原谅糟糕的季度表现,但不会原谅创始人隐瞒问题,直到问题演变成危机。

指标展示规则
  • **始终展示趋势。**对比当前、上一周期和计划。单个数字毫无意义。
  • **统一时间范围。**不要在同一张表中混用月度和年化数字。
  • **突出偏差。**任何偏离计划超过 10%(无论高于还是低于)的指标都要加粗。
  • **包含单位经济效益。**CAC、LTV 和回本周期能说明仅凭营收无法呈现的情况。
  • 以月数而非金额展示现金可支撑时间。“按当前消耗速度还能维持 14 个月”比“银行账户里有 210 万美元”更具参考价值。
  • **营收预测需标注置信度。**切勿只提供单点估算。
  • 为每项与目标的偏差提供一句话解释。
更新频率指南
格式适用时机长度分发时间
月度邮件从种子轮到 A 轮少于 800 字次月第一周
季度董事会演示文稿A 轮及之后20-30 张幻灯片会议前 48 小时发送预读材料
月度精简演示文稿任何阶段8-12 张幻灯片指标、财务数据、销售管线、风险
临时更新重大事件1 页,1 个主题立即发送
融资演示文稿融资前聚焦市场/愿景以促成交易的请求为结构
常见错误
  1. 篇幅过长 — 季度演示文稿控制在 25-30 张幻灯片以内
  2. 指标没有目标参照 — 每个数字都需要比较基准
  3. 缺少叙事 — 没有故事的数据只是噪音
  4. 坏消息藏得太深 — 应在前三张幻灯片中呈现
  5. 请求含糊不清 — “能帮忙引荐就太好了”不如“请引荐 Stripe 的运营副总裁”
  6. 偏差缺乏解释 — 每项未达标都需要一句话说明
  7. 附录内容陈旧 — 每个周期都要更新支撑数据
  8. 演示文稿只适合阅读,不适合演讲 — 幻灯片应辅助交流,而不是取而代之
  9. 只在进展顺利时发送更新 — 沉默时期会因此引发怀疑
  10. 只有叙事,没有数据 — 无法持续追踪进展

相关技能

  • process-docs — 可串联使用,为内部董事会更新准备流程创建 SOP,确保每个周期的质量一致。
  • pitch-deck — 当董事会更新显示需要启动融资时,或当更新兼作现有投资者续投演示文稿时,可串联使用。

示例

示例 1:月度投资人邮件

用户:“撰写我的 2 月投资人动态。MRR 达到 $85K(高于 $72K),我们聘请了一位工程副总裁,但失去了最大的客户。”

良好输出摘录:

**概要:**2 月 MRR 增长 18%,达到 $85K,这得益于中型市场业务的强劲拓展;但由于 Acme Corp($12K/月)进行预算重组,且此事不在我们的控制范围内,我们失去了这位客户。我们聘请了 Sarah Chen 担任工程副总裁(曾任职于 Stripe)。总体而言:产品推进速度领先计划,净收入留存略低于计划。剩余 14 个月的现金 runway。

关键指标

指标2 月1 月与计划相比
MRR$85K$72K+3%
净新增 ARR$156K$120K+8%
总流失$12K$2K-$10K
现金消耗$110K$105K符合计划
Runway14 个月15 个月符合计划

**关于客户流失:**Acme Corp 的新任 CFO 在全公司削减成本期间,取消了所有 ARR 低于 $50K 的软件合同。我们提前 30 天收到通知,并尝试提供更低价的套餐;对方拒绝了。这并非产品问题,但暴露出收入集中风险——Acme 占 MRR 的 14%。我们正在分散前 10 大客户的收入占比。

需要的帮助

  1. 引荐中型市场金融科技公司的人脉——具体来说是运营副总裁或合规负责人。
  2. 推荐一位高级后端工程师。已附职位描述。
示例 2:传达重大目标未达成

用户:“我们将大幅未达成季度目标。请帮我撰写这份动态。”

**良好输出方式:**在执行摘要开篇直截了当地说明未达成目标的情况。量化差距。用承担责任的措辞在 2 至 3 句话内解释根本原因,不要找借口。随后立即给出补救计划,包括时间表、带置信度的修订预测。最后明确提出需要哪些帮助。不要让坏消息成为读者看到的最后内容——结尾要始终展望前进方向,并给出具体的后续步骤。

评论

支持 Markdown