Back to skills
extension
Category: OtherNo API key required

产品经理综合技能(PM Master)

需求分析、PRD编写、产品需求文档、详细设计、BRD、MRD、PRD模板、用户故事、用户访谈、需求挖掘、痛点分析、功能设计、KANO模型、Y模型、5W1H、优先级排序、需求池管理、写过需求、写PRD、做需求分析、产品设计、产品策略、SWOT分析、波特五力、PESTLE、安索夫矩阵、商业模式画布、价值主张、产品愿景、OKR制定、Sprint规划、回顾会、发布说明、干系人管理、竞品分析、市场调研、用户研究、机会解决方案树、指标看板、测试场景、头脑风暴、假设验证

personAuthor: user_dec48685hubcommunity

产品经理综合技能 - PM Master

本技能整合了来自 Dean Peters、Teresa Torres、Marty Cagan 等产品大师的40+种方法论框架, 覆盖从产品战略、需求分析、用户研究、PRD撰写、优先级排序到敏捷执行的全流程。


技能概览

| 阶段 | 核心能力 | 主要工具/框架 | |------|---------|--------------| | 战略层 | 产品策略、商业模式、价值主张 | 产品策略画布、商业模式画布、SWOT、波特五力、PESTLE、安索夫矩阵 | | 研究层 | 用户访谈、需求挖掘、市场调研 | JTBD、5W1H、Y模型、用户故事地图、机会解决方案树 | | 分析层 | 需求分析、竞品分析、优先级评估 | KANO、RICE、ICE、MoSCoW、机会评分、预死亡分析 | | 文档层 | PRD、DDD、用户故事、测试用例 | 8模块PRD模板、DDD结构、INVEST标准 | | 执行层 | Sprint规划、OKR、回顾会、发布 | 敏捷规划、OKR制定、3种回顾格式、干系人地图 | | 数据层 | 指标设计、数据看板、效果追踪 | 北极星指标、AARRR、HEART、漏斗分析 |


一、需求分析方法论

1.1 核心分析方法

KANO模型 - 需求分类

| 需求类型 | 特征 | 策略 | |---------|------|------| | 基础型(必备) | 若没有,用户极度不满 | 必须完成,作为MVP核心 | | 期望型(意愿) | 做得越好,用户越满意 | 优先完成,提升核心竞争力 | | 兴奋型(魅力) | 用户意想不到 | 择机完成,制造产品亮点 | | 无差异型 | 做不做用户都没感觉 | 不做,避免浪费资源 |

Y模型 - 深层挖掘

用户需求 (What) → 目标动机 (Why) → 人性本质 → 产品方案 (How)
     ↑                              ↑                   ↓
     ←──── 验证核心假设 ←───────────────────────────────
  • 用户提出的是解决方案(Y的上端)
  • 需要深挖背后的真实动机(Y的下端)
  • 再重构更优方案

5W1H分析法

  • Who:谁用?(多角色、权限控制)
  • Where:什么环境下用?(移动端/PC、网络环境)
  • When:什么时候用?(高频/低频)
  • Why:为什么要做?(解决什么痛点)
  • What:具体做什么?(功能本体)
  • How:如何实现?(前端交互、后端逻辑)

JTBD需求挖掘(功能/社交/情感三层)

| 需求层级 | 核心问题 | 示例 | |---------|---------|------| | 功能性需求 | 用户要完成什么任务? | 自动化生成报表 | | 社交性需求 | 用户希望别人怎么看他? | 看起来更专业、数据驱动决策 | | 情感性需求 | 用户想避免什么感受? | 不再被老板质问而感到羞愧 |

1.2 伪需求识别

"人们其实不想买一个四分之一英寸的钻头,他们只想要一个四分之一英寸的洞!"

识别伪需求的关键:

  1. 追问"为什么":用户说"想要一匹更快的马",真实需求是"更快的交通工具"
  2. 观察用户行为:不仅听用户说什么,更要看用户怎么做
  3. 验证普遍性:是个别用户的需求还是群体需求
  4. 小范围测试:通过MVP或灰度发布验证

1.3 需求分析输出模板

【需求分析摘要】

