business-literacy

商业素养

开始之前

先检查是否有 EM 背景信息。如果 .agents/em-context.md 存在，请阅读。

如果 .agents/em-context.md 不存在，请先询问并保存一份精简的经理人档案，再提供详细建议：角色／职务、团队规模、团队使命或负责领域，以及当前挑战或优先事项。

如果对话的核心涉及某个具体人员，且 .agents/reports/[name].md 不存在，请先询问并保存该人员的精简档案，再提供详细建议：职务／级别、任职时长、优势，以及当前挑战或成长领域。

如果后续对话揭示了长期有效的新背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式，不要保存猜测、暂时的挫败情绪或尚未解决的解读。

回复风格

首次回复应简洁实用。除非用户要求深入探讨，否则不要一股脑给出整套框架。

默认采用以下方式：

• 先说明可能的诊断或建议
• 只有在缺失的背景信息会改变建议时，才提出最多 2～3 个有针对性的问题
• 给出下一步的具体行动，并在有用时提供经理可以直接使用的确切措辞
• 简要提及相关框架，但不要逐一解释所有部分
• 直接回答后，再询问是否需要更深入的版本

---

如何使用此技能

• 需要解读会议中听到的商业术语 → 最常出现的术语
• 想用商业语言说明工程工作的价值 → 实践应用
• 想在商业领导者或损益负责人面前建立公信力 → 商业影响的 3 个层次

---

默认回复结构

向 EM 解释商业概念时，应让回答便于实际应用：

1. 通俗定义： 不卖弄财务术语，解释该术语。
2. EM 为何应关注： 将其与路线图、人员配置、可靠性、成本或优先级联系起来。
3. 工程层面的解读： 说明工程工作如何推动或保障该指标。
4. 示例表述： 提供 EM 可以对商业相关方使用的措辞。
5. 注意事项： 指出该指标可能产生误导或被操纵的情况。

针对面向相关方的请求，结尾应给出简洁的、以业务为框架的工程诉求表述。

---

为什么这很重要

工程师即使不了解商业语言，也能取得成功；工程经理则不行。如果你想发挥影响力、说服相关方并塑造路线图，就需要使用领导层的语言。

理解这些术语也能让你更好地为团队争取支持。当你能把工程决策与业务成果联系起来——例如利润率、留存率、CAC——你就能把“我们需要重构”转化为“这能降低 15% 的托管成本，并提高毛利率”。

---

最常出现的术语

收入

ARR（年度经常性收入） — 订阅带来的年度总收入。这是 SaaS 公司的核心指标。领导层说“我们的 ARR 达到 $5M”时，指的就是它。

MoM（环比增长率） — 从一个月到下一个月的增长率。10% 的 MoM 增长率非常出色。

TAM（总体可寻址市场） — 如果你占领目标市场的 100%，所能获得的总收入潜力。常用于论证投资规模。

成本

COGS（销售成本）——与交付产品直接相关的成本（托管、基础设施、第三方 API）。对于 SaaS，工程团队会直接影响 COGS。

毛利率——(Revenue - COGS) / Revenue。对于 SaaS，70–80% 属于健康水平。低于 60% 意味着相对于客户支付的金额，交付成本过高。**工程决策会体现在财务数据中。**减少对第三方 API 的依赖、优化基础设施成本或提高效率，都能提升毛利率。

OpEx（运营费用）——与生产不直接相关的持续性成本：薪资、租金、营销。

CapEx（资本支出）——具有长期价值的大额投资。建设新的数据中心属于 CapEx；每月的 AWS 账单属于 OpEx。

Burn Rate（资金消耗率）——公司每月花掉多少现金。高资金消耗 + 低收入 = 跑道有限。

净利率——扣除所有成本后剩下的部分。大多数初创公司多年来的净利率都为负。

EBITDA——息税折旧摊销前利润。剔除融资因素的盈利能力衡量指标。在后期阶段更重要。

客户

CAC（客户获取成本）——获取一位客户的平均成本。如果花费 10 万美元做营销并获得 100 位客户，CAC = 1,000 美元。

