4. 需求收集渠道与优先级
需求的来源分散而嘈杂，产品经理的日常工作之一就是持续从多个渠道捕获信息，并判断哪些值得写入 PRD、哪些应暂缓或拒绝。若不加筛选地全盘接收，PRD 会变成“愿望清单”；若过度依赖单一渠道，则可能忽略关键的真实用户痛点。本章围绕五种最常见的需求输入通道，逐一拆解其特点、适用场景和优先级评估方法，并给出可复用的权衡框架。
业务问题示例：一款在线协作工具同时收到 30 条 Bug 反馈、用户群中 5 人要求增加“暗色模式”、数据分析显示“文件上传耗时”下降但转化率未变、老板提出“接入企业微信 SSO”的季度目标，以及技术团队指出“登录模块代码耦合严重”需要重构。如何在一周内产出下一迭代的 PRD？此时需要系统化的收集与权衡手段。
4.1 五个核心渠道
| 渠道 | 来源 | 典型表现 | 业务价值特征 |
|---|---|---|---|
| Bug 反馈 | 用户投诉、工单系统、QA 测试 | 功能报错、数据丢失、流程中断 | 直接修复优先级高，但需区分偶发性与批量性 |
| 用户群 | 微信群、论坛、用户访谈、NPS 调研 | “能不能加一个导出功能？”“XX 竞品有这个” | 用户声量≠真实需求，需验证行为数据 |
| 数据分析 | 埋点报表、漏斗分析、A/B 测试 | “注册转化率在步骤 3 骤降 40%” | 基于行为洞察，可量化 ROI，但需排除噪音 |
| 老板需求 | 高层会议、OKR 对齐、战略方向 | “下季度必须支持多语言版本” | 通常与公司目标绑定，资源优先但需验证可行性 |
| 技术债 | 工程师提案、架构审查、代码复杂度报告 | “每次迭代 20% 时间花在屎山上改 bug” | 长期效率提升，但短期无直接用户收益 |
收集方法提示：建立统一的“需求收集表”（Google Sheets / JIRA 看板），每条需求记录来源、描述、提交人、紧急程度、影响用户数。每周定期 triage，避免口头需求被遗忘。
4.2 优先级权衡框架
不同渠道的需求难以直接比较，需要一套多维度评估体系。以下框架整合了 影响范围（Reach）、业务价值（Impact）、开发成本（Effort）、风险（Risk） 和 战略一致性（Alignment） 五个维度，每个维度按 1–5 分打分，最终得分 = (Reach × Impact) ÷ (Effort × Risk) × Alignment。该公式来自 RICE 模型变体，适用于大多数产品团队。
- 影响范围（Reach）：涉及多少用户或交易？用百分比或绝对数估算。
- 业务价值（Impact）：对留存、转化、收入、满意度等核心指标的提升程度。
- 开发成本（Effort）：包括设计、开发、测试、部署的人天。
- 风险（Risk）：上线后可能带来的负面效果或技术不确定性。
- 战略一致性（Alignment）：是否匹配当前季度 OKR。
使用该框架时，技术债 类需求往往 Effort 高、Reach 低，但可通过“若不重构，未来 Effort 指数级增长”的折现值来调整 Impact 分数。老板需求通常 Alignment=5，但需用用户访谈或数据验证其真伪。
4.3 渠道权衡实战 —— 一个星期的 triage 示例
回到开头的业务问题。某在线协作工具团队使用上述框架对 30 条 Bug、5 个用户群需求、数据分析异常、老板 SSO 需求、技术债进行了评分。结果如下（部分截取）：
| 需求条目 | 渠道 | Reach | Impact | Effort | Risk | Alignment | 得分 | 优先级 |
|---|---|---|---|---|---|---|---|---|
| 文件上传失败（批量 Bug） | Bug 反馈 | 5 | 5 | 3 | 2 | 4 | 25.0 | P0 |
| 登录模块重构 | 技术债 | 2 | 4 | 5 | 1 | 3 | 4.8 | P2 |
| 暗色模式 | 用户群 | 3 | 2 | 4 | 1 | 2 | 3.0 | P3 |
| 企业微信 SSO | 老板需求 | 4 | 3 | 5 | 3 | 5 | 4.0 | P1 |
| 注册转化率优化 | 数据分析 | 5 | 4 | 2 | 2 | 4 | 20.0 | P0 |
注意：得分并非唯一标准。当两大 P0 依赖同一开发资源时，需进一步拆解 MVP 阶段，或与相关方协商调整。本示例中“文件上传失败”和“注册转化率优化”均为 P0，但前者紧急度更高，故放到迭代首周修复 Bug，次周做转化优化。
4.4 交付物：需求收集与评估模板
每个渠道在 PRD 前应有对应记录。以下是常用交付物模板的列表，可根据团队情况裁剪：
- Bug 反馈单：日期、版本号、重现步骤、影响用户占比、优先级（P0–P3）。
- 用户群需求记录：原始引用、用户画像、提出场景、竞品对标（如有）、语音/访谈附件。
- 数据分析报告：图表、基线指标、对比组、统计显著性（如 p 值）。
- 老板需求沟通纪要：目标对齐文档、预期 ROI 测算、技术可行性评估。
- 技术债评估卡片：当前坏味道描述、修改范围、预估人天、不修改后果。
所有模板最终汇总到一张 PRD 需求源追溯表，包含需求 ID、渠道、原始链接、评估分、决策状态（采纳/暂缓/拒绝）。这份表格是 PRD 评审时的有力支撑，也是产品经理对利益相关方的透明回应。
验收标准提示：在 PRD 完成时，应能回溯每条已纳入需求的上游渠道及评估记录。若被问到“为什么不做这个？”，你可以展示评估表并根据得分解释原因。这种透明机制能减少事后争议，提升团队信任。