**核心业务目标**:...
**用户角色矩阵**:
| 角色 | 核心诉求 | 痛点 |
|------|---------|------|
| ... | ... | ... |

**关键功能域拆解**:
- 功能域A:...
- 功能域B:...

**需求优先级(KANO)**:
- 基础型:...
- 期望型:...
- 兴奋型:...

**待澄清风险/模糊点**:
- ...

二、产品策略框架

2.1 产品策略画布(9模块)

| 模块 | 核心问题 | |------|---------| | 愿景 | 我们如何激励他人?我们渴望实现什么? | | 市场细分 | 第一个目标细分市场是谁?为什么优先选择? | | 相对成本 | 我们是优化低成本还是强调独特价值? | | 价值主张 | 针对每个细分:现状→解决方案→改变后→替代方案 | | 战略取舍 | 我们不做什么? | | 关键指标 | 北极星指标是什么?本季度OMTM是什么? | | 增长 | 销售驱动还是产品驱动?如何规模化? | | 能力 | 需要哪些核心能力?什么自建,什么合作? | | 防御性 | 为什么竞争对手无法复制? |

2.2 SWOT分析

| 维度 | 内容 | |------|------| | 优势(S) | 独特能力、品牌认知、客户关系、技术优势、成本优势 | | 劣势(W) | 资源约束、技术限制、品牌知名度低、高成本结构 | | 机会(O) | 市场增长、技术进步、监管变化、竞品弱点、合作机会 | | 威胁(T) | 新兴竞品、需求变化、技术颠覆、监管风险、经济下行 |

战略应用

  • 进攻(Build):优势 + 机会
  • 防御(Defend):劣势 + 威胁
  • 转型(Pivot):探索改变竞争格局的机会

2.3 波特五力模型

| 五力 | 评估问题 | |------|---------| | 竞争对手 | 竞争有多激烈?对手规模和实力如何? | | 供应商议价能力 | 供应商有多大话语权? | | 买方议价能力 | 客户有多大压价能力? | | 替代品威胁 | 存在哪些替代解决方案? | | 新进入者威胁 | 新竞争对手容易进入吗? |

2.4 PESTLE分析

| 维度 | 评估内容 | |------|---------| | 政治(Political) | 政府政策、税收法规、政治稳定性 | | 经济(Economic) | 经济增长、利率、通胀、消费者信心 | | 社会(Social) | 人口趋势、文化态度、生活方式、教育水平 | | 技术(Technological) | 新兴技术、数字化转型、网络安全 | | 法律(Legal) | 数据保护、劳动法、知识产权 | | 环境(Environmental) | 碳排放、可持续发展、ESG要求 |

2.5 安索夫矩阵

| | 现有市场 | 新市场 | |--|---------|--------| | 现有产品 | 市场渗透(低风险) | 市场开发(中风险) | | 新产品 | 产品开发(中风险) | 多元化(高风险) |

2.6 商业模式画布(BMC)

| 模块 | 内容 | |------|------| | 核心伙伴 | 关键战略合作伙伴和供应商 | | 核心活动 | 关键业务活动 | | 核心资源 | 创造价值所需的核心资源 | | 价值主张 | 为客户交付什么价值? | | 客户关系 | 如何建立和维护客户关系? | | 渠道 | 客户如何发现并获取价值? | | 客户细分 | 核心客户细分是哪些? | | 成本结构 | 最重要的成本是什么? | | 收入来源 | 企业如何赚钱? |

2.7 精益画布

| 模块 | 内容 | |------|------| | 问题 | Top 3 核心问题或需求 | | 解决方案 | Top 3 核心功能 | | 独特价值主张 | 客户选择你的理由 | | 不公平优势 | 防御性竞争优势 | | 客户细分 | 目标客户和早期采用者 | | 渠道 | 主要获客渠道 | | 收入来源 | 定价模型和LTV | | 成本结构 | CAC和核心成本 | | 关键指标 | 核心追踪指标 |


三、用户研究与访谈

3.1 用户访谈脚本设计

开场白(2-3分钟)

  • 介绍自己和访谈目的(学习,不是销售)
  • 设定预期:"没有对错之分,我们只是希望从您的经历中学习。"
  • 征得录音许可(如适用)

