# Day 17 · 产品执行与数据驱动手册

> **阶段六 · 跨界知识（第二站）**：产品执行与数据驱动（Product Execution & Data-Driven）
> **核心命题**：Day 16 想清楚了"该不该做、为谁做、凭什么赢"，Day 17 解决"怎么做出来、怎么用数据验证、怎么让团队对齐"
> **为什么放在产品战略之后**：战略是"想"，执行是"做"——想得再清楚，做不出来、做错了方向、团队没对齐，都是零

---

## 开篇：从"想"到"做"的鸿沟

Day 16 你已经会回答"这个产品该不该做"了。但商业世界里，**"想清楚"只是 20%，"做对"才是剩下的 80%**。一个好战略死掉，最常见的三个原因都不是"战略错了"，而是执行层出了问题：

```
1. 想法没翻译成需求 —— 团队不知道"到底要做什么"
   → 创始人说"我们要做一个更好的购物体验"，工程师一脸懵：什么叫"更好"？

2. 做出来了没人验证 —— 不知道"做得对不对"
   → 上线了个新功能，到底有没有用？靠直觉？靠老板拍脑袋？

3. 团队没对齐 —— 每个人心里对"什么是成功"的定义都不一样
   → 增长组觉得"日活"最重要，商业化组觉得"收入"最重要，两边打架
```

本手册的四大模块，正好对应这三道鸿沟的解法：

| 鸿沟 | 解法 | 对应模块 |
|------|------|---------|
| 想法没翻译成需求 | PRD 写作 | 模块一 |
| 做出来没人验证 | A/B 测试 | 模块二 |
| 团队没对齐 | 指标金字塔 + OKR | 模块三、四 |

先记住一句话：**产品执行的核心，不是"快"，而是"可验证、可对齐、可复盘"。**

---

## 模块一：PRD 写作——把"想法"翻译成"可执行的需求"

### 1.1 什么是 PRD，为什么产品经理要写

PRD（Product Requirements Document，产品需求文档）是产品经理写给工程师、设计师、测试看的**"施工图纸"**。它回答一个问题：**"我们要做一个什么东西，做完之后怎样才算'做完了、做对了'？"**

```
类比：
  建筑 → 施工图（建筑师画好，工人照着盖）
  软件 → PRD（产品经理写好，工程师照着做）

没有施工图的工地会乱盖；没有 PRD 的开发会乱做。
```

为什么 PRD 重要？因为**"想法"在每个人脑子里长得不一样**。你说"做一个搜索功能"，工程师可能做成"精确匹配"，但你要的是"模糊搜索 + 联想词"。PRD 就是把这些分歧在动手之前摊开来对齐。

### 1.2 PRD 的五个要素（务必背下来，面试直接考）

一份能落地的 PRD，至少包含五个要素：

```
要素 1：背景与目标（Background & Goal）
  → 为什么要做这个功能？要解决什么问题？不做什么？（边界）

要素 2：用户故事（User Story）
  → 用一句话说清"谁、要什么、为什么"

要素 3：功能需求（Functional Requirements）
  → 具体要做哪些功能，拆解到可执行的粒度

要素 4：验收标准（Acceptance Criteria）
  → 做到什么程度算"做完"——可测试、可判断

要素 5：优先级（Priority）
  → 哪些是 Must-have（必须有），哪些是 Nice-to-have（锦上添花）
```

其中**最容易忽略、也最体现功力的是"验收标准"**——它把"感觉做完了"变成"客观判据做完了"。

### 1.3 用户故事的黄金格式

用户故事（User Story）有一个标准模板，来自敏捷开发，务必记住：

```
格式：作为【角色】，我想要【功能】，以便【价值】。
英文：As a [role], I want [feature], so that [value].

例 1：作为"外卖 App 用户"，我想要"一键再来一单"，以便"不用重新选菜、省时间"
例 2：作为"运营人员"，我想要"导出用户活跃数据"，以便"做周报分析"
```

**关键点：** "以便（so that）"后面的**价值**才是灵魂。如果写不出"以便"，说明你还没想清楚这个功能到底为了什么——那就不该做。

### 1.4 好 PRD vs 坏 PRD（面试加分点：能举出反例）

```
坏 PRD（模糊、不可执行）：
  "做一个用户友好的搜索功能，提升搜索体验。"

  为什么坏？——"用户友好"和"提升体验"都是不可判断的形容词。
  工程师不知道做到什么程度算完，测试不知道怎么写用例。

好 PRD（具体、可验收）：
  背景：当前用户搜索"啤酒"返回空结果的场景占 8%，主要因为品牌别名没匹配（如"科罗娜"vs"Corona"）
  用户故事：作为"搜索用户"，我想要"输入品牌别名也能搜到商品"，以便"不用记官方品牌名"
  验收标准：
    ① 输入"科罗娜"，能返回 Corona 相关商品，且命中率 ≥95%
    ② 无结果页出现"试试这些相关词"推荐
    ③ 搜索响应时间 ≤300ms（P95）
  优先级：Must-have
```

