阶段性调研

阶段性调研

策略很难一次上线就到达理想状态。一个方案通常要多轮迭代：上线后回看效果，判断是否真的解决了用户问题、卡在哪一段、下一轮做什么。效果回归是 PM 的学习机制：看到哪些判断正确、哪些有偏差，才能修正方法论。

但回归往往只围绕上一版本或某个项目；监控偏向持续发现异常；用户反馈则是随机、零散地暴露问题。阶段性调研的任务不同：针对当前产品现状，做一次完整、系统、上下左右都覆盖的分析。四条途径的对比见发现问题的四条途径。

策略通用方法论是四步：定义理想态 → 拆解未达理想态的情况 → 提出解决方案 → 验证是否解决问题。阶段性调研主要做前两步，并在第三步上交出可排期的项目清单；具体方案、成本和预期解决比例还要进入研发预研，不能在调研里把算法写死。

flowchart LR
    A[定义理想态] --> B[拆未达情况]
    B --> C[形成项目计划]

核心关系是：理想态给出尺子，抽样给出未达类型和影响面，项目计划把问题变成可排期条目。

调研工作量很大，范围定义错了后面容易整体返工。正确顺序是：阶段目标 → 理想态 / 指标 → 未达成类型 → 抽样对象 → 分析标注 → 项目优先级。不能倒过来先拿一批现成数据，再强行找结论。

三步

第一步：定义理想态。 定义产品「应该是什么样」，并用数字化指标或其他明确标准衡量。没有可衡量的理想态，后面无法判断哪些是未达标。理想态服务于当前阶段目标，不是遥不可及的终极愿景。详见理想态。产出：理想态定义、核心指标或判断标准、指标口径。

第二步：拆未达情况（抽样分析）。 基于理想态，找到没有达到理想态的样本，分析每个 Case 背后的原因，并统计各类问题的影响面。不要从自己熟悉的方案或已有数据出发，而要问：理想态由哪些必要环节组成？哪一环节失败会使最终结果不达标？每种失败能否用数据或 Case 验证？是否遗漏了某类用户、场景或业务边界？

交易型产品可沿「发起-匹配-执行-完成」拆；推荐型产品可能拆成「是否该展示-展示了什么-排序是否合理-用户是否得到满足」。方法细节见抽样分析。产出：样本集合、标注结果、问题分类、问题影响面。

1

问题影响面 = 问题 Case 数 ÷ 调研总体 Case 数

影响面是发现阶段的统计描述，不等于项目收益，也不等于最终能提升的业务指标。公式是教学示意。

第三步：形成项目计划。 综合影响面、严重程度、解决成本以及预计解决比例，确定哪些问题先做、由谁负责、进入哪个阶段。每类问题至少补齐：影响多少用户或订单、对理想态的损失、是否涉及严重风险、需要什么团队、当前阶段能否解决、解决后如何回归。这样得到的是可讨论、可排期、可追踪的项目清单。排序方法见优先级与项目计划。产出：项目列表、优先级、预期收益 / 成本、后续计划。

调研结论应描述当前问题及影响面，而不是未经预研就断言某个算法一定有效。发现用的问题树和落地用的项目结构可以不同：前者便于识别，后者便于按乘客端 / 策略端 / 运营或需求分析 / 排序 / 收录来分工。

调研开始前建议先写一页理想态定义，避免后面整体返工。课程用「瞬间移动」作反例：对打车更理想，但对当前工作没有操作意义。未达成类型要按理想态反推，不要按自己会做的方案反推。

何时启动

1. PM 刚接触一个新产品：先摸清产品、用户、流程、指标和现有问题，不能马上凭经验接需求。
2. 周期性回顾：每月、每季度或每半年做整体评估。周期按业务变化速度定，不是越频繁越好。
3. 不定期的管理或业务需要：新总监要了解现状；季度中已上线多个优化，旧数据不再代表现状；新版本暴露了尚未纳入列表的新问题。这时需要一份「热气腾腾」的现状调研，而不是直接复用旧报告。

还要刻意检查：是否覆盖完整业务链路和主要用户 / 场景；是否把新版本之后出现的问题纳入；是否仍在使用已经过时的历史数据。对极小范围单一故障，用监控、日志或专项排查更高效，不必上完整调研。对变化极快的实时系统，不能只依赖低频调研，还要配合持续监控。

「发现问题」和「判断方案」要分开。阶段性调研的结论是当前问题及影响面；方案、成本和预期解决比例应在项目评估阶段由 PM 调研与 RD 预研共同确认。

刚接手产品时，先问清：产品解决谁的什么问题、当前核心指标是什么、关键流程有哪些分支、哪些团队共同影响最终结果。周期性回顾时，周期应根据业务变化速度决定：变化快可以按月，变化慢可以按季度或半年。不定期启动的典型信号是：新管理者要看现状、季度中已上线多个项目导致旧数据失效、新版本带出了清单外的问题。这三种情境的共同点是：当前需要一份能指导下一阶段计划的全貌。