破冰阶段(5分钟)

  • "请介绍一下您的工作职责,以及典型的一天是什么样的。"
  • 目标:建立信任,理解受访者背景

核心探索:JTBD(15-20分钟)

当前情境与行为(过去时态):

  • "请带我回顾一下您上次[事情]的经过。"
  • "您用了哪些工具或方法?"
  • "花了多长时间?有哪些人参与?"

痛点与挫败感

  • "那个过程中最难的地方是什么?"
  • "如果有一根魔法棒,您希望改变什么?"

期望产出

  • "对您来说,这个领域'做得好'是什么样子?"

支付意愿

  • "您目前在这上面花了多少时间/金钱?"

追问技巧

  • "能再说详细一点吗?" — 展开任何话题
  • "为什么?" — 深挖根本原因
  • "能举个具体例子吗?" — 从观点转向事实
  • "接下来发生了什么?" — 顺着故事追问

老妈测试原则

  • 询问他们的生活,而非你的想法
  • 询问过去的事,而非未来
  • 少说多听 — 80/20分配
  • 访谈过程中绝不推销
  • 关注强烈情绪 — 它们代表真实痛点

3.2 访谈记录模板

**日期**:[访谈日期]
**参与者**:[姓名和职位]
**背景**:[受访者背景]

**当前解决方案**:[他们目前使用什么]

**满意的地方**:
- [JTBD、期望产出、重要性及满意度]

**不满的地方**:
- [JTBD、期望产出、重要性及满意度]

**核心洞察**:
- [意外发现或值得关注的引用]

**行动项**:
- [日期、负责人、行动内容]

四、PRD文档结构

4.1 完整PRD模板(8大模块)

# [项目名称] 产品需求文档

## 1. 文档概览
| 项目 | 内容 |
|------|------|
| 版本号 | V1.0.0 |
| 状态 | [草稿/评审中/已生效] |
| 创建日期 | YYYY-MM-DD |
| 作者 | [姓名] |
| 审核人 | [姓名] |

## 2. 修订记录
| 版本 | 日期 | 修改人 | 修改内容 |
|------|------|--------|----------|

## 3. 背景与目标
- **业务背景**:为什么要做这个项目?
- **产品目标**(SMART):
  - 具体、可量化、有时限
  - 如:"将注册转化率提升至50%"
- **用户画像**:涉及的角色及核心诉求

## 4. 范围定义
### 4.1 包含范围 (In Scope)
- [明确要实现的功能]

### 4.2 不包含范围 (Out of Scope)
- [明确不做的内容]

### 4.3 MVP边界
- **Must**:必须交付的最小闭环
- **Should**:可做但不影响闭环的增强项
- **Could**:可选加分项

## 5. 价值主张
针对每个目标细分市场:
- **现状(What before)**:客户当前的处境
- **解决方案(How)**:产品如何解决问题
- **改变后(What after)**:改善后的结果
- **替代方案(Alternatives)**:客户今天用什么

## 6. 用户故事
| 角色 | 动作 | 价值 | 验收标准 |
|------|------|------|----------|
| [用户A] | [操作] | [收益] | 1. 界面...<br>2. 数据校验... |

## 7. 详细功能说明
### 7.1 [模块名称]
- **功能描述**:一句话说明
- **前置条件**:需先完成什么
- **主流程**  1. 用户点击...
  2. 系统校验...
  3. 执行动作...
- **异常流程**  - 网络超时:...
  - 无权限:...
- **后置条件**:操作后的系统状态

## 8. 非功能需求
- **性能**:响应时间 ≤ 200ms,支持 1000 QPS
- **安全**:敏感数据加密,防越权
- **兼容**:iOS 14+ / Android 10+
- **可靠**:99.9% 可用性

## 9. 数据埋点
| 埋点位置 | 事件ID | 触发条件 | 上报字段 |
|----------|--------|----------|----------|
| 详情页 | click_buy | 点击购买 | goods_id, price |

## 10. 风险评估
| 风险 | 概率 | 影响 | 缓解措施 |
|------|------|------|----------|
| ... | ... | ... | ... |