**一句话总结 PRD：** PRD 的本质，是把"感觉"翻译成"判据"——让每个读到它的人，对"做什么、做到什么程度算完"有一致的理解。

---

## 模块二：A/B 测试设计——用数据而不是直觉做决策

### 2.1 为什么需要 A/B 测试

产品经理每天都在做"小决策"：按钮放左边还是右边？文案用哪个？新功能上不上？

```
不做 A/B 测试的决策方式（靠直觉/权威）：
  "我觉得红色按钮转化率更高"（直觉）
  "老板说首页要改"（权威）

A/B 测试的决策方式（靠数据）：
  → 随机把用户分成两组：A 组看旧版，B 组看新版
  → 比较两组的核心指标，用统计检验判断"差异是真的还是运气"
```

A/B 测试的本质，就是 **Day 14/15 学的"随机对照实验 + 假设检验"在真实产品里的落地**。它回答的问题非常朴素：**"这个改动，到底有没有带来真实的改善？"**

### 2.2 A/B 测试的五个步骤

```
步骤 1：提出假设（不是"改个按钮试试"，而是"因为X，改Y，预期Z"）
  → 例：因为"结算按钮不够醒目"（X），把按钮从灰色改成红色（Y），预期"点击率提升 10%"（Z）

步骤 2：选核心指标（OEC，Overall Evaluation Criterion）
  → 一个实验只盯一个主指标，避免"什么都看、什么都想要"

步骤 3：算样本量（这一步最容易被跳过，但最关键）
  → 需要多少用户，才能检测出你要的效果？取决于：基线转化率、最小可检测效应（MDE）、显著性水平 α、统计功效 1-β

步骤 4：随机分流（Randomization）
  → 用户被随机、均匀地分到 A/B 两组，保证两组"除了改动，其他都一样"

步骤 5：判断显著性（显著性检验 + 置信区间）
  → p < 0.05 且差异达到业务意义，才算"有效"
```

### 2.3 A/B 测试最常见的三个错误（面试高频，务必能说）

```
错误 1：提前偷看 + 多次检验（Peeking Problem）
  → 实验还没跑完就天天看结果，一看 p<0.05 就提前结束
  → 问题：多次看，相当于多次做检验，假阳性率被放大
  → 解法：跑之前定好样本量和时长，跑完再看

错误 2：把"统计显著"当成"业务显著"
  → 大样本下，1% 的微小提升也能"显著"，但不值得投入
  → 解法：同时看置信区间和"最小可检测效应"，问"这个提升值得做吗"

错误 3：忽略"辛普森悖论"（Simpson's Paradox）
  → 整体看 A 组更好，但分层看（按新老用户/渠道分）每组都是 B 组更好
  → 原因：分组不均衡，隐藏变量在捣乱
  → 解法：实验前分层分流，分析时看关键子群
```

### 2.4 A/B 测试 = 假设检验的落地（连接 Day 14/15）

```
Day 14 学的假设检验：H₀（无差异）vs H₁（有差异），p 值判断
Day 15 学的样本量、置信区间、显著性

A/B 测试就是把这些套在"产品改动"上：
  H₀：新版和旧版没区别（改动无效）
  H₁：新版更好（改动有效）
  p < 0.05 → 拒绝 H₀ → 有证据说"改动有效"

面试金句："A/B 测试不是'看谁的数据好看'，而是'用一个预先声明的判断标准，控制假阳性地确认因果'。"
```

---

## 模块三：指标金字塔——从"北极星指标"到"运营指标"

### 3.1 为什么需要指标体系

一个团队如果"什么都看"，就等于"什么都没看"。当每个人盯着不同的指标，团队就散了：

```
没有指标体系的团队：
  增长组说："我们日活涨了，成功！"
  商业化组说："但收入没涨，失败！"
  留存组说："新用户第二天就流失了，很糟糕！"
  → 三个组各说各话，没人知道"到底做得好不好"

有指标体系的团队：
  先定一个"北极星指标"（团队共同的成功定义），再往下拆
  → 所有人朝同一个方向努力
```

### 3.2 北极星指标（North Star Metric）

北极星指标是**"最能代表产品对用户核心价值的那个指标"**——它一涨，说明产品真的在为用户创造价值；它一跌，说明出了问题。

