Appearance
B端产品经理工作流程：如何做需求管理
B端产品经理最核心的工作之一就是需求管理。今天介绍需求管理中的六个核心动作，从需求验证到效果跟踪形成完整闭环。
六个关键动作
- 如何保证业务需求的合理性和真实性
- 需求排期如何决策
- 如何管理需求池
- 如何处理需求冲突
- 如何做需求评审
- 如何跟踪需求上线后的效果
一、如何保证业务需求的合理性和真实性
业务方提需求，有时是用户真实痛点，有时是"政治需求"，有时是解法伪装成需求。
验证合理性的三步法
| 步骤 | 方法 | 说明 |
|---|---|---|
| 需求溯源 | 追问场景 | "你在什么场景下遇到了什么问题？现在怎么解决？" |
| 多方交叉验证 | 三个方向 | 用户访谈 + 数据 + 竞品，三者指向同一点才可靠 |
| 价值验证 | ROI评估 | 投入多少人？带来多少收益？与北极星指标挂钩吗？ |
真实性的关键判断
看业务方是否愿意"为这个需求承担结果"。如果需求做完，业务方自己的KPI会受影响，这个需求大概率是真实的；如果业务方对结果没有ownership，就需要额外审视。
二、需求排期如何决策
三层过滤
| 层级 | 问题 | 判断依据 |
|---|---|---|
| 必要性过滤 | 是否解决真实问题？ | 问题严重程度 + 影响范围 |
| 优先级评估 | 投入产出比如何？ | RICE/Kano模型打分 |
| 多方决策 | 谁来做最终拍板？ | 需求评审会共同决策 |
常用优先级模型
RICE模型：
得分 = Reach（影响用户数）× Impact（影响程度）× Confidence（置信度）/ Effort（投入成本）Kano模型：
| 类型 | 说明 | 处理方式 |
|---|---|---|
| 必须有 | 基础需求 | 优先保证 |
| 有了更好 | 期望需求 | 按资源情况安排 |
| 意外惊喜 | 兴奋需求 | 资源充裕再做 |
决策链显式化的好处
- 一条需求是否应该排期有明确规则，不是拍脑袋
- 业务方清楚"为什么我的需求没排进去"，降低解释成本
三、如何管理需求池
需求池是产品团队的"待办仓库"，需要定期清理、评估和归档。
三个核心机制
1. 入口控制
建立简单过滤标准：
- 描述问题场景
- 影响范围
- 期望结果
- 预估工作量
不接受一句话需求。
2. 状态管理
每条需求标注清晰状态：
| 状态 | 说明 |
|---|---|
| 待评估 | 新需求，刚进入池子 |
| 已评估/待排期 | 评估完成，等待排期 |
| 已排期 | 确认开发时间 |
| 开发中 | 正在开发 |
| 已上线 | 需求已完成 |
| 已归档 | 归档保存 |
3. 定期梳理（每两周一次）
| 动作 | 说明 |
|---|---|
| 清理僵尸需求 | 超过3个月没更新且不再被提及的需求，标注后归档 |
| 更新优先级 | 业务发展变化，优先级可能过时 |
| 大需求拆分 | 工作量超过两个版本就需要拆分 |
四、如何处理需求冲突
多个业务方抢同一份研发资源是常见场景。
四步处理方法
| 步骤 | 原则 | 具体做法 |
|---|---|---|
| 1. 标准化 | 把冲突从"人"转移到"规则" | 建立RICE等统一评估标准 |
| 2. 透明化 | 公开优先级决策过程 | 告诉每个业务方评分和排名 |
| 3. 时序化 | 不是"选一个放弃一个" | 而是"先做哪个"，需求都在计划里 |
| 4. 升级机制 | 无法协调时推给更高层 | 带上背景、评估结果和建议 |
透明化的两个好处
- 业务方能理解"为什么我的需求没被排进去"
- 业务方有机会补充信息来影响评估结果
五、如何做需求评审
需求评审是研发启动前最重要的对齐环节。
四步骤
评审前：PRD提前发
评审会是讨论问题的场合，不是"第一次看PRD"的场合。PRD至少提前1-2天发给与会者。
评审中：用场景走读替代功能宣讲
| 错误方式 | 正确方式 |
|---|---|
| 先讲背景，再讲功能列表，再讲边界条件 | 以典型用户为主角，走一遍完整使用流程 |
场景走读能让研发快速建立"用户心智模型"。
重点检查异常流程和边界条件
主流程通常没问题，容易遗漏的是：
- 网络异常怎么处理？
- 用户数据异常怎么办？
- 字段最大长度是多少？
- 并发场景怎么处理？
评审后：整理验收标准
每个功能点对应几条可以验证的标准，开发完成后按验收标准来验收。
六、如何跟踪需求上线后的效果
产品工作流在"需求上线"就结束了？效果跟踪可以把工作从"执行"升级为"学习总结"。
效果跟踪框架
1. 定义"成功标准"
| 错误表述 | 正确表述 |
|---|---|
| "用户体验提升" | "核心链路转化率从35%提升到42%，3个月内达成" |
2. 分阶段收集数据
| 时间点 | 关注内容 |
|---|---|
| 上线后48小时 | 是否有异常（错误率、用户投诉） |
| 上线后一周 | 核心行为指标的变化趋势 |
| 上线后一个月 | 完整效果评估，对比成功标准 |
3. 区分"相关性"和"因果性"
某个指标上涨不一定是这个需求带来的，可能有同期其他功能、运营活动、季节性因素。
好的效果分析会尝试隔离变量：有条件的话用A/B测试，没有的话分析同期其他可能影响因素。
4. 形成上线复盘文档
| 对比项 | 内容 |
|---|---|
| 实际结果 vs 预期结果 | 达到了吗？ |
| 成功/失败原因 | 为什么？ |
| 下次改进方向 | 下次怎么做不同？ |
关键词：B端产品经理, 需求管理, RICE模型, Kano模型, 需求池, 需求评审, 产品经理, 工作流程
