Back to Details

business-literacy

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Business Literacy

商业素养

Before Starting

开始之前

Check for EM context first. If 
.agents/em-context.md
exists, read it.
If 
.agents/em-context.md
does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.
If a specific person is central to the conversation and 
.agents/reports/[name].md
does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update 
.agents/em-context.md
or 
.agents/reports/[name].md
automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

首先确认工程经理（EM）的背景信息。如果
.agents/em-context.md
文件存在，请先阅读该文件。
如果
.agents/em-context.md
文件不存在，请先询问并保存一份基础的经理资料，之后再提供详细建议：职位/头衔、团队规模、团队使命或负责领域，以及当前面临的挑战或优先级。
如果对话核心涉及特定人员且
.agents/reports/[name].md
文件不存在，请先询问并保存该人员的基础资料，之后再提供详细建议：职位/级别、任职年限、优势，以及当前的挑战或成长方向。

若对话后续出现可长期留存的新信息，请自动更新
.agents/em-context.md
或
.agents/reports/[name].md
文件。仅保存稳定的事实和规律，不保存猜测、暂时的情绪或未明确的解读。

Response Style

响应风格

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.
Default to:
  • State the likely diagnosis or recommendation first
  • Ask at most 2-3 targeted questions only if the missing context changes the advice
  • Give the next concrete action and, when useful, exact wording the manager can use
  • Mention the relevant framework briefly, but do not explain every part of it
  • Offer a deeper version only after the direct answer
首次回答需简洁实用。除非用户要求深入讲解，否则不要直接输出完整框架。
默认遵循以下原则：
  • 先说明初步判断或建议
  • 仅当缺失的信息会影响建议内容时，提出最多2-3个针对性问题
  • 给出具体的下一步行动，必要时提供经理可直接使用的话术
  • 简要提及相关框架，但无需解释每个部分
  • 在直接回答后，再提供深入版本的选项

How to Use This Skill

本技能的使用场景

  • Need to decode a business term you heard in a meeting → The Terms That Come Up Most
  • Want to make the case for engineering work in business language → Using These in Practice
  • Want to build credibility with business leaders or the P&L owner → The 3 Layers of Business Impact
  • 需要解读会议中听到的商业术语 → 查看「高频出现的术语」部分
  • 想用商业语言为工程工作争取支持 → 查看「实践应用」部分
  • 希望与业务领导者或损益负责人建立可信度 → 查看「业务影响的三层框架」部分

Default Response Shape

默认响应结构

When translating business concepts for an EM, make the answer operational:
  1. Plain-English definition: explain the term without finance theater.
  2. Why an EM should care: connect it to roadmap, staffing, reliability, cost, or prioritization.
  3. Engineering translation: show how engineering work can move or protect the metric.
  4. Example sentence: give wording the EM can use with a business stakeholder.
  5. Caveat: note where the metric can mislead or be gamed.
For stakeholder-facing asks, end with a concise business-framed version of the engineering request.
为工程经理解读商业概念时，需确保回答具备可操作性：
  1. 直白定义： 用通俗语言解释术语，避免专业套话。
  2. EM为何要关注： 将术语与路线图、人员配置、可靠性、成本或优先级关联起来。
  3. 工程视角转化： 说明工程工作如何影响或保护该指标。
  4. 示例话术： 提供EM可用于与业务利益相关者沟通的具体表述。
  5. 注意事项： 指出该指标可能存在的误导性或可被操纵的情况。
针对面向利益相关者的请求，结尾需附上以商业视角精简表述的工程需求。

Why This Matters

重要性说明

Engineers can succeed without understanding business language. Engineering managers cannot. If you want to have influence, convince stakeholders, and shape the roadmap — you need to speak the language leadership uses.
Understanding these terms also makes you a better advocate for your team. When you can connect engineering decisions to business outcomes — margins, retention, CAC — you move from "we need this refactor" to "this reduces our hosting cost by 15% and improves our gross margin."
工程师无需理解商业语言也能取得成功，但工程经理不行。如果你想要拥有影响力、说服利益相关者并主导路线图，就必须掌握领导层使用的语言。
理解这些术语还能让你更好地为团队发声。当你能将工程决策与业务成果（利润率、留存率、CAC）关联起来时，你的表述就会从「我们需要重构」转变为「这项工作能将托管成本降低15%，提升我们的毛利率」。

The Terms That Come Up Most

高频出现的术语

Money In

收入类

ARR (Annual Recurring Revenue) — total yearly revenue from subscriptions. The core metric for SaaS companies. When leadership says "we're at $5M ARR," this is it.
MoM (Month-over-Month) — growth rate from one month to the next. A 10% MoM growth rate is exceptional.
TAM (Total Addressable Market) — the total revenue potential if you captured 100% of your target market. Used to justify investment size.
ARR (Annual Recurring Revenue) — 订阅业务的年度总收入，是SaaS公司的核心指标。当领导层提到「我们的ARR达到500万美元」时，指的就是这个指标。
MoM (Month-over-Month) — 月度环比增长率。10%的MoM增长率属于优秀水平。
TAM (Total Addressable Market) — 若完全占领目标市场可获得的总收入潜力，用于论证投资规模的合理性。

