发现问题

策略项目的原动力是问题，方案跟在问题后面。本模块解决：问题从哪来、怎样定义「好」、怎样用样本看清原因、怎样排成下一阶段计划。

四条途径要配合：反馈给线索，监控给异常，回归检验上一版，调研看当前全貌。理想态没立住，后面的抽样和优先级都会漂。

flowchart TB
    A[四条途径] --> B[用户反馈]
    A --> C[系统监控]
    A --> D[效果回归]
    A --> E[阶段性调研]
    E --> F[理想态]
    F --> G[抽样分析]
    G --> H[优先级与项目计划]

核心关系是：先从结果走进问题，再立住可衡量的理想态，用有代表性的 Case 估计影响面，最后按单位成本下的收益排序。

结果层只看到转化率低、点击率掉了；问题层要写出哪类用户在哪一步离开、为何离开、解决后改善什么。没有问题层，监控看板再多也只是在重复播报结果。

策略问题往往一开始只表现为一个难看的数字。第一件事是判断：这个数字已经能解释原因，还是只是结果层的警报。解释不清时，优先补证据。

理想态是产品方案确实解决了用户问题，必须可衡量并服务当前阶段。简单产品可找单一指标；复杂产品不能把点击当成满足。

抽样用有代表性的 Case 近似认识群体。影响面是发现阶段的统计描述，还不是项目收益。优先级按单位成本下的收益排序，红线可以跳过比较。

途径	特点	局限	适合回答的问题
用户反馈	随机、具体、贴近个体感受	不是随机抽样，难直接估计全体发生率	用户遇到了什么具体问题？感受如何？
系统监控	持续、自动、及时	发现异常但不能直接定位原因	哪个指标或环节现在异常？
效果回归	针对上一版本或项目	视野受项目范围限制	这次方案是否有效？有没有副作用？
阶段性调研	全面、系统、覆盖当前全貌	成本高、耗时长	当前产品主要问题是什么，下阶段做什么？

一个重要问题通常需要多个证据互相印证：反馈提供用户语境，监控发现波动，回归验证版本，阶段性调研负责全局盘点。

flowchart LR
    A[日常：反馈与监控] --> B[版本节点：效果回归]
    B --> C[阶段节点：调研盘点]
    C --> D[计划落地：需求与评估]
    D --> A

核心关系是：日常入口负责及时发现，版本节点检验上一方案，阶段节点形成下一计划，计划落地后再进入发现。

三项都含糊时，先补证据，不要直接写需求。进入项目前应收敛成一个问题层表述，表述里至少有人群、环节、场景和「解决后改善什么」。

上一模块概念基础回答「这是不是策略、怎样写成四要素」。本模块把循环的第一阶段展开。下一模块需求与验证把排完序的问题写成可开发需求，并用效果回归检验上一版本。

定义理想态到验证的通用闭环，见策略通用方法论。评测指标与实验设计，见评测。

进入项目前，问题层表述至少有人群、环节、场景和「解决后改善什么」。缺一项，就还在结果层。安全、合规、资金类即使样本极少，也不能等它长成大盘再处理。

理想态写完后立刻用两个真实 Case 试标。两个人标不一致，先改定义卡，再大规模抽样。抽样先定目标再选对象；只抽已展示结果会漏掉覆盖。优先级用 IoI 作常规排序，红线置顶。课程里的样本量、阈值和「10 天 10 点」都是教学示意。

按列表顺序读七篇。赶工时先读四条途径和理想态，再按手头证据补用户反馈或监控；做阶段规划时把阶段性调研、抽样和优先级连起来读。

课程案例中的数字、阈值和公式是教学示意，不能直接当作可上线参数。出行成交率和搜索满足度只作方法对照。

来源说明

本文根据公开课程《策略产品经理》（B 站 BV1YE411g717）整理为知识点，不是逐课笔记。

课程中的数字、阈值和公式是教学示意，不能直接当作可上线参数。

对应原课第 5 至 13 集。整理日期：2026-09-04。

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