4.2 PRD撰写要点

  1. 量化表述:避免"大概""可能""尽量"
    • 错误:"页面加载尽量快"
    • 正确:"3G网络下商品详情页加载时间≤2秒"
  2. 逻辑闭环:每个正向操作都要有逆向逃生通道
  3. 边界穷尽:考虑所有异常情况
  4. 图文并茂:优先使用流程图、UML图

五、详细设计文档(DDD)

# [模块名称] 详细设计说明书

## 1. 设计概述
[用技术语言描述本模块要解决的问题]

## 2. 模块结构与依赖
- **入口层**:Controller / API Endpoint
- **业务逻辑层**:Service 职责划分
- **数据持久层**:DAO/Repository

## 3. 核心逻辑流程图

```mermaid
graph TD
    A[用户请求] --> B{权限校验}
    B -->|通过| C[参数校验]
    B -->|失败| F[返回403]
    C --> D[业务处理]
    D --> E[数据持久化]
    E --> G[返回结果]

4. 接口定义

4.1 [接口名称]

  • 请求方式:POST
  • 请求路径:/api/v1/xxx
  • 请求参数:...
  • 响应参数:...
  • 错误码:...

5. 数据模型

5.1 数据库表设计

| 字段名 | 类型 | 说明 | 约束 | |--------|------|------|------| | id | bigint | 主键 | PK |

5.2 缓存设计

  • 缓存Key:xxx:{id}
  • TTL:3600s
  • 更新策略:Cache Aside

6. 异常处理

| 异常场景 | 处理策略 | |----------|----------| | 网络超时 | 重试3次 | | 服务不可用 | 降级处理 |


---

## 六、用户故事编写

### 6.1 用户故事模板

标题:[功能名称]

描述:作为 [用户角色],我想要 [操作],以便 [收益]。

设计:[设计文件链接]

验收标准:

  1. [清晰、可测试的标准]
  2. [可观察的行为]
  3. [系统正确验证]
  4. [边界情况处理]

### 6.2 INVEST标准

| 标准 | 说明 |
|------|------|
| **I**ndependent | 独立,不依赖其他故事 |
| **N**egotiable | 可协商,非固定规格 |
| **V**aluable | 对用户有价值 |
| **E**stimable | 可估算工作量 |
| **S**mall | 规模适中 |
| **T**estable | 可测试验收 |

### 6.3 用户故事示例

**标题**:最近浏览区域

**描述**:作为在线购物者,我想要在商品详情页看到「最近浏览」区域,以便轻松回顾我曾考虑过的商品。

**验收标准**:
1. 对于浏览过至少1件商品的用户,「最近浏览」区域显示在商品详情页底部
2. 对于本次会话访问第一件商品的用户,该区域不显示
3. 当前商品被排除在展示列表之外
4. 区域显示商品图片、标题和价格
5. 每张卡片标注浏览时间(如"5分钟前")
6. 点击卡片跳转至对应商品详情页

---

## 七、测试场景设计

### 7.1 测试场景模板

测试场景:[场景名称]

测试目标:[验证什么]

初始条件:

  • [系统状态]
  • [所需数据]
  • [用户设置]

测试步骤:

  1. [操作1] → [预期结果1]
  2. [操作2] → [预期结果2]
  3. [操作3] → [预期结果3]

预期结果:

  • [可观察结果1]
  • [可观察结果2]

### 7.2 测试场景示例

**测试场景**:在商品详情页查看最近浏览的商品

**测试目标**:验证「最近浏览」区域正确显示,排除当前商品

**初始条件**:
- 用户已登录
- 用户本次会话浏览过至少2件商品

**测试步骤**:
1. 进入任意商品详情页 → 「最近浏览」区域应出现
2. 滚动至页面底部 → 验证商品卡片显示
3. 检查当前商品 → 不在最近浏览列表中
4. 点击商品卡片 → 跳转至对应详情页

---

## 八、优先级评估框架

### 8.1 框架选择决策树

产品处于什么阶段? ├── 早期/PMF探索期 → ICE(轻量快速) ├── 成长期/有用户数据 → RICE(数据驱动) ├── 功能分类需求 → Kano Model └── 敏捷开发团队 → MoSCoW / Value-Effort矩阵


### 8.2 机会评分(Dan Olsen)

机会评分 = 重要性 × (1 − 满意度)


- 归一化至0-1范围
- 高重要性 + 低满意度 = 最高机会
- 在"重要性 vs 满意度"图上,左上象限是黄金区域

### 8.3 ICE评分法

| 维度 | 说明 | 计算 |
|------|------|------|
| **I**mpact | 影响力 | 机会评分 × 客户数量 |
| **C**onfidence | 置信度 | 我们有多确定?(1-10) |
| **E**ase | 简易度 | 实施难度 (1-10) |

**ICE得分 = I × C × E**

### 8.4 RICE评分法

| 维度 | 说明 |
|------|------|
| **R**each | 触达范围(受影响用户数) |
| **I**mpact | 影响力 |
| **C**onfidence | 置信度 (0-100%) |
| **E**ffort | 工作量(人月) |

**RICE得分 = (R × I × C) / E**

### 8.5 MoSCoW法则

| 类别 | 含义 | 比例 |
|------|------|------|
| **Must** | 必须有 | 60% |
| **Should** | 应该有 | 20% |
| **Could** | 可以有 | 15% |
| **Won't** | 本次不做 | 5% |

### 8.6 9大框架对比

| 框架 | 适用场景 | 核心特点 |
|------|---------|---------|
| 艾森豪威尔矩阵 | 个人任务 | 紧急 vs 重要 |
| 影响力 vs 工作量 | 快速分类 | 2×2矩阵 |
| 风险 vs 回报 | 计划评估 | 考虑不确定性 |
| **机会评分** | 客户问题 | **推荐** |
| Kano模型 | 理解期望 | 需求分类 |
| 加权决策矩阵 | 多因素决策 | 标准赋权 |
| **ICE** | 快速排序 | **推荐** |
| **RICE** | 规模化分析 | 增加触达范围 |
| MoSCoW | 需求范围 | 敏捷友好 |

---

## 九、风险识别与分析

### 9.1 预死亡分析(Pre-Mortem)

> 被研究证明能提升30%问题发现率

#### 三类风险分类

| 类型 | 定义 | 处理 |
|------|------|------|
| **老虎(Tigers)** | 真实问题,可能让项目脱轨 | 必须采取行动 |
| **纸老虎(Paper Tigers)** | 被夸大的担忧 | 记录以对齐干系人 |
| **大象(Elephants)** | 未被说出的隐忧 | 值得深入调查 |

#### 紧迫程度分级

| 级别 | 含义 | 示例 |
|------|------|------|
| **发布阻断** | 发布前必须解决 | 核心功能损坏 |
| **快速跟进** | 发布后30天内解决 | 性能问题 |
| **持续跟踪** | 监控,必要时解决 | 边界情况 |

### 9.2 假设验证四维度

| 维度 | 问题 |
|------|------|
| **价值(Value)** | 能为客户创造价值吗? |
| **可用性(Usability)** | 用户能弄清楚如何使用吗? |
| **商业可行性(Viability)** | 市场、销售、财务能支持吗? |
| **技术可行性(Feasibility)** | 能用现有技术构建吗? |

---

## 十、产品探索工具

### 10.1 机会解决方案树(OST)

                ┌─────────────┐
                │ 期望产出    │
                │(北极星指标)│
                └──────┬──────┘
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
     ┌────────┐   ┌────────┐   ┌────────┐
     │ 机会1  │   │ 机会2  │   │ 机会3  │
     │(痛点)  │   │(痛点)  │   │(痛点)  │
     └───┬────┘   └────────┘   └────────┘
         │
┌────────┼────────┐
▼        ▼        ▼

┌──────┐ ┌──────┐ ┌──────┐ │方案1 │ │方案2 │ │方案3 │ └──┬───┘ └──────┘ └──────┘ │ ▼ ┌────────┐ │ 实验 │ └────────┘


**核心原则**:
- 一次聚焦一个产出
- 机会,不是功能
- 比较与对比(每个机会3+方案)
- 探索不是线性的

### 10.2 产品铁三角

> 产品经理 + 设计师 + 工程师共同参与探索

- "最好的创意往往来自工程师"
- 每周更新OST
- 实验失败时循环回来

---

## 十一、OKR与目标管理

### 11.1 OKR模板

目标:让新用户享受轻松愉快的引导体验

关键成果:

  • KR1:引导调研CSAT评分 >= 75%
  • KR2:66%以上的用户在两天内完成引导
  • KR3:平均首次价值实现时间(TTV) <= 20分钟

### 11.2 OKR vs KPI vs 北极星指标

| 概念 | 说明 |
|------|------|
| **OKR** | 鼓舞人心的目标 + 可衡量的关键成果 |
| **KPI** | 长期跟踪的核心量化指标 |
| **北极星指标** | 单一、以客户为中心、成功领先指标 |

**关系**:关键成果可以是KPI;OKR的KR可以表达北极星指标的变化

---

## 十二、Sprint规划与管理

### 12.1 Sprint规划流程

  1. 估算团队容量

    • 成员数量 × 可用时间
    • 历史速率(3个Sprint平均)
    • 预留15-20%缓冲
  2. 评审并选取故事

    • 从优先级列表取用
    • 验证"就绪定义"
    • 达到容量上限停止
  3. 映射依赖关系

    • 识别外部依赖
    • 合理排序
    • 标注关键路径
  4. 创建Sprint计划


### 12.2 Sprint计划模板

Sprint目标:[一句话描述成功的样子] 时长:[2周] 团队容量:[X故事点] 已承诺:[Y故事点] 缓冲:[剩余容量]

故事列表:

  1. [故事] — [故事点] — [负责人] — [依赖项] ...

风险:

  • [风险] → [缓解措施]

### 12.3 Sprint回顾格式

#### 格式A — Start/Stop/Continue
- **开始**:我们应该开始做什么?
- **停止**:我们应该停止做什么?
- **继续**:哪些做得好,应该保持?

#### 格式B — 4Ls
- **Liked**:团队喜欢什么?
- **Learned**:获得了哪些新知识?
- **Lacked**:缺少了什么?
- **Longed For**:希望拥有什么?

#### 格式C — 帆船模型
- **风(推进力)**:什么在驱动我们前进?
- **锚(阻力)**:什么在拖慢我们?
- **礁石(风险)**:前方有哪些危险?
- **岛屿(目标)**:我们想要到达哪里?

---

## 十三、干系人管理

### 13.1 权力×利益方格

| | 高关注度 | 低关注度 |
|--|---------|---------|
| **高权力** | **重点管理**<br>定期一对一<br>参与决策 | **保持满意**<br>定期更新<br>仅上报关键问题 |
| **低权力** | **及时告知**<br>定期状态更新<br>收集反馈 | **持续监控**<br>轻量级更新<br>按需响应 |

### 13.2 沟通计划模板

| 干系人 | 角色 | 权力 | 关注度 | 策略 | 频率 | 渠道 |
|--------|------|------|--------|------|------|------|
| ... | ... | ... | ... | ... | ... | ... |

---

## 十四、数据指标体系

### 14.1 北极星指标框架

北极星指标(North Star) ├── 输入指标(3-5个) │ ├── 输入指标1 │ └── 输入指标2 ├── 健康指标 │ ├── 延迟 │ ├── 错误率 │ └── NPS └── 业务指标 ├── MRR ├── CAC ├── LTV └── 流失率


### 14.2 好指标的4个标准

1. **易理解** — 形成共同语言
2. **可比较** — 随时间变化
3. **是比率** — 比绝对数字更具洞察力
4. **能改变行为** — "如果一个指标不会改变你的行为,它就是一个糟糕的指标"

### 14.3 AARRR海盗指标

| 阶段 | 指标 | 说明 |
|------|------|------|
| **A**cquisition | 获取 | 用户如何发现你? |
| **A**ctivation | 激活 | 用户第一次体验好吗? |
| **R**etention | 留存 | 用户会回来吗? |
| **R**eferral | 推荐 | 用户会推荐别人吗? |
| **R**evenue | 收入 | 你如何盈利? |

### 14.4 指标看板定义模板

| 指标 | 定义 | 数据来源 | 可视化 | 目标值 | 告警阈值 |
|------|------|----------|--------|--------|----------|
| [名称] | [精确计算] | [出处] | [类型] | [目标] | [条件] |

---

## 十五、定价策略

### 15.1 定价模型选择

| 模型 | 最适合 | 示例 |
|------|--------|------|
| 统一费率 | 简单产品 | Basecamp |
| 按席位 | 协作工具 | Slack、Figma |
| 按用量 | 基础设施、API | AWS、Twilio |
| 分级定价 | 有明显细分 | 多数SaaS |
| 免费增值 | 有网络效应 | Spotify、Notion |
| 价值定价 | 高影响力企业 | Salesforce |

### 15.2 分层定价设计

| 套餐 | 价格 | 目标细分 | 核心功能 | |------|------|----------|----------| | 免费 | ¥0 | 试用用户 | 基础功能 | | 专业 | ¥99/月 | 个人用户 | 高级功能 | | 企业 | ¥299/月 | 团队用户 | 全部功能 |


**锚定定价**:让最受欢迎的套餐看起来是显而易见的最优选择

---

## 十六、发布说明

### 16.1 发布说明模板

```markdown
# [产品名称] — [版本 / 日期]

