需求价值数据不足时，取舍依然可以做，前提是把判断依据整理成可追溯的证据。本文围绕“缺哪类证据、由谁补、何时验证”三个问题，给出证据分类、留存步骤、角色分工、演示示例和完成检查清单，帮助团队在数据补齐前做出有据可查的取舍决定，并在后续回看修正。
要点总览（TL;DR）
- 数据不足时先拆价值问题：用户价值、业务收益、合规风险、成本节约，每类对应不同的证据来源和最低证据要求。
- 证据留存按四步走：建条目、分事实与判断、写假设验证计划、评审前汇总评审后归档，每条证据可追溯到原始材料。
- 收集、判断、归档分到需求提出人、产品经理、业务对接人、评审参与者和归档责任人，避免证据整理变成单人负担。
- 评审时按统一口径比较证据强弱，结论对应到具体证据条目，保留意见署名，后续数据补齐后可回看修正。
- 证据不足仍推进的需求，记录中写明推进理由和风险承担人；需求量大时可先用只含来源、可信度、验证期限的简化清单。
数据不足时，需求取舍先回答哪几个问题
面对一条缺少数据的需求，先不要急着讨论“做不做”，而要把它拆成可回答的价值问题。数据不足通常意味着量化指标缺失，但需求要解决什么问题、影响谁、不做的后果是什么，这些信息往往可以通过定性材料获得。把价值问题分类，是为了明确需要哪类证据，避免收集一堆与取舍无关的材料。
常见需求价值问题可分为四类：用户价值，即解决哪些用户的具体困难；业务收益，即对收入、转化、留存等目标的预期贡献；合规或风险规避，即不满足会带来什么后果；成本节约，即能减少多少人工、返工或资源消耗。每类问题对应的证据来源不同，最低证据要求也不同。
| 价值问题类型 | 可获取的证据类型 | 最低证据要求 |
|---|---|---|
| 用户价值 | 用户原话、访谈记录、工单与投诉、客服反馈、可用性观察 | 至少一条来自目标用户的直接反馈，注明时间与场景 |
| 业务收益 | 销售反馈、客户会议记录、合同或商机备注、竞品观察 | 至少一条来自业务侧的具体诉求，说明关联客户或场景 |
| 合规或风险规避 | 法规条款、审计发现、事故记录、法务或安全意见 | 明确的风险描述与触发条件，注明依据来源 |
| 成本节约 | 工时估算、返工记录、流程耗时统计、供应商报价 | 可复核的估算口径，注明假设与计算方式 |
证据不足时的处理原则有三条。第一，标注置信度：把证据分为“有直接材料支撑”“有间接材料支撑”“仅为判断或推测”三档，评审时按档位比较。第二，写明假设：把“我们相信用户会……”这类判断显式写成假设，而不是混在结论里。第三，设定验证期限：为关键假设指定验证方式和到期时间，到期未验证的假设在下次评审时降级处理。这样处理既不因缺数据直接搁置需求，也不把推测当成事实拍板。
证据留存的操作步骤：从收集到归档
证据留存的价值在于让取舍过程可复核。以下四步按顺序执行，每步都有明确的输入、动作、输出和完成标志，可以按需求逐条推进。
步骤一：建立证据条目
输入是需求描述和已有材料。动作为每条需求建立独立的证据条目，逐条记录来源类型、获取时间、提供人、原始材料位置（如访谈纪要、工单编号、会议记录）。输出是一份挂在需求下的证据清单。完成标志是每条证据都能追溯到原始材料，且提供人和时间齐全。
步骤二：区分事实性证据与判断性证据
输入是步骤一收集的材料。动作为把材料分为两类：事实性证据指可直接核对的内容，如用户原话、工单数量、合同条款；判断性证据指基于经验或局部观察的推断，如“预计能提升转化”。两类分别标注可信度，事实性证据标注材料完整度，判断性证据标注推断依据和影响范围。输出是带可信度标注的证据清单。完成标志是每条证据都有类别和可信度标记，没有未分类材料。
步骤三：为关键假设写验证计划
输入是证据清单中支撑结论的关键假设。动作为逐条写明验证方式（如补充用户访谈、上线小范围试点、查询后台数据）、负责人和验证时间。输出是假设验证计划表。完成标志是每条关键假设都有负责人和明确日期，没有“待定”项。
步骤四：评审前汇总，评审后归档
输入是证据清单和假设验证计划。动作为评审前把材料整理成证据包，按统一口径列出各需求的证据强弱；评审后记录结论、参与人意见和保留意见。输出是评审记录与归档证据包。完成标志是结论能对应到具体证据条目，保留意见有署名，后续数据补齐后可回看修正。
在工具层面，证据条目需要随需求对象一起留存，而不是散落在个人文档里。ONES 通过统一的业务需求池、产品需求池与工单系统，实现业务反馈与产品开发联动，业务团队可跟踪需求处理进度，产品经理可基于用户反馈持续优化路线图。将访谈记录、工单来源和评审结论关联到需求条目上，可以让证据在需求流转过程中保持可追溯；具体关联方式与字段配置需在实施时按团队实际情况核验。
角色分工与各环节交付物
证据留存如果只由产品经理承担，容易变成走形式。把收集、判断、归档拆到不同角色，既分担工作量，也让每条证据有明确的责任人。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 需求提出人 | 说明业务背景，给出初始价值假设 | 需求背景说明、初始假设清单 |
| 产品经理 | 组织证据收集，维护证据条目，主持取舍评审 | 证据清单、评审议程、评审记录 |
| 业务或客户侧对接人 | 提供用户原话、访谈记录、客户反馈材料 | 访谈纪要、反馈汇总、客户诉求说明 |
| 评审参与者 | 对证据强弱给出判断并署名 | 评审意见、对关键假设的质疑或确认 |
| 归档责任人 | 保证结论、依据与保留意见完整留存 | 归档证据包、版本记录 |
分工时注意两点。其一，需求提出人对初始假设负责，但不必承担全部证据收集，否则容易只提交对自己有利的材料。其二，评审参与者的判断要署名，便于后续回看时区分“当时基于什么证据做出的判断”。归档责任人可以由产品经理兼任，但要明确归档时点，通常在评审结束后一个工作日内完成。
示例：一条缺少数据的需求如何留存证据并完成取舍
以下为演示情景，用于说明证据条目和评审记录的写法，不代表真实案例。
需求背景：客服团队提出“在订单详情页增加批量导出功能”，理由是客服处理客诉时需要逐单截图。该需求缺少使用频次和工时数据，价值问题属于成本节约与用户价值交叉。
| 证据条目 | 内容 | 来源与时间 | 提供人 | 可信度 |
|---|---|---|---|---|
| E1 | 客服主管反映近一个月有多次逐单截图操作，涉及约若干客诉工单 | 客服周会记录，评审前两周 | 客服主管 | 事实性，材料为会议记录，完整度中 |
| E2 | 两名客服人员口述每次截图约需数分钟 | 访谈纪要，评审前一周 | 客服专员 | 判断性，样本小，置信度低 |
| E3 | 假设：导出功能可减少客诉处理中的重复操作时间 | 产品经理整理 | 产品经理 | 假设，待验证 |
假设验证计划：由产品经理在两周内抽取若干客诉工单，统计涉及截图的工单占比；由客服主管提供一个月内的操作记录。验证到期后更新证据条目。
评审时与另一条需求比较：另一条需求有明确的客户合同条款支撑，属于事实性证据且材料完整。按同一口径比较，批量导出需求的证据以口述和假设为主，可信度低于合同条款支撑的需求，因此本次评审将其列为“有条件进入”，条件是两周内补充工单占比数据，数据达到约定比例再排期。
归档写法示例：“结论：暂不排期，列为有条件进入。依据：E1 会议记录、E2 访谈纪要、E3 待验证假设。保留意见：客服主管认为客诉量被低估，建议补充一个月操作记录。验证负责人：产品经理，验证时间：两周后。”这样的记录让后续数据补齐时可以直接回看并修正结论。
完成检查：证据留存是否足以支持取舍
评审前用以下清单逐项核对，全部满足即可认为证据包达到可评审状态；存在未满足项时，应在评审记录中注明缺口和处理计划。
- 每条需求都有独立证据条目，来源、时间、提供人齐全，可追溯到原始材料。
- 事实性证据与判断性证据已分开标注，可信度标记完整，没有未分类材料。
- 支撑结论的关键假设均写明验证方式、负责人和验证期限，没有“待定”项。
- 评审结论记录了依据对应的证据条目，保留意见有署名，参与人意见可区分。
- 证据包已归档到需求对象下，后续数据补齐后可按同一结构更新并回看修正。
- 对于证据不足仍决定推进的需求，记录中写明了推进理由和风险承担人。
这套做法的适用条件是团队愿意为每条需求投入少量整理时间，并在评审中按统一口径比较证据强弱。需求量大、评审周期短的团队可以先用简化版清单，只保留来源、可信度和验证期限三项，待流程稳定后再补充完整字段。
常见问题
只有一两条用户口述，能作为需求取舍的证据吗？
可以作为证据，但要按判断性证据处理，标注样本小、置信度低。评审时把它与事实性证据分开比较，例如合同条款、工单记录这类可直接核对的材料。口述材料的作用是提示方向，支撑结论还需要补充验证计划，写明由谁在什么时间用什么方式核实，例如抽取工单统计占比或补充访谈。到期未验证的假设在下次评审时降级处理。
需求很急，来不及整理完整证据包怎么办？
可以先用简化版清单，只保留三项：证据来源、可信度标记、关键假设的验证期限。评审记录中写明缺口和处理计划，并指定风险承担人。这样既保证紧急需求能推进，也留下后续补证的线索。流程稳定后再逐步补充提供人、原始材料位置等字段。
证据条目应该放在哪里，才能让后续评审和回看都用得上？
证据条目要挂在需求对象下，与需求描述、评审结论放在一起，避免散落在个人文档或聊天记录里。ONES 通过统一的业务需求池、产品需求池与工单系统，实现业务反馈与产品开发联动，业务团队可跟踪需求处理进度，产品经理可基于用户反馈持续优化路线图。把访谈记录、工单来源和评审结论关联到需求条目上，可以让证据在流转过程中保持可追溯；具体关联方式与字段配置需在实施时按团队实际情况核验。
评审参与者对证据强弱的判断不一致时怎么处理？
把分歧写进评审记录，而不是在结论里抹平。每位参与者对证据的判断署名，注明各自依据的证据条目。分歧集中在关键假设上时，转为验证任务，指定负责人和期限，用补充材料在下一轮评审中收敛。这样后续回看时能区分当时的判断依据，也便于数据补齐后修正结论。
数据补齐后，原来的取舍结论需要重新走一遍评审吗？
不必全量重审，但应按同一结构更新证据条目，并在评审记录中标注结论是否变化及原因。原结论、保留意见和验证结果放在一起留存，形成可回看的修正轨迹。如果补充数据推翻了关键假设，涉及排期的需求应重新提交评审，按更新后的证据强弱重新比较。
