2. 产品需求与用户需求的关系：区分、转化、优先级
产品需求文档（PRD）的本质是一份翻译手册——将用户模糊的诉求转译成工程团队可执行的技术规格。但在实际工作中，许多人直接把用户原话写进 PRD，导致开发反复返工、验收标准模糊、产品上线后用户仍不满意。本章从 区分、转化、优先级 三个动作拆解用户需求与产品需求的关系，帮你建立需求处理的第一性原理。
2.1 用户需求 vs 产品需求：核心区分
用户需求是发生在特定场景下的问题陈述，自带情绪、假设和模糊性；产品需求是经过结构化拆解后的解决方案描述，必须具备可测量、可验证的属性。二者在属性、主语、粒度、验证方式上存在根本差异：
| 对比维度 | 用户需求 | 产品需求 |
|---|---|---|
| 表达形态 | 主观、口语化、含情绪词（“太慢了”“真麻烦”） | 客观、结构化、含量化指标（“页面加载 ≤ 1.5 s”） |
| 主语归属 | 以用户为主语（“我想”“我需要”“我找不到”） | 以系统/功能为主语（“搜索框支持模糊匹配”“列表提供分页”） |
| 粒度层级 | 场景级或任务级（“出差时能快速找到最近的加油站”） | 功能级或子功能级（“地图模块增加 '附近加油站' 图层”） |
| 验证方式 | 满意度、NPS、主观反馈 | 通过/不通过、响应时间、错误率、转化率 |
| 变更成本 | 低（用户想法可以随时变） | 高（进入开发后修改需走变更流程） |
区分实操建议： 在用户访谈记录中用两种颜色高亮——黄色标记用户原话（需求来源），蓝色标记你翻译后的产品需求（PRD 条目）。如果 PRD 里还有黄色内容，说明转化未完成。
2.2 从用户需求到产品需求的转化路径
转化不是“把用户的话换个说法”，而是经过四层加工，逐步去除主观性、补全上下文、量化验收标准。每一层对应一个具体的动作：
- 场景还原 —— 把用户的一句话放回真实场景：谁、在什么时间、什么环境下、为了完成什么任务、遇到了什么障碍。
- 问题提炼 —— 从场景中抽象出本质问题，去掉用户自带的解决方案倾向，只保留“痛点 + 期望结果”。
- 方案设计 —— 基于问题定义，产出至少 2 个可选解决方案，并标注每个方案的代价、风险和用户感知变化。
- 指标锚定 —— 为选定的方案设定可量化的验收指标，明确“做到什么程度算成功”。
转化检查清单： 每转化一条需求，自问三个问题——① 删掉用户原话后，工程师能看懂吗？② 换一个工程师来做，理解会一致吗？③ 测试看到这条需求，能写出测试用例吗？
2.3 需求优先级的三层过滤模型
一条用户需求转化为产品需求后，不能直接进入开发排期。你需要用三层过滤器评估它是否值得做、什么时候做。下面这张图展示了一个完整的优先级过滤流程：
三层过滤模型的核心价值在于将优先级决策从“凭感觉排”变成“按标准筛”。第一层过滤确保需求与产品战略方向一致；第二层用 ROI 思维判断投入产出比；第三层评估技术可行性与风险敞口。只有三层都通过的需求，才进入正式的 PRD 撰写阶段。
常见误区： 很多产品经理直接跳过第一层和第二层，拿着用户需求就去问技术“能不能做”，结果是做出来之后发现用户根本不买账，或者与产品定位冲突。记住：技术可行性是最后一个过滤器，不是第一个。
2.4 实战案例：从用户抱怨到 PRD 条目
下面通过一个真实场景演示“区分 → 转化 → 优先级”的完整链路。假设你负责一款企业云盘产品，收到多条用户反馈：
用户原话：“每次找文件都要翻半天，文件夹套文件夹，太烦了！能不能像百度网盘那样有个搜索框？”
第一步：区分 —— 用户的真实诉求不是“加搜索框”，而是“快速找到目标文件”。加搜索框只是用户自带的解决方案假设。
第二步：转化 —— 拆解为三条产品需求：
- PRD-01： 全局搜索入口支持文件名模糊匹配，搜索响应时间 ≤ 1.0 s（P0）
- PRD-02： 搜索结果按“最近修改时间”降序排列，支持按文件类型筛选（P1）
- PRD-03： 在文件夹浏览模式下增加“当前路径面包屑导航”，方便定位层级（P2）
第三步：优先级过滤 —— 将三条需求放入三层过滤模型：
| 需求条目 | 战略匹配 | 价值 / 成本 | 技术可行 | 优先级结论 |
|---|---|---|---|---|
| PRD-01 全局搜索 | ✅ 对齐“提升文件管理效率”战略 | ✅ 高价值（覆盖 80% 用户痛点），中成本（已有搜索引擎基础） | ✅ 可行，需接入索引服务 | P0 · 立即进入迭代 |
| PRD-02 搜索筛选 | ✅ 同一战略方向 | ✅ 中价值，低成本（UI 层拓展） | ✅ 技术风险低 | P1 · 与 P0 同版本 |
| PRD-03 面包屑导航 | ✅ 方向一致 | ⚠️ 低价值（仅帮助已有层级认知的用户），低成本 | ✅ 前端组件改造 | P2 · 后续版本优化 |
经过三层过滤，原本用户一句简单的“加个搜索框”，变成了一个包含优先级、指标、排期的需求组合。PRD-01 和 PRD-02 进入当前版本开发，PRD-03 放入需求池等待后续排期。
交付物提示： 建议在 PRD 的“需求背景”章节附上用户原话（表明需求来源），在“需求详述”章节只写转化后的产品需求条目。这样评审时，参会者既能理解上下文，又能聚焦于可执行的技术方案。