## 新功能
- **[功能名称]**:[1-2句话描述及重要性]

## 改进
- **[改进方向]**:[什么变得更好了]

## 缺陷修复
- 修复了 [用户语言描述的问题]

## 破坏性变更(如有)
- **需要操作**:[用户需要做什么]

16.2 撰写原则

  • 以用户收益为先,而非技术变更
  • 使用通俗语言,避免行话
  • 每个条目1-3句话
  • 技术描述 → 用户版本示例:
    • "实现Redis缓存层" → "仪表板加载速度提升最高3倍"

十七、会议与文档管理

17.1 会议摘要模板

## 会议摘要

**日期与时间**:[日期和时间]
**参与者**:[姓名和角色]
**主题**:[简短标题]

**摘要**
- **要点1**:[关键讨论]
- **要点2**:[关键讨论]

**行动项**
| 截止日期 | 负责人 | 行动内容 |
|---------|-------|---------|
| [日期] | [姓名] | [内容] |

**已做决策**
- [决策1]
- [决策2]

**待解问题**
- [问题1]

十八、一页纸速查模板

一页纸PRD

【Goal】______(可量化的核心目标)
【Why】______(用户痛点+业务价值)
【Scope】
- Must:______
- Should:______
- Not now:______
【User Story】
- As a [角色], I want [功能], so that [价值]
【Key Flow】
______(核心流程,3-5步)
【Acceptance Criteria】
1. ______
2. ______
3. ______
【Metrics】
- 业务指标:______
- 技术指标:______
【Risks】
- ______:应对措施______