LTV（客户生命周期价值）——客户在整个合作关系期间带来的平均收入。健康的业务中，LTV 应为 CAC 的 3–5 倍。否则，增长成本就会很高。

流失率——每个周期内流失的客户百分比。这是悄无声息的杀手。月流失率为 5% = 每年约有 46% 的客户流失。

留存率——与流失率相反。净收入留存率（NRR）> 100% 意味着现有客户带来的扩张收入超过了流失收入。

GRR（总收入留存率）——在不计扩张收入的情况下，去年收入中保留下来的比例。

NPS（净推荐值）——“你有多大可能向他人推荐我们？”评分为 9–10 的是推荐者，7–8 的是被动者，0–6 的是贬损者。

业务健康状况

Default Alive（默认存续）——如果停止融资，当前收入增长能否在现金耗尽前实现盈利？如果不能，你就是“默认死亡”。

护城河——让你难以被复制的优势。深厚的技术、网络效应、专有数据、品牌。工程决策（尤其是围绕数据和平台的决策）往往会构建或削弱护城河。

AARRR（海盗指标）——获客、激活、留存、推荐、收入。用于诊断增长在哪个环节流失的框架。如果留存率只有 20%，继续往获客上砸钱只会让漏水的桶装得更多。先堵住漏洞。

---

在实践中使用这些概念

提出技术工作时，要用业务语言来表达：

• 不要说：“我们需要迁移掉这个旧版 API” → 要说：“这个 API 每年花费我们 4 万美元，也是导致故障的首要原因；移除它能提高毛利率并降低客户流失率”
• 不要说：“我们应该投资平台建设” → 要说：“目前每项新功能都需要 2 周才能完成接入；投资平台建设可以将其缩短至 2 天，直接通过缩短用户获得价值的时间来降低 CAC”

审查路线图时，提出业务问题：目前哪个 AARRR 阶段最薄弱？优先在那里投入。

---

业务影响的 3 个层次

能推动真正业务影响的 EM 通常会逐步深入以下 3 个层次，难度依次递增：

第 1 层 — 产品： 你和团队是否了解功能的使用情况？建立一个所有人都能查看的功能使用情况仪表板。了解产品的 AARRR 指标。发布了却无人使用的功能，影响力为零。

第 2 层 — 业务经济： 你能否将团队的工作与业务在财务方面的关注点联系起来？找到负责你们团队所服务业务领域损益（P&L）的“GM”——经理。与其交流：他们关心什么？团队的工作与之有何关联？能回答这些问题后，就开始在技术论证中使用业务指标。“这每年能节省 12.5 万美元”比“基础设施更好”更能说服人。

第 3 层 — 行业／领域： 你是否足够了解公司所处的行业，能够与领域专家进行可信的交流？大多数工程经理对领域缺乏了解，这会让非技术领导低估他们。

领域知识分为 3 个层次：

• 第 1 级（被动了解）： 了解相关术语。反复听到却不完全理解的行业专有术语会损害你的可信度。每周花 10–15 分钟阅读行业内容（文章、新闻通讯，或向大模型请教）。请大模型像讲师一样讲解这个领域。
• 第 2 级（分享交流）： 分享你的学习所得。在与同事和 PM 共同使用的频道中，分享一篇相关文章并写下你的收获。看到你积极了解该领域的人，会开始把你当作同行。
• 第 3 级（亲身体验）： 找一种切实可行的方式，亲身体验这个行业。跟随客户观察、连续一个月以真实用户的身份使用自己的产品，或者（如果愿意投入更多）考取领域认证。了解领域与亲身体验领域之间的差距，决定了你是会受到认真对待，还是仅仅被容忍。

---

深入了解

如果用户询问某个框架的出处、想阅读原文，或想进一步了解本技能中的某个主题，请阅读 references/sources.md，其中列出了完整的来源文章（含链接）和书籍。

---

相关技能

• working-with-pm — PM 经常使用这些术语；理解它们能让你成为真正的合作伙伴
• roadmap-planning — 要让技术债务和平台工作获得优先级，需要业务层面的论证
• developer-productivity — 了解如何将工程指标（DORA、速度）与业务成果联系起来
• influence — 业务素养能直接助力你达到定位的第 3 个层次（赢得信任）