Costs

成本类

COGS (Cost of Goods Sold) — costs directly tied to delivering the product (hosting, infra, third-party APIs). For SaaS, engineering teams directly influence COGS.
Gross Margin — 
(Revenue - COGS) / Revenue
. For SaaS, 70–80% is healthy. Below 60% means your delivery costs are high relative to what customers pay. This is where engineering decisions show up in financials. Reducing third-party API dependency, optimizing infra costs, or improving efficiency all improve gross margin.
OpEx (Operating Expenses) — ongoing costs not directly tied to production: salaries, rent, marketing.
CapEx (Capital Expenditure) — large investments with long-term value. Building a new data center is CapEx; monthly AWS bill is OpEx.
Burn Rate — how much cash the company spends per month. High burn + low revenue = limited runway.
Net Margin — what's left after ALL costs. Most startups have negative net margin for years.
EBITDA — Earnings Before Interest, Taxes, Depreciation, Amortization. A profitability measure that strips out financing. Matters more at late-stage.
COGS (Cost of Goods Sold) — 与产品交付直接相关的成本（托管费、基础设施、第三方API费用）。对于SaaS公司，工程团队直接影响COGS。
Gross Margin — 
(Revenue - COGS) / Revenue
。对于SaaS公司，70-80%的毛利率属于健康水平。若低于60%，说明交付成本相对于客户付费过高。这是工程决策在财务数据中的体现。减少第三方API依赖、优化基础设施成本或提升效率，都能提高毛利率。
OpEx (Operating Expenses) — 与生产无直接关联的持续性成本：薪资、租金、营销费用等。
CapEx (Capital Expenditure) — 具有长期价值的大额投资。例如，建设新数据中心属于CapEx；月度AWS账单属于OpEx。
Burn Rate — 公司每月的现金消耗额。高烧钱率+低营收=有限的现金流存续时间。
Net Margin — 扣除所有成本后的剩余利润。大多数初创公司在成立后的数年内净利润率为负。
EBITDA — 息税折旧摊销前利润，是剔除融资因素后的盈利能力衡量指标，在后期阶段更为重要。

Customers

客户类

CAC (Customer Acquisition Cost) — average cost to acquire a customer. If you spend $100k on marketing and get 100 customers, CAC = $1,000.
LTV (Lifetime Value) — average revenue from a customer over their full relationship. LTV should be 3–5x CAC for a healthy business. If not, growth is expensive.
Churn — percentage of customers lost per period. The silent killer. 5% monthly churn = ~46% of customers gone per year.
Retention — the inverse of churn. Net Revenue Retention (NRR) > 100% means expansion from existing customers outweighs churn.
GRR (Gross Revenue Retention) — what percentage of last year's revenue you kept, excluding expansion.
NPS (Net Promoter Score) — "How likely are you to recommend us?" Scores 9–10 = promoters, 7–8 = passives, 0–6 = detractors.
CAC (Customer Acquisition Cost) — 获取单个客户的平均成本。若投入10万美元营销费用获得100个客户，则CAC=1000美元。
LTV (Lifetime Value) — 客户在整个合作周期内带来的平均收入。健康的业务中，LTV应是CAC的3-5倍，否则增长成本过高。
Churn — 每个周期内流失的客户比例，是隐形的业务杀手。月度流失率5%意味着每年约46%的客户会流失。
Retention — 流失率的反向指标。净收入留存率（NRR）>100%意味着现有客户的拓展收入超过了流失收入。
GRR (Gross Revenue Retention) — 上一年度收入的留存比例，不含拓展收入。
NPS (Net Promoter Score) — 「你向他人推荐我们的可能性有多大？」评分9-10分的是推荐者，7-8分的是中立者，0-6分的是贬损者。

Business Health

业务健康度

Default Alive — if you stop raising money, does current revenue growth make you profitable before cash runs out? If not, you're "default dead."
Moat — what makes you hard to copy. Deep tech, network effects, proprietary data, brand. Engineering decisions (especially around data and platform) often build or erode moats.
AARRR (Pirate Metrics) — Acquisition, Activation, Retention, Referral, Revenue. A framework for diagnosing where growth is leaking. If retention is 20%, pouring money into acquisition just fills a leaky bucket. Fix the leak first.
Default Alive — 若停止融资，当前的营收增长能否让公司在现金耗尽前实现盈利？若不能，则属于「默认死亡」状态。
Moat — 公司的竞争壁垒，即难以被复制的优势。比如深度技术、网络效应、专有数据、品牌影响力。工程决策（尤其是数据和平台相关的决策）往往会强化或削弱竞争壁垒。
AARRR (Pirate Metrics) — 获取、激活、留存、推荐、收入，是诊断增长漏洞的框架。若留存率仅为20%，投入资金获取客户就像往漏水的桶里倒水，应先修复漏洞。

Using These in Practice

实践应用

When proposing technical work, translate it:
  • Not: "we need to migrate off this legacy API" → Yes: "this API costs us $40k/year and is our top cause of outages; removing it improves gross margin and reduces customer churn"
  • Not: "we should invest in platform" → Yes: "right now each new feature takes 2 weeks to wire up; a platform investment gets that to 2 days, directly improving our CAC by reducing time-to-value"