十九、常见错误与避坑

| 错误 | 正确做法 | |------|----------| | 需求背景模糊 | 背景要讲清:用户痛点+业务影响 | | 功能描述模糊 | 描述要量化:用数字代替形容词 | | 只写正常情况 | 边界要穷尽:考虑所有异常场景 | | 验收标准不量化 | 验收要可测试:明确具体指标 | | 原型与描述不一致 | 逻辑要一致:文字、流程图、原型图统一 | | 忘记逆向流程 | 流程要完整:每个正向操作都有逆向通道 | | 版本控制混乱 | 变更要记录:所有修改都有书面记录 | | 以产出为导向 | 以成果为导向:聚焦客户和业务影响 |


二十、与其他技能的关系

  • investigation-first:用于调查阶段,占有第一手材料
  • practice-cognition:用于验证阶段,检验假设和方案
  • contradiction-analysis:用于识别需求中的核心矛盾
  • overall-planning:用于多需求并行时的整体规划
  • mass-line:用于收集多方意见,整合成可执行方案

延伸阅读资源

  • 《Inspired》— Marty Cagan
  • 《Continuous Discovery Habits》— Teresa Torres
  • 《The Lean Product Playbook》— Dan Olsen
  • 《Jobs to be Done》— Anthony Ulwick
  • 《创新者的窘境》— Clayton Christensen
  • 《Radical Focus》— Christina Wodtke(OKR)
  • 《商业模式新生代》— Alexander Osterwalder

踩坑经验

(以下由AI在实际调用中自动积累)