```
好北极星指标的标准（面试考点）：
  ① 反映用户价值（不是"访问量"，而是"真正用起来了"）
  ② 是先行指标（能提前预警，不是滞后看财报）
  ③ 能拆解、可行动（不是一个大而空的数字）

几个经典例子：
  → 音乐 App（Spotify）：不是"下载量"，而是"每周总收听时长"（用户真的在听）
  → 外卖平台：不是"注册量"，而是"每周成功下单数"
  → 社交产品：不是"安装量"，而是"日活跃用户数（DAU）"或"人均时长"
```

**反面教材：** 把"注册量""下载量"当北极星——这些是"虚荣指标（Vanity Metrics）"，可以靠买量刷上去，但不代表用户真的在用、真的觉得好。

### 3.3 护栏指标（Guardrail Metrics）——不能为了增长牺牲的东西

北极星指标回答"我们要冲什么"，护栏指标回答"**冲的过程中，什么不能跌破**"。

```
例：电商平台想冲"下单量"（北极星），但护栏指标要守住：
  → 退款率不能超过 X%（不能靠"诱导下单"冲量）
  → 客单价不能跌破 Y（不能靠"疯狂打折"冲量）
  → 客服投诉率不能超过 Z（不能牺牲体验冲量）

一句话：北极星告诉你"油门踩多深"，护栏告诉你"刹车在哪里"。
```

### 3.4 指标金字塔的完整结构

```
         ┌───────────────┐
         │  北极星指标     │  ← 1 个：团队共同的成功定义
         ├───────────────┤
         │  护栏指标       │  ← 3-5 个：不能跌破的底线
         ├───────────────┤
         │  运营/执行指标   │  ← N 个：漏斗、留存、转化、成本……
         └───────────────┘
```

从北极星往下拆，每一层都是"上一层的驱动因素"。面试时能画清楚这个金字塔，说明你真正理解了"指标是用来对齐的，不是用来刷的"。

---

## 模块四：OKR vs KPI——目标管理框架

### 4.1 KPI 及其局限

KPI（Key Performance Indicator，关键绩效指标）是"结果性指标"，用来**衡量**做得好不好。

```
例：销售团队的 KPI = 本季度营收 1000 万
问题：KPI 告诉你"目标是什么"，但没告诉你"怎么达到、为什么达不到"。
```

KPI 的三大局限（面试常考）：

```
局限 1：只看结果，不看过程 → 容易"刷分"（为了完成 KPI 而牺牲长期）
局限 2：滞后指标 → 等 KPI 出来，问题已经发生了
局限 3：容易"各自为政" → 每个部门守自己的 KPI，整体却可能不协同
```

### 4.2 OKR 是什么

OKR（Objectives and Key Results，目标与关键结果）是英特尔发明、谷歌发扬光大的目标管理方法。它由两层组成：

```
O（Objective，目标）：
  → 一个鼓舞人心、方向性的目标（定性）
  → 例："让我们的产品成为年轻人最爱的短视频平台"

KR（Key Results，关键结果）：
  → 3-5 个可量化、可验证的关键结果（定量）
  → 例：
    KR1：日活跃用户从 3000 万提升到 5000 万
    KR2：人均日使用时长从 45 分钟提升到 60 分钟
    KR3：7 日留存率从 40% 提升到 55%
```

**OKR 的黄金法则：**
```
① O 要"野心勃勃"，甚至有点"跳一跳才够得着"
② KR 必须可量化、有时限（数字 + 时间）
③ OKR 是"对齐和聚焦"的工具，不是"绩效考核"的工具
④ 一个周期（通常是季度）不要超过 3-5 个 O
```

### 4.3 OKR vs KPI 的本质区别（面试必考，务必能清晰对比）

| 维度 | KPI | OKR |
|------|-----|-----|
| **本质** | 衡量结果的指标 | 对齐方向 + 驱动执行的方法 |
| **回答的问题** | "做得好不好？" | "我们要去哪？怎么知道到了？" |
| **方向性** | 结果（what） | 目标 + 路径（what + how） |
| **类型** | 多为定量 | O 定性 + KR 定量 |
| **用途** | 考核、监控 | 对齐、聚焦、激励 |
| **典型问题** | 容易刷分、滞后 | 如果 O 太保守或 KR 不可量化，就形同虚设 |

**一句话记忆：** KPI 是"仪表盘"（告诉你现在的读数），OKR 是"导航仪"（告诉你目的地和路线）。

### 4.4 OKR 和指标金字塔的连接

```
北极星指标 ≈ OKR 里的 O（团队共同的"成功定义"）
  例：北极星"每周成功下单数" → O"成为用户最信赖的外卖平台"
关键结果 KR ≈ 北极星指标 + 护栏指标的具体拆解
  例：KR1 下单量提升 X，KR2 退款率不超 Y

面试金句："指标体系解决'看什么'，OKR 解决'朝哪冲'——两者是一体两面。"
```

