4. 识别产品路线图中的关键假设
产品路线图中的每一项功能请求、用户故事或战略举措，本质上都是一个未经证实的假设。本章节定义了一套标准操作程序，用于将隐性的团队共识显性化为四类可记录、可追溯、可验证的结构化假设，从而避免将资源浪费在错误的优先级上。
关键洞察：研究表明，超过 60% 的功能上线后未能对核心业务指标产生预期影响，其根本原因往往在于初始假设未经验证便开始开发。结构化的假设分类是降低此“交付陷阱”风险的第一道防线。
4.1 适用场景
- 季度/双周产品路线图规划与审视会议。
- 启动具有高不确定性（如新产品、新市场、新架构）的项目前。
- 跨多个团队协作的路线图项依赖关系梳理与风险评估时。
- 对已有功能进行重大改版或策略调整前的复盘阶段。
4.2 前置条件
- 已完成初步用户研究（访谈、问卷调查）或数据分析（埋点、漏斗分析）。
- 已维护一份包含待办项（Epic/Feature）草稿的产品路线图。
- 已建立历史 A/B 测试与功能上线结果的知识库（如有）。
- 核心项目团队（PM、工程、设计、数据）已到位。
4.3 操作步骤
- 需求优先级假设：陈述“我们相信，功能 X 是 Y% 用户中最重要的未满足需求。” 对照用户访谈纪要、调查数据或竞品分析报告进行映射与验证。
- 用户行为假设：陈述“我们相信，用户会通过点击按钮 Z 来完成流程 A。” 审查现有埋点数据以设定行为基线，并估算预期样本量。
- 技术可行性假设：陈述“我们相信，新的推荐引擎可以在 ≤200ms 内提供结果。” 与工程团队进行技术设计冲刺或原型验证，识别潜在瓶颈。
- 商业收益假设：陈述“我们相信，将转化率提升 X% 将使 LTV 增加 Y 美元。” 根据市场数据与财务模型，验证单位经济效益的合理性。
4.4 输入输出物
| 假设类型 | 输入（数据/工件） | 输出（记录/决策） |
|---|---|---|
| 需求优先级 | 用户之声、市场报告、路线图待办列表 | 假设记录单、风险评分 |
| 用户行为 | 埋点数据、热力图、用户测试视频 | 预期行为基线、样本量估算 |
| 技术可行性 | 架构图、技术方案、原型 | 技术风险登记册、依赖关系清单 |
| 商业收益 | 财务模型、历史 LTV 数据 | 北极星指标影响评估、ROI 预测 |
4.5 责任边界
- 产品经理：主导需求优先级与商业收益假设的提出与评审。
- 工程师：主导技术可行性假设的验证与记录，评估实现成本。
- 设计师/用户研究员：负责用户行为假设的细化与基线建立。
- 数据分析师：审核所有假设的可衡量性，并协助定义成功指标与样本量。
4.6 记录材料
假设记录单模板
假设ID: HYP-004-01
类型: [需求/行为/技术/商业]
路线图项: [功能名称]
陈述: 我们认为 [目标用户] 将通过 [行动] 实现 [收益]。
衡量标准: [具体指标，如 CTR、LTV]
关键数据源: [如用户访谈、埋点事件]
所有者: [姓名]
状态: [已提议/已验证/已证伪]4.7 异常处理
冲突调节：当技术可行性假设与商业收益假设冲突时（例如，技术实现成本过高导致 ROI 为负），需由产品经理与 Tech Lead 召开权衡会议，必要时升级至决策层进行资源博弈。
- 假设被证伪：若在 A/B 测试前已有充分证据表明假设不成立，应果断取消或降级该路线图项，避免开发浪费。
- 无法衡量：若一个假设无法定义具体量化指标，应与数据团队结对，寻找可代理的替代指标，否则视为无效假设，不得进入开发阶段。
- 依赖缺失：若某项假设依赖外部数据或第三方服务，需在记录中明确标注阻塞状态，并设定决策等待时间窗口。
4.8 验收标准
- 每个路线图项均关联了 4 类（需求、行为、技术、商业）明确的假设记录。
- 每项假设均指定了唯一的所有者。
- 每项假设均定义了具体的量化衡量标准与数据来源。
- 所有假设已在团队内进行过“证伪测试”评审，通过后方可进入开发管道。