方法如何落地：两例短对照

两例只说明方法如何落地，样本量和百分比不能当成所有调研的固定参数。10 公里、5 公里等是案例条件，不能当通用阈值。

无应答继续按机制拆：召回范围内无司机、有司机但过远未推送、有合适司机但未排到前面、已推送但司机未接。避免把四种机制混成「司机不愿意接」。搜索侧：无点击但结果页已直接给答案，可能满足；只点一条且结果足以完成任务，也可能满足；连点、改词、翻页才找到，则是满足不够好。

调研结论与计划字段

报告结构：

1
2
3
4
5
6
7
8

1. 调研背景与目标
2. 产品理想态及指标口径
3. 抽样范围与方法
4. 问题分类与影响面
5. 重点案例
6. 问题优先级及判断依据
7. 下一阶段项目计划
8. 风险、待确认项与验证方式

立项前先写理想态和范围，抽样中只填结论表的前六列，预研后再补项目和负责人。不要在还没有口径的时候先写项目名称。

每条进入下一阶段的项目至少能回答：

1
2
3
4
5
6
7
8

项目名称：
对应的未达理想态类型：
影响面及分母：
代表性 Case：
PM 判断的原因假设：
需要 RD 预研确认：解决程度 / 成本 / 依赖
不做什么（本阶段明确排除）：
上线后回归什么指标、看哪些分群：

「不做什么」和「要做什么」同样重要。阶段性调研最常见的失败是把所有未达标都写成项目，下一阶段无法执行。明确排除项应写回理想态定义卡里的「本阶段不纳入的终极目标」。

调研产出的项目上线后，不要另起一套指标。回归应回到调研时的理想态口径、同一类 Case、同一分群。若回归发现新问题大面积出现，说明现状已经变了，应启动下一轮阶段性调研。

误区与边界

• 把效果回归当作项目结项。 回归的目的是决定产品循环是否结束、下一轮做什么。
• 理想态写成口号。 「提升体验」不能直接指导抽样和标注。
• 把终极愿景当成当前理想态。 当前理想态要与阶段目标、产品能力和可执行项目匹配。
• 只分析上一版本数据。 阶段性调研关注当前全貌，应检查旧数据是否已经被新项目、新问题淘汰。
• 只列问题、不产出计划。 没有影响面、成本和负责人，调研无法进入执行。
• 把解决方案提前写死。 调研阶段先确认问题，具体方案还需要研发 / 运营预研。
• 对极小范围单一故障也上完整调研。 那种情况用监控、日志或专项排查更高效。
• 只依赖低频调研。 变化极快的实时系统还要配合持续监控。

阶段性调研适合产品现状复杂、问题分散、需要规划下一阶段的场景。理想态暂时无法量化的搜索 / 推荐，仍要先定义阶段性、可操作的最佳方案，再用抽样和人工标注近似衡量。安全、合规问题应另设更高优先级的风险处置。滴滴案例中的 1000 个样本、百度案例中的 5000 / 1500，只说明「方法如何落地」，不能当成所有调研的固定样本量。

阶段性调研的质量不取决于报告页数，而取决于三步是否闭环：理想态能否指导标注，未达类型是否互斥且覆盖目标，项目计划是否带口径、负责人和验证方式。若调研结论无法直接进入优先级与项目计划，说明第三步还没有做完。

从局部回到全貌时，固定问四句：完整链路覆盖了吗？主要用户和场景覆盖了吗？新版本之后的问题纳入了吗？手里的数据还热吗？有一句答不上，就还不能把旧材料当成当前结论。

对交易产品，未达成分支最好先画成状态树再抽样。对搜索 / 推荐产品，最好先写满足判定手册再抽样。状态树和判定手册都是理想态的可执行形态。

调研日历可以很简单：接手时做一次、每个规划周期做一次、现状明显过时时加做一次。三次以外的「随时调研」容易变成没有范围的日常分析，和监控、反馈抢活。

调研开工检查：阶段目标是否写在一页纸上；理想态是否可衡量，且不是终极愿景；未达类型是否从理想态反推；抽样总体、实体、时间窗口是否与目标匹配；问题框架是否总分清楚、同级互斥；每类问题是否都有影响面、代表 Case、负责人候选；项目计划是否等待 RD 预研后再锁解决比例和成本；旧报告的数据是否仍代表当前版本。有一项为否，就还不应召开「排期会」。

延伸阅读

• 理想态：调研三步的第一步如何写成可衡量标准
• 抽样分析：未达情况如何抽样、标注和汇总
• 优先级与项目计划：问题清单如何变成阶段计划
• 效果回归：回归看上一版本，调研看当前全貌
• 策略通用方法论：目标-差距-方案-验证
• 发现问题的四条途径：调研与反馈、监控、回归如何配合

来源说明

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用