产品经理的核心工作流与 PRD 写法
产品经理的核心工作流与 PRD 写法
背景
很多人刚接触产品经理时，会先听到一个词：PRD。
但 PRD 只是产品经理的一种产出，不是产品经理工作的全部。真正重要的是，产品经理要把一个模糊问题变成团队可以执行、可以验证、可以复盘的产品动作。
一句话概括：
找到值得解决的问题，定义清楚要做什么，推动团队做出来，并验证它是否真的产生价值。1、产品经理的核心工作流
产品经理的工作流可以拆成六个阶段：发现问题、定义目标、设计方案、写需求、推动交付、上线复盘。
这六个阶段不是一次性流程，而是一个持续循环。上线后的数据和反馈，会重新进入下一轮问题发现。
| 阶段 | PM 要做什么 | 主要产出 |
|---|---|---|
| 发现问题 | 看数据、访谈用户、收集反馈、研究竞品 | 用户问题、机会点、调研结论 |
| 定义目标 | 判断为什么要做、给谁做、做到什么算成功 | 目标、成功指标、优先级 |
| 设计方案 | 拆场景、画流程、确定功能范围 | 方案草图、用户流程、功能清单 |
| 写需求 | 把共识沉淀成研发、设计、测试能执行的文档 | PRD、埋点需求、验收标准 |
| 推动交付 | 协调设计、研发、测试、运营，处理变更和取舍 | 任务拆分、排期、评审记录、上线计划 |
| 上线复盘 | 看数据、收反馈、判断是否继续迭代 | 数据复盘、问题清单、下一版计划 |
2、产品经理的主要产出
产品经理的产出不只有 PRD。PRD 更像是其中一个关键节点：当问题、目标和方案已经基本明确后，用来让团队形成执行共识。
常见产出包括：
| 产出 | 作用 |
|---|---|
| 用户调研记录 | 记录用户是谁、遇到什么问题、真实行为是什么 |
| 竞品分析 | 理解市场上类似问题如何被解决 |
| 用户画像 / 使用场景 | 明确目标用户和典型使用情境 |
| 需求池 | 收集、归类和管理待处理需求 |
| 优先级排序 | 判断哪些需求先做、哪些暂缓 |
| Roadmap | 描述一段时间内的产品演进方向 |
| PRD | 描述需求背景、目标、功能规则和验收标准 |
| 原型图 / 流程图 | 帮团队理解页面、路径和状态变化 |
| 埋点方案 | 定义上线后如何衡量用户行为和业务结果 |
| 测试验收标准 | 明确做到什么程度算完成 |
| 上线公告 / 运营文案 | 帮用户和内部团队理解新功能 |
| 数据复盘报告 | 判断功能是否达成目标，并决定下一步 |
3、PRD 是什么
PRD，全称是 Product Requirements Document，通常翻译为产品需求文档。
它的核心作用不是把页面描述得很长，而是把团队最容易误解的内容写清楚：为什么做、做什么、不做什么、规则是什么、边界在哪里、怎么验收。
一个好的 PRD 应该让设计、研发、测试、运营看完后，都知道自己该做什么，也知道做到什么算完成。
4、PRD 的推荐结构
下面是一份适合大多数功能需求的 PRD 结构。
# PRD：功能名称
## 1. 基本信息
- 产品 / 模块：- 负责人：- 版本：- 状态：草稿 / 评审中 / 已确认 / 已上线- 更新时间：
## 2. 背景
为什么要做这个需求？
当前有什么问题？
用户或业务遇到了什么痛点？
## 3. 目标
这个需求要解决什么问题？
上线后希望达成什么结果？
## 4. 成功指标
如何判断这个需求做得好？
例如：
- 转化率提升- 留存率提升- 使用次数增加- 投诉率下降- 人工处理成本下降
## 5. 用户与场景
目标用户是谁？
他们在什么情况下会使用这个功能？
典型使用流程是什么？
## 6. 需求范围
本期做什么？
本期不做什么？
## 7. 功能说明
逐条写清楚功能规则。
### 7.1 功能点 A
- 用户可以做什么- 页面展示什么- 点击后发生什么- 异常情况怎么处理- 权限规则是什么
### 7.2 功能点 B
继续描述其他功能点。
## 8. 用户流程
放流程图、状态图或页面跳转说明。
## 9. 页面与交互说明
每个页面建议包含：
- 页面入口- 页面元素- 按钮行为- 表单规则- 空状态- 错误状态- 加载状态
## 10. 数据与埋点
需要记录哪些用户行为？
例如：
- 页面曝光- 按钮点击- 提交成功- 提交失败- 转化完成
## 11. 验收标准
研发完成后，怎么判断它符合需求？
建议使用“给定-当-那么”的方式。
例如：
给定用户未登录，当用户点击“提交订单”，那么系统应跳转到登录页。
## 12. 依赖与风险
依赖哪些系统、团队或资源？
有哪些可能影响上线的风险？
## 13. 上线计划
- 灰度范围- 上线时间- 回滚方案- 运营配合- 客服说明
## 14. 未决问题
还有哪些问题没确定？
谁负责确认？
什么时候确认？5、写 PRD 时最重要的判断
PRD 不追求长，而追求可执行。
写 PRD 时，可以用几个问题检查质量：
| 检查问题 | 判断标准 |
|---|---|
| 为什么做清楚了吗 | 能说出用户问题或业务问题 |
| 目标清楚了吗 | 能说明上线后希望改变什么 |
| 范围清楚了吗 | 能区分本期做什么和不做什么 |
| 规则清楚了吗 | 研发能按规则实现，不需要反复猜 |
| 状态清楚了吗 | 正常、异常、空状态、加载状态都有说明 |
| 验收清楚了吗 | 测试能判断通过或不通过 |
| 数据清楚了吗 | 上线后能验证是否有效 |
如果 PRD 写完后，团队仍然大量追问“这个地方到底怎么算”“失败怎么办”“谁能看到这个按钮”，说明需求规则还没有写清楚。
6、常见误区
第一个误区，是把 PRD 写成页面说明书。
页面很重要，但产品需求不只是页面。真正容易出问题的是业务规则、权限、异常状态、数据口径和边界条件。
第二个误区，是一开始就写功能。
如果没有先写清楚背景、目标和成功指标，功能列表会变成“我想做什么”，而不是“为了解决什么问题应该做什么”。
第三个误区，是替研发写技术实现。
产品经理应该写清楚业务逻辑和用户体验，不应该越界规定具体技术方案。技术方案需要和研发一起讨论。
第四个误区，是不写“不做什么”。
不写范围边界，需求很容易在评审和开发过程中不断膨胀。本期不做什么，和本期做什么一样重要。
总结
产品经理的核心工作流不是写 PRD，而是从问题到结果的闭环管理。
PRD 是这个闭环中的关键交付物。它把背景、目标、范围、规则、流程、数据和验收标准写清楚，让团队能够稳定地把需求做出来。
好的 PRD 不一定很长，但一定具体、可验证、边界清晰。
Comments
留下评论