When reviewing the roadmap, ask the business question: which AARRR stage are we weakest at right now? Invest there first.
在提出技术工作需求时，需进行转化表述：
  • 不要说：「我们需要迁移出这个遗留API」→ 要说：「该API每年花费我们4万美元，也是导致故障的首要原因；移除它能提升毛利率并降低客户流失率」
  • 不要说：「我们应该投资平台建设」→ 要说：「目前每个新功能需要2周时间完成对接；平台投资能将这个时间缩短至2天，通过缩短价值交付周期直接降低CAC」
在评审路线图时，要问自己这个业务问题：我们目前在AARRR的哪个阶段最薄弱？优先在该阶段投入资源。

The 3 Layers of Business Impact

业务影响的三层框架

EMs who drive real business impact typically work across three layers, in increasing order of difficulty:
Layer 1 — Product: Do you and your team understand how your features are used? Have a dashboard showing feature usage that everyone can see. Know the product's AARRR metrics. A feature that ships but nobody adopts has zero impact.
Layer 2 — Business Economics: Can you connect your team's work to what the business cares about financially? Find the "GM" — the manager who owns P&L (profit and loss) for the business area your team serves. Have a conversation: what do they care about, and how does your team's work connect to it? Once you can answer that, start using business metrics in technical arguments. "This saves $125k/year" wins conversations that "better infrastructure" loses.
Layer 3 — Industry/Domain: Do you understand the industry your company operates in well enough to speak credibly with domain experts? Most engineering managers are domain-agnostic, which makes non-technical leaders underestimate them.
Three levels of domain knowledge:
  • Level 1 (Passive): Know the terminology. Industry-specific terms you hear repeatedly but don't fully understand undermine your credibility. Spend 10–15 minutes/week on industry content (articles, newsletters, an LLM tutor). Ask it to explain the domain as an instructor would.
  • Level 2 (Sharing): Share what you learn. Post a relevant article with your takeaway in a shared channel with peers and PMs. People who see you engaging with the domain start treating you as a peer.
  • Level 3 (Insider): Find one concrete way to experience the industry firsthand. Shadow a customer, use your own product as an actual user for a month, or (for the committed) get a domain certification. The gap between knowing the domain and experiencing it is the difference between being taken seriously and being tolerated.
真正推动业务影响的工程经理通常会在以下三个层面开展工作，难度依次递增：
第一层 — 产品： 你和团队是否了解功能的使用情况？要有一个全员可见的功能使用仪表盘。熟悉产品的AARRR指标。一个发布后无人使用的功能毫无价值。
第二层 — 业务经济： 你能否将团队的工作与业务关注的财务指标关联起来？找到「GM」——即你团队所服务业务领域的损益负责人。与其沟通：他们关注什么，你的团队工作如何与之关联？一旦能回答这个问题，就开始在技术论证中使用业务指标。「这项工作每年能节省12.5万美元」比「更好的基础设施」更能说服他人。
第三层 — 行业/领域： 你是否足够了解公司所处的行业，能与领域专家进行可信的沟通？大多数工程经理是领域无关的，这会让非技术领导者低估他们。
领域知识分为三个等级：
  • Level 1（被动了解）： 掌握行业术语。反复听到但不完全理解的行业术语会损害你的可信度。每周花10-15分钟阅读行业内容（文章、通讯，或借助LLM导师），让它像讲师一样为你讲解领域知识。
  • Level 2（主动分享）： 分享所学内容。在与同事和产品经理共享的频道中发布相关文章并附上你的见解。当人们看到你在参与领域内容时，会开始将你视为同行。
  • Level 3（内行）： 找到一种亲身体验行业的具体方式。跟随客户实习、以真实用户身份使用自家产品一个月，或者（对于投入度高的人）获取领域认证。了解领域和体验领域之间的差距，就是被认真对待和被容忍的区别。

Dive Deeper

深入学习

If the user asks where a framework came from, wants to read the original article, or wants more context on any topic in this skill — read 
references/sources.md
 for the full list of source articles (with links) and books.
如果用户询问某个框架的来源、想要阅读原文，或需要本技能中任何主题的更多背景信息，请查看
references/sources.md
获取完整的来源文章（含链接）和书籍列表。

Related Skills

相关技能

  • working-with-pm
    — PMs use this language constantly; understanding it makes you a real partner
  • roadmap-planning
    — Tech debt and platform work need business justification to get prioritized
  • developer-productivity
    — For connecting engineering metrics (DORA, velocity) to business outcomes
  • influence
    — Business fluency directly enables the 3rd level of positioning (being trusted)
  • working-with-pm
    — 产品经理经常使用这些语言，理解它们能让你成为真正的合作伙伴
  • roadmap-planning
    — 技术债务和平台工作需要商业论证才能获得优先级
  • developer-productivity
    — 用于将工程指标（DORA、交付速度）与业务成果关联
  • influence
    — 商业流利度直接助力第三层定位（获得信任）