主题
02 产品术语
这些术语是产品经理的「专业语言」。掌握它们，你才能在需求评审、版本规划、数据复盘中游刃有余。
为什么 PM 要懂产品术语？
产品术语是 PM 最核心的工作语言。你会在以下场景中高频使用：
- 老板问你：「我们的产品找到 PMF 了吗？North Star Metric 是什么？」
- 需求评审会上：「这个 User Story 的 Acceptance Criteria 是什么？排在 Backlog 的什么位置？」
- 季度规划时：「我们的 OKR 是什么？Roadmap 上的优先级怎么排？」
- 和工程师讨论：「这个功能先做 MVP，然后通过 A/B Test 验证，再决定是否全量发布。」
术语详解
一、产品方法论
MVP -- 最小可行产品
| 项目 | 内容 |
|---|---|
| 英文全称 | Minimum Viable Product |
| 含义 | 用最小的成本和最短的时间，做出一个能验证核心假设的产品版本。重点不是「做得少」，而是「验证得快」。 |
| 核心理念 | 先交付一个能解决核心问题的完整方案，而不是一个大方案的半成品。 |
MVP 的核心理念可以用下面的经典对比来理解：
正确的 MVP 理念（每个阶段都能用）：
阶段 1 阶段 2 阶段 3 阶段 4
┌──────┐ ┌──────┐ ┌───────┐ ┌────────┐
│ │ │ __o │ │ ____ │ │ ______ │
│ \o/ │ │ _`\<, │ │ / \│ │| | │
│_/█\_ │ │(*)/(*)│ │(*) (*)│ │| [] | │
│ / \ │ │ │ │ │ │(*) (*)│
└──────┘ └──────┘ └───────┘ └────────┘
滑板 自行车 摩托车 汽车
能移动! 更快了! 很快了! 完美体验!
✅ 每个版本都能独立使用，解决「从 A 到 B」的核心问题
错误的 MVP 理念（半成品不能用）：
阶段 1 阶段 2 阶段 3 阶段 4
┌──────┐ ┌──────┐ ┌───────┐ ┌────────┐
│ │ │ │ │ ____ │ │ ______ │
│ () │ │ ()() │ │/ \ │ │| | │
│ │ │ ──── │ │ │ │| [] | │
│ │ │ │ │() ()│ │() () │
└──────┘ └──────┘ └───────┘ └────────┘
一个轮子 底盘+轮子 车壳 完整汽车
不能用! 不能用! 还是不能用! 终于能用了...
❌ 前三个阶段用户都无法使用，无法获得任何反馈实际举例： 假设你想做一个外卖 App：
- 错误做法： 花 6 个月开发完整的 App（商家入驻系统 + 用户下单 + 骑手调度 + 支付结算）
- MVP 做法： 先在微信群里接单，用 Excel 记录订单，自己送外卖。验证了「用户愿意在线点外卖」这个核心假设后，再开发系统。
PMF -- 产品市场匹配
| 项目 | 内容 |
|---|---|
| 英文全称 | Product-Market Fit |
| 含义 | 产品满足了一个真实且足够大的市场需求，用户愿意主动使用和付费，增长开始自然发生。 |
| 判断标准 | Sean Ellis 测试：问用户「如果这个产品明天消失，你会怎么想？」如果超过 40% 的用户回答「非常失望」，说明达到了 PMF。 |
| 实际举例 | Slack 早期发现团队沟通效率低下是一个真实痛点，当用户开始主动邀请同事加入、自然增长时，就是达到了 PMF。而很多创业产品失败，就是因为解决了一个「伪需求」，永远找不到 PMF。 |
PLG -- 产品驱动增长
| 项目 | 内容 |
|---|---|
| 英文全称 | Product-Led Growth |
| 含义 | 以产品本身作为获客、激活、留存和变现的主要驱动力，而不是依赖销售团队。用户先免费使用产品，体验到价值后自主付费升级。 |
| 典型模式 | 免费试用（Freemium）→ 用户体验到价值 → 自主升级付费版 → 邀请同事/朋友使用 |
| 实际举例 | Notion、Figma、Zoom 都是 PLG 的典型代表。Figma 让设计师免费使用，设计师觉得好用后邀请整个团队，团队达到一定规模后需要升级付费版。获客成本极低，K-Factor 很高。 |
SLG -- 销售驱动增长
| 项目 | 内容 |
|---|---|
| 英文全称 | Sales-Led Growth |
| 含义 | 以销售团队为核心驱动力，通过销售人员主动联系客户、演示产品、签订合同来获客。常见于企业级 (To B) 产品。 |
| 实际举例 | Salesforce、SAP 等企业级软件，通常需要销售团队花数周甚至数月与客户沟通需求、做方案演示、谈价格、签合同。CAC 很高，但 LTV 也很高（大客户年费可达几十万甚至上百万）。 |
二、需求与迭代管理
| 术语 | 英文全称 | 含义解释 | 实际举例 |
|---|---|---|---|
| Iteration / Sprint | Iteration / Sprint | 迭代/冲刺，指固定时间周期（通常 1-2 周）内完成一批需求的开发、测试和上线。是敏捷开发的核心节奏。 | 团队约定每两周为一个 Sprint：周一 Sprint 计划会确定本轮要做的需求 → 两周内完成开发和测试 → 周五上线发布 → 下周一开始新的 Sprint。 |
| User Story | User Story (用户故事) | 从用户角度描述需求的标准格式：「作为 [角色]，我想要 [功能]，以便 [价值]」。帮助团队始终站在用户角度思考需求。 | 「作为一个外卖用户，我想要在下单时选择送达时间，以便我能在合适的时间收到外卖。」这比「添加一个预约送达功能」更清晰地表达了用户需求和背后的价值。 |
| Acceptance Criteria | Acceptance Criteria (验收标准) | 定义一个 User Story「完成」的具体条件，是开发和测试的依据。好的验收标准应该具体、可测试、无歧义。 | 上面那个 User Story 的 AC：(1) 用户可以选择当天 30 分钟后的任意整点/半点作为送达时间；(2) 选择后在订单详情中显示预计送达时间；(3) 如果所选时间段无骑手可配送，提示用户更换时间。 |
| Backlog | Product Backlog (产品待办列表) | 所有待做需求的有序列表。排在最上面的优先级最高，会在最近的 Sprint 中被完成。PM 的核心工作之一就是管理和排序 Backlog。 | 某电商 App 的 Backlog 可能是：(1) 支持微信支付 [P0] (2) 商品搜索结果页优化 [P1] (3) 用户评价功能 [P1] (4) 分享到朋友圈 [P2] ... 共 200+ 条需求。 |
| Roadmap | Product Roadmap (产品路线图) | 产品未来一段时间（通常是季度或年度）的规划蓝图。展示什么时间做什么功能，用于对齐团队和利益相关者的期望。 | Q1：完成支付系统改造 + 搜索优化 → Q2：上线会员体系 + 个性化推荐 → Q3：国际化（支持英语市场）→ Q4：开放平台（第三方接入）。Roadmap 不是承诺，是方向性的计划。 |
| 灰度发布 | Canary Release / Gradual Rollout | 新功能不一次性对所有用户开放，而是先对一小部分用户开放（如 1% → 5% → 20% → 100%），观察数据无异常后再逐步扩大范围。降低了上线风险。 | 某 App 做了新的首页推荐算法，先对 5% 的用户灰度。发现这 5% 的用户点击率提升了 15%，且无崩溃等问题，再逐步扩大到 100%。如果数据下降，就回滚到旧版本，影响范围很小。 |
| Feature Flag | Feature Flag (功能开关) | 在代码中嵌入的「开关」，可以在不重新发版的情况下，远程控制某个功能的开启/关闭。是灰度发布的技术基础。 | 工程师在代码里加了一个开关 show_new_search = true/false。PM 可以在后台控制台把这个开关打开给特定用户群体，不需要重新发版。如果出问题，一秒钟就能关掉。 |
| A/B Test | A/B Test (A/B 测试) | 将用户随机分为两组（或多组），分别展示不同的方案，通过数据比较来确定哪个方案更好。是数据驱动决策的核心方法。 | 纠结购买按钮用红色还是绿色？做个 A/B Test：50% 用户看到红色按钮（A 组），50% 看到绿色按钮（B 组），跑一周后对比两组的点击率和转化率。数据说了算，不靠「我觉得」。 |
三、目标与度量
| 术语 | 英文全称 | 含义解释 | 实际举例 |
|---|---|---|---|
| OKR | Objectives and Key Results | 目标与关键成果，一种目标管理框架。O（Objective）是定性的方向目标，KR（Key Result）是定量的可衡量成果。强调聚焦和对齐。 | O：提升用户留存。KR1：30 日留存率从 20% 提升到 30%。KR2：用户月均使用天数从 5 天提升到 8 天。KR3：NPS 从 30 提升到 45。OKR 鼓励设定有挑战性的目标，完成 70% 就算成功。 |
| KPI | Key Performance Indicator | 关键绩效指标，用于衡量工作表现的量化指标。和 OKR 的区别在于：KPI 侧重「考核」，OKR 侧重「方向」；KPI 要求 100% 完成，OKR 完成 70% 即可。 | 客服团队 KPI：平均响应时间 < 5 分钟、问题解决率 > 90%、用户满意度 > 4.5 分。PM 的 KPI 可能包括：需求交付准时率、线上 Bug 率、核心指标达成率等。 |
| North Star Metric | North Star Metric (北极星指标) | 整个产品团队最重要的唯一核心指标。它应该能反映产品为用户创造的核心价值，并且与公司的长期增长强相关。 | Facebook 的北极星指标是 DAU（日活跃用户数）；Airbnb 是「预订间夜数」（Nights Booked）；Spotify 是「用户收听时长」。选择北极星指标的标准：(1) 能反映用户获得的核心价值 (2) 是先行指标而非滞后指标 (3) 整个团队都能为之努力。 |
四、文档与产出物
| 术语 | 英文全称 | 含义解释 | 实际举例 |
|---|---|---|---|
| PRD | Product Requirements Document | 产品需求文档，PM 最核心的产出物。详细描述一个功能的背景、目标、用户场景、功能规则、交互逻辑、数据埋点等。是开发和测试的依据。 | 一份「优惠券功能」的 PRD 可能包括：背景与目标、优惠券类型（满减/折扣/免邮）、领取规则、使用规则、叠加规则、过期规则、页面交互说明、异常情况处理、数据埋点需求等，通常几千字到上万字。 |
| Wireframe | Wireframe (线框图) | 用简单的线条和色块表示页面布局和元素位置的低保真草图。重点是信息架构和功能布局，不关注颜色、字体等视觉细节。 | PM 在讨论需求时画的简笔画草图就是 Wireframe：「这里放一个搜索框，下面是商品列表，每个商品卡片包含图片、标题、价格、购买按钮」。可以用纸笔画，也可以用 Balsamiq、Axure 等工具。 |
| Prototype | Prototype (原型) | 可交互的产品模拟，比线框图更接近真实产品的效果。用于在开发之前验证交互逻辑和用户体验。 | 用 Figma 或 Axure 做一个可以点击跳转的原型：用户点击商品 → 跳转到详情页 → 点击加入购物车 → 底部弹出提示。虽然没有真实数据，但交互体验接近最终产品。可以拿来做用户测试。 |
五、分析与洞察
| 术语 | 英文全称 | 含义解释 | 实际举例 |
|---|---|---|---|
| Persona | User Persona (用户画像) | 基于用户研究数据构建的虚拟典型用户形象。包括人口属性、行为特征、需求痛点、使用场景等。帮助团队在讨论需求时有共同的用户理解。 | 某生鲜电商的核心 Persona：「李阿姨，52 岁，退休教师，住在上海浦东，每天早上买菜，关注食材新鲜度和价格，不太会用复杂的 App 功能，喜欢有人推荐搭配。」有了这个画像，团队讨论「是否要加一键购买功能」时就有了共同的判断依据。 |
| 用户旅程 | User Journey (Map) | 用户从接触产品到完成目标的完整路径和体验记录。包括每个阶段的行为、想法、情绪和痛点。帮助 PM 发现体验瓶颈。 | 外卖用户旅程：饿了(触发) → 打开 App(进入) → 浏览餐厅(探索) → 选择菜品(决策) → 下单支付(行动) → 等待配送(等待) → 收到外卖(完成) → 评价(反馈)。在每个节点标注用户的情绪（等待时焦虑、收到时开心）和痛点（选择困难、配送慢）。 |
| 漏斗分析 | Funnel Analysis | 将用户的行为路径分解为多个步骤，分析每一步的转化率和流失率。名字来源于漏斗的形状——每一步都会流失一部分用户。 | 电商购买漏斗：浏览首页 (10000 人) → 查看商品详情 (3000 人, 30%) → 加入购物车 (600 人, 20%) → 提交订单 (300 人, 50%) → 完成支付 (240 人, 80%)。PM 发现「详情页到加购」转化率最低（20%），应该重点优化这一步。 |
| Cohort | Cohort Analysis (同期群分析) | 按照用户的某个共同特征（如注册时间）分组，追踪不同组用户随时间变化的行为表现。详细解释见 01-business-terms.md 的 Cohort 部分。 | 比较「通过朋友邀请注册的用户」和「通过广告注册的用户」的 30 日留存率，发现邀请用户的留存高出 20%。据此决定加大邀请机制的投入。 |
六、术语对比表
有些术语容易混淆，这里做个对比：
| 对比项 | 术语 A | 术语 B | 核心区别 |
|---|---|---|---|
| 目标管理 | OKR | KPI | OKR 侧重方向和挑战（完成 70% 算成功），KPI 侧重考核（要求 100% 达标） |
| 产品文档 | Wireframe | Prototype | Wireframe 是静态的低保真草图，Prototype 是可交互的高保真模拟 |
| 增长模式 | PLG | SLG | PLG 靠产品自身驱动增长（低 CAC），SLG 靠销售团队驱动（高 CAC 高 LTV） |
| 发布策略 | 灰度发布 | A/B Test | 灰度发布是为了降低风险（逐步放量），A/B Test 是为了比较方案优劣（同时对照） |
| 需求描述 | User Story | PRD | User Story 是一句话描述需求（谁想要什么），PRD 是完整的需求文档（详细规则） |
| 产品阶段 | MVP | PMF | MVP 是做出来的最小产品，PMF 是验证出来的市场匹配状态 |
| 需求列表 | Backlog | Roadmap | Backlog 是待做事项的详细列表，Roadmap 是时间维度的规划蓝图 |
七、产品工作流中的术语串联
一个完整的产品迭代流程中，这些术语是这样串联在一起的：
产品规划阶段
┌──────────────────────────────────────────────────────┐
│ 确定 North Star Metric → 制定 OKR → 规划 Roadmap │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 定义 Persona 拆解 KPI 排序 Backlog │
│ │ │ │
│ ▼ ▼ │
│ 绘制用户旅程 编写 User Story │
│ 发现痛点和机会 + Acceptance │
│ Criteria │
└──────────────────────────────────────────────────────┘
│
▼
需求设计阶段
┌──────────────────────────────────────────────────────┐
│ 编写 PRD → 画 Wireframe → 做 Prototype → 需求评审 │
└──────────────────────────────────────────────────────┘
│
▼
开发发布阶段
┌──────────────────────────────────────────────────────┐
│ Sprint 开发 → 灰度发布 (Feature Flag) → A/B Test │
│ │ │
│ ▼ │
│ 漏斗分析 + Cohort │
│ 分析数据验证效果 │
└──────────────────────────────────────────────────────┘
│
▼
复盘迭代阶段
┌──────────────────────────────────────────────────────┐
│ 效果达到 MVP 验证目标？ → 是否达到 PMF？ │
│ │ │ │
│ 是：全量发布 是：加大投入(PLG/SLG) │
│ 否：迭代优化 否：调整方向(Pivot) │
└──────────────────────────────────────────────────────┘常见面试问题
请解释 MVP 的概念，并举一个实际例子。
- 参考上面的「滑板→汽车」模型和外卖 App 例子
OKR 和 KPI 有什么区别？你更倾向用哪个？为什么？
- OKR 适合创新探索（鼓励挑战），KPI 适合执行考核（要求达标）。实际工作中常常结合使用
如何判断一个产品是否达到了 PMF？
- Sean Ellis 测试（40% 用户说「非常失望」）、用户自然增长、留存曲线趋于平稳而非持续下降
什么是 PLG？和 SLG 有什么区别？你负责的产品适合哪种？
- 工具型/协作型产品适合 PLG（Figma、Notion）、复杂企业级产品适合 SLG（SAP、Salesforce）、也可以结合（Slack 底部 PLG + 大客户 SLG）
描述一次完整的 A/B Test 流程。
- 提出假设 → 设计方案 → 确定分流比例和样本量 → 上线实验 → 等待数据积累（通常 1-2 周）→ 分析结果（看统计显著性）→ 决策（采纳/放弃/继续迭代）
小结
| 你想知道... | 看这个术语 |
|---|---|
| 最快速验证想法 | MVP |
| 产品是否满足市场需求 | PMF |
| 怎么组织开发节奏 | Sprint / Iteration |
| 怎么描述需求 | User Story + Acceptance Criteria |
| 怎么管理需求池 | Backlog |
| 怎么规划未来方向 | Roadmap |
| 怎么设定目标 | OKR / KPI |
| 产品最重要的指标是什么 | North Star Metric |
| 怎么降低发布风险 | 灰度发布 + Feature Flag |
| 怎么做数据驱动决策 | A/B Test + 漏斗分析 |
| 怎么分析用户留存趋势 | Cohort |
| 怎么理解用户 | Persona + 用户旅程 |
| 产品文档怎么写 | PRD + Wireframe + Prototype |
| 怎么驱动增长 | PLG / SLG |
下一节： 03-tech-terms.md -- 学习技术术语，理解工程师的世界，让你在技术评审中不再「听天书」。