---

## 模块五：产品分析框架——漏斗、留存、激活

### 5.1 AARRR 漏斗（海盗指标）

AARRR 是增长领域最经典的漏斗框架（由 Dave McClure 提出），五个字母代表用户生命周期的五个阶段：

```
A 获取（Acquisition）   —— 用户从哪里来？  （渠道、投放）
A 激活（Activation）    —— 用户有没有"用起来"？  （完成关键动作，如第一单）
R 留存（Retention）     —— 用户用了还会回来吗？  （最硬的产品信号）
R 变现（Revenue）       —— 怎么赚钱？  （付费、广告、佣金）
R 推荐（Referral）      —— 用户愿不愿意拉人？  （口碑、裂变）
```

漏斗的用法：**看每一层的转化率，找出"漏得最厉害"的那一层**，集中优化。面试时，先画漏斗、再定位瓶颈，是标准的分析套路。

### 5.2 留存分析（Retention）

留存是 PMF 的硬信号（Day 16 讲过），这里给具体的分析工具：

```
留存曲线（Retention Curve）：
  → 横轴：时间（第 1 天、第 7 天、第 30 天……）
  → 纵轴：还在用的用户比例
  → 健康的产品，留存曲线会"先陡降、后趋平"（陡降是正常流失，趋平是核心用户沉淀）

关键指标：
  → 次日留存（Day 1 Retention）：产品"第一印象"好不好
  → 7 日留存（Day 7 Retention）：产品有没有"粘住"用户
  → 30 日留存（Day 30 Retention）：产品有没有长期价值
```

### 5.3 激活与 Aha Moment（顿悟时刻）

激活（Activation）是 AARRR 里最容易被忽视、却最关键的一环：**用户要"体验到产品的核心价值"，才算被激活**。

```
Aha Moment（顿悟时刻）：用户第一次真正"get 到"产品价值的那个瞬间。

例：
  → 网盘：用户第一次"上传文件并在另一台设备打开"的瞬间
  → 外卖：用户第一次"下单后 30 分钟收到热饭"的瞬间
  → 短视频：用户第一次"刷到一条停不下来"的瞬间

激活率 = 完成 Aha Moment 的用户 / 新用户
  → 如果激活率低，后面做再多留存、变现都白搭——因为用户根本没"用起来"
```

---

## 模块六：把五块串起来——产品执行与数据驱动的完整闭环

```
一个功能从"想法"到"验证"的完整链条：

① 想法 → PRD（模块一）
  → 把"我想做个更好的体验"翻译成"用户故事 + 验收标准"

② 上线前 → 定指标（模块三、四）
  → 这个功能服务于哪个北极星指标？设什么护栏？OKR 里对应哪个 KR？

③ 上线时 → A/B 测试（模块二）
  → 随机分流，跑实验，用显著性检验判断"改动有没有用"

④ 上线后 → 漏斗/留存复盘（模块五）
  → 看激活、留存、转化，定位下一轮优化点

一句话：PRD 保证"做对的事"，A/B 测试保证"把事做对"，指标金字塔+OKR 保证"全团队朝同一个对的方向"。
```

---

## 模块七：连接你学过的知识

| 概念 | 在哪学的 | 在产品执行中的体现 |
|------|---------|-----------------|
| **假设检验 / p 值** | Day 14 | A/B 测试就是"随机对照 + 假设检验"的落地——p 值判断改动是否有效 |
| **样本量 / 置信区间** | Day 15 | A/B 测试跑之前要算样本量，判断时看置信区间和"最小可检测效应" |
| **相关性 ≠ 因果性** | Day 14 | A/B 测试通过"随机分流"排除混淆变量，是少数能接近"因果"的方法 |
| **产品-市场匹配（PMF）** | Day 16 | 留存率是 PMF 的硬信号——AARRR 的 R（留存）就是它的量化版 |
| **Jobs-to-be-Done** | Day 16 | PRD 的"用户故事"（以便…）本质上就是 JTBD 的"雇佣产品完成的 Job" |
| **单元经济学（CAC/LTV）** | Day 5 | AARRR 的"获取（A）"看 CAC，"变现（R）"看 LTV——漏斗两端对应成本与价值 |
| **毛利率的商业模式含义** | Day 1/6 | 变现层（R）决定商业模式——广告/佣金/订阅对应不同的毛利率结构 |

---

*Day 17 手册 · 产品执行与数据驱动 · 2026-08-15*
*下一篇：Day 18 · 运营管理（精益运营 / 约束理论 TOC / 流程设计 / 质量管理）*