我们从之前的课程可以学到，作为一个策略产品经理，基本的工作流程可能包含以下四步：
这其实是一个从发现问题到解决问题的完整循环。
那么如何用户问题进而发现需求呢？从策略的角度来说，共有四种方法：用户反馈收集、系统监控、效果回归、阶段性调研
课程截图
1.用户反馈收集
比如，高德地图有用户反馈自己又在西直门大桥上转了三圈才下来，那PM就要注意下，“转了三圈”这件事情太不正常了，是不是导航上某个环节的引导不够合理，导致用户没有注意到而错过了出口呢？
2.系统监控
监控可以主动帮我们发现产品出了什么问题，比如，今日头条的PM收到一条系统报警的短信：过去一小时头条的首页结果点击率同比上周下降了20%。这周的KPI要完不成了，需要赶紧看一下是什么地方出了问题。
3.效果回归
每次新版本上线后，PM都要做下效果回归，看看新版本是否符合预期，这是一个非常直接的发现问题的途径。比如说，滴滴的拼车功能上线了，需要评估下拼车的成功率和拼成后的取消率有没有达成这个版本的优化目标，有没有出现新的问题等等。
4.阶段性调研
阶段性调研是PM抽出一整天或者一整周的时间从头到尾梳理自己的产品到底有什么问题。比如到季度末了，百度搜索的PM开始整体地去评估网页搜索的效果，去确定下个Ｑ产品的优化目标和方向。
案例
很多时候我们不知道问题出在哪里
一.用户反馈收集
课程截图
1.处理用户反馈的基本流程
课程截图
ａ.收集用户问题，要知道从哪里去获取用户反馈
ｂ.用户反馈分析，要弄清楚反馈背后对于的产品问题是什么
ｃ.整理撰写需求，将问题对应的解决方案整理成需求
ｄ.落实产品改进
其中
（１）收集用户问题的常见渠道
自有渠道：
－产品各个端上的用户反馈入口 产品内部
－客服收集到的问题 一般非常重要
外部渠道：
－各类应用商店评论
－微博、贴吧等媒体渠道的评论 关键词搜索
（２）用户反馈分析的方法
案例
数据处理：清洗、标注
问题整理：分析、汇总
课程截图
数据处理的步骤：浏览了解数据内容——删除无效数据——对反馈问题进行标注，理解背后反映的问题
首先要看下反馈数据的格式内容，这份数据可能是应用商店收集来的，可能是RD抓取来的，也可能是客服人员日常记录的。大致的浏览数据维度、格式和内容，可以帮助我们更好的进入下一步。
因为提供数据的人可能不知道PM的分析需求，里面有可能会有无效数据。因此我们需要删掉这些无效数据，帮助我们减少接下来标注工作的成本。
接下来就可以对剩下的有效数据进行一一标注，理解背后反映的问题。但是这里要清楚一点：“数据是有效的，但不一定是有效的反馈”。
课程截图
常见问题分类：“不是问题”、“已知问题”、“未知问题”
1.不是问题：常见为用户的抱怨，在产品当前的服务范畴之外
2.已知问题：常见为优先级不高、或已在项目计划中还未上线未排上需求的老问题
3.未知问题：常见为新版本问题或之前没发现的老问题，如果无法直接判断原因，需要抽取当时具体session（自有渠道）、或进行用户回访（外部渠道）定位问题。
【问题整理实例】——某外卖平台应用商店评论
部分原始数据
进行问题标注和问题分类
部分问题标注，进行统计，做一个excel数据透视表如图所示
数据透视表整理数据
数据透视表整理数据
（3）用户反馈分析的局限性
课程截图
用户反馈分析的局限性：
虽然直观，但是收集到的问题比较随机，很难反映产品现状的全局。
虽然可能代表一类问题，但是问题的影响面和优先级比较难判断。
（4）小结
课程截图
每一个反馈背后都是一个真实用户的情感表达，以敬畏心态深入分析每一个问题。
首先，敬畏用户的感受。当你听到他的声音的时候他已经很痛了。
其次，敬畏反馈背后隐藏的问题。可能这就是一个堤坝上的蚁穴。
二.系统监控
课程截图
方法二、系统监控
一、系统监控是什么
系统监控是一种针对相对稳定的产品，通过对数字性指标的收集和观察，自动、实时发现问题的有效手段。
首先，系统监控作用的产品类型是相对成熟和稳定的，因为我们要用机器的手段去发现问题，如果这个产品三天两头在重构，所有的数据表现一直在变，那我们是没办法去做监控的。并且对于一个成熟产品，它的模块通常比较多且复杂，PM没办法频繁去检查每个环节是否正常，那这个时候就可以借助机器的力量了。而机器很难模拟用户的真实体验，所以我们的监控对象是各类统计性的指标。
自动指的是我们可以利用机器去执行，可以一天24小时不停地去监控。实时指的是可以持续不断的去监控，并且可以在问题发生的第一时间去获知。自动和实时在很大程度上减少了我们的人力成本，并且增加了问题发现的时效性，可以及时帮助我们去止损。
系统监控是一个自动化的报警手段，能伴我们解放双手，只要我们给到对应的规则，不需要主动挖掘，自动的能帮助我们发现需求。
二、如何搭建监控体系
课程截图
分为两步：
1.定义待监控指标：告诉机器要观察哪些指标
2.定义报警规则：告诉机器什么时候&如何通知我们
1.如何定义待监控指标
课程截图
所以的产品流程都可以用上图的框架来抽象，整个框架分为两个部分。
一部分是用户直接感受到的，用户和产品发生的交互动作，就是前台，比如说行为1、行为2，这部分可以称为“白盒”。白盒直接反映了用户的体验，这是需要我们密切关注的。
另一部分是用户发起请求的时候，我们为了给出下一步的反馈，系统内部不同模块做出的一系列动作，是后台。这些是用户不会直接感受到的，但这些动作直接影响了产品给出的反馈结果是什么，这些我们称之为“黑盒”。黑盒部分的运转是否正常，间接影响了用户的体验。
案例1：百度搜索
案例2：滴滴出行
案例3：淘宝消息推送
白盒部分可能会有功能和策略共同去作用控制，我们把整个这个控制以及针对他的监控称之为“效果监控”，指的是整个产品的体验效果的监控。我们把其中可以用来衡量用户体验的核心指标抽出来作为待监控指标。
黑盒部分监控的其实是各个模块之间的交互，怎样可以一步步地输出用户可以感知到的结果。对于功能产品来说，这其实是纯粹的技术模块之间的交互，比如说客户端和服务端API，服务端API跟更多的挂载的数据和服务之间的交互等等。这里的监控系统通常是由研发人员去搭建和维护的。对于功能和策略共存的产品来说，黑盒部分是有很多策略模块的，是需要由PM重点关注和观察的，所以这里面的监控系统是需要PM提出和发起搭建的。
所以，站在策略PM的角度，除了要针对白黑的效果监控之外，还要针对黑盒中的策略模块的监控，称之为“策略监控”。将效果监控分开，我们需要选取能够衡量各个策略效果的核心指标作为待监控指标。
根据产品流程的框架，我们把监控分为两种类型。
系统监控类型
1.效果监控
针对产品的白盒部分，监控用户的体验，即产品的核心目标。该指标发生异常变化时需要重点即刻关注。
2.策略监控
针对产品的黑盒部分，监控某个策略的运转情况，对象为各类中间指标。该指标经常受到某个项目迭代影响，监测作用大于监控。
举例，左边是效果监控，右边是策略监控。
“策略监控并不一定直接影响用户的体验”
2.定义报警规则
触发报警的条件：什么时候报警
报警的方式：怎么报警
触发报警的条件
根据产品历史数据得到正常波动区间，在正常区间外即发起报警给相关负责人。
报警方式
监控指标的重要程度和波动幅度决定了响应的及时性，我们根据响应的及时性来选择不同的报警方式：电话、短信、邮件。
如何界定正常波动区间？
1.数据敏感度
波动是否超越历史波动范围，有一些历史数据，去掉噪点
2.三西格玛理论
符合正态分布，波动范围在
如何评估指标重要程度？
两个衡量维度：对产品核心目标（用户体验、收入等）的影响面和影响程度。
四个分类：不重要、一般重要、重要、很重要
案例：今日头条的抓取策略
我们如何选择报警方式？
课程截图
1.波动幅度高、重要程度低：短信
2.波动幅度高、重要程度高：电话
3.波动幅度低、重要程度高：短信
4.波动幅度低、重要程度低：邮件
2.2举个例子【实例】效果监控系统搭建：
网页搜索中图片类特型结果的监控体系搭建
一、什么是网页搜索中的图片类特型结果？
宜宾菜坝机场搜索结果
搜索“宜宾菜坝机场”，首页展现四张图片。
九寨沟搜索结果
搜索“九寨沟”，除了展现四张图片，上面还有景点的推荐。
云豹搜索结果
搜索“云豹”，展现了两排图片，且图片有大有小，有竖图有横图。
头像搜索结果
搜索“头像”，展示的图片数量很多，且有筛选功能。
以上几种都是图片类特型结果。
这些用户的搜索词（宜宾菜坝机场、九寨沟、云豹、头像等）背后有图片类的需求。
二、搜索产品框架
首先用户输入搜索词，然后用户就会看到搜索结果，如果用户看到了合适的搜索结果就会点击，还没有找到就会翻页，或者没有检索到所需内容更换搜索词重新搜索。这是白盒部分。
用户输入搜索词之后，系统会对用户输入的文本进行分析，识别背后的需求，这是需求识别策略。然后在数据库中检索产生排序，这是检索策略。最后选择什么的样式展现给用户，这是展现策略。这些是黑盒部分。
三、如何搭建网页搜索中图片特型结果的效果监控（针对白盒部分）
我们将白盒部分的产品流程进行归类，以帮助我们更好的梳理逻辑。
首先，我们将用户能“看到结果”成为产品的覆盖情况。接下来用户要表达是否满足，这里包含一些不同的点击行为，比如说点击，继续翻页，更换搜索词再次搜索等等，我们称之为产品的满足效果。
1.效果监控的两部分内容
覆盖情况：当用户表达图片类需求时，产品展现在搜索结果中
满足效果：当用户看到该特型结果时，产生了点击或其他代表满足的行为
2.衡量覆盖情况的监控指标
影响面：图片特型结果的展现流量/网页搜索总流量
为了更细化，我们定义以下的指标：更细粒度的指标：展现首位影响面、展现二位影响面、... 、展现第十位影响面
覆盖情况的报警规则：
小时级监控：同比上周同期波动>5%时，以短信形式发出报警；波动>20%时，以电话形式发出报警。
3.衡量满足效果的监控指标
用户的满足效果分为正向和负向，正向反馈为点击行为，负向反馈是翻页和更改搜索词等等行为。
针对正向反馈，我们设置监控指标为：
点击率：点击图片特型结果次数/结果总展现次数
展现首位点击率...展现第十位点击率等等
针对负向反馈，我们设置监控指标为：
翻页比例：结果展现后用户翻页的次数/结果总展现次数
更改搜索词比例：结果展现后用户更改搜索词的次数/结果总展现次数
满足效果的报警规则：
根据历史数据，小时级的监控数据波动比较大，天级的监控数据比较稳定，但是天级监控具有滞后性，因此依然保留小时级监控，但是将阈值放高，天级监控时效性不高，重要程度下调一档。
小时级监控：同比上周同期波动>50%时，以短信形式发出报警
天级监控：同比上周同日波动>5%时，以邮件形式报警，波动>20%时，以短信形式发出报警。
四、策略产品经理工作中的“黑话”
图片类特型：指图片类特殊类型的结果，在百度又被称作阿拉丁结果，常见的还有天气类特型、地图类特型等。
Session：指用户行为的一个片段，包括一个或多个连续动作。对于不同产品，会根据其业务类型自行定义如何将某用户的所有行为切割成不同片段，通常以用户在产品上完成一个独立的目的为切割方式。所以Session是评估用户某个需求的满足程度的最小数据单元。
Query：指搜索词
Tab：原义指标签，通常指产品导航栏
实例：如何搭建网页搜索中图片特型类结果的策略监控（针对黑盒部分）
一、图片特型结果的策略环节
课程截图
1.需求识别策略
首先识别用户的搜索词是否包含图片需求
2.检索策略
如果识别为图片需求，开始针对性地在图片结果库中进行检索
3.展现策略
将检索到的结果以符合用户需要的样式进行展现
二、需求识别策略
1.如何衡量需求识别策略的效果？
策略的目标是将所有背后隐含图片需求的搜索词都识别出来，而且没有隐含的都不会错误的识别出来。所以这里面是两个维度的指标，第一个覆盖程度，第二个准确程度。
但是，现实中，只能监控识别到了多少。
2.需求识别策略监控指标
覆盖率：识别为图片需求的流量/网页搜索总流量
“识别为图片需求的流量不等于展现了的图片需求的流量”
需求强度分布：强、中、弱需求的比例*图片需求=强需求量+中需求量+弱需求量
比如：
吴亦凡图片：强图片需求
吴亦凡：中图片需求
邢台：弱图片需求
报警规则：
三、检索策略
1.如何衡量检索策略的效果？
通过 质量来衡量。
2.监控指标
相关性打分=每个搜索词对应结果的相关性打分均值
3.监控规则
小时级监控，同比上周同期波动>20%时，以短信形式发出报警；
波动>50%时，以电话形式发出报警。
四、展现策略
1.如何衡量展现策略的效果？
监控各种展现样式的表现：样式占比、点击率
四种样式：多排筛选样式、多排样式、单排筛选样式、单排样式
2.监控指标
3.监控规则
课程截图
小时级监控：
同比上周同期波动>5%时，以邮件形式发出报警；
同比上周同期波动>20%时，以短信形式发出报警。
五、通过监控获得需求的总结的局限
1.图片特型结果的监控体系的搭建
首先第一步，我们将用户与产品的交互进行分析，将监控拆解为针对白盒部分的效果监控，和针对黑盒部分的策略监控。
对于白盒部分，我们又进行拆分和抽象。首先用户要看到结果，这个是产品的覆盖情况。接下来用户可能产生各类行为，比如点击、翻页、更换搜索词，这个代表了产品的满足效果。
对于黑盒部分，我们将整个策略体系分为需求识别、检索、展现三个不同的策略模块分别进行监控。
2.监控的局限性
局限1：考虑到准确率，监控覆盖的精度（策略意义上的召回率）有限，精度是有问题的。
局限2：虽然可以帮助发现异常，但通常不能直接定位问题，最终依然需要配合人工手段确定最后的问题。
3.小结
对于任何一个复杂的策略系统，人工去排查每个模块给用户带来的影响，是一种非常不经济的方式。
所以，线上监控作为一种自动、实时、针对效果的问题发现方法，日趋重要。
2.3 策略产品发现问题的四个方法（三）：效果回归
策略产品发现问题的四个方法：用户反馈收集、系统监控、效果回归、阶段性调研
方法三、效果回归（比较复杂，下个章节讲）
作为一个策略产品经理，基本的工作流程可能包含以下四步：
效果回归是策略产品非常重要的一部分工作，通过每次效果回归来找到问题
1.产品循环：
判断产品循环是否中止
确定产品接下来的计划
2.PM自我成长的重要途径：
验证解决方案可行性
修正和巩固方法论
2.4 策略产品发现问题的四个方法（四）：阶段性调研
策略产品发现问题的四个方法：用户反馈收集、系统监控、效果回归、阶段性调研
方法四、阶段性调研
阶段性调研是针对产品现状进行的系统性分析。
此时产出的分析结论最能代表产品问题的全貌，可以有效指导下阶段的产品计划。
一、什么是阶段性调研？
阶段性调研是针对产品现状做的详细完整的系统性分析，PM此时会上上下下、左左右右将产品的所有细节都扫一遍。
相对于随机收集问题的用户反馈、相对于精度不够的监控和只针对上个版本去做的效果回归，阶段性调研产出的分析结论最能代表产品问题的全貌，可以有效指导下阶段的产品计划。
二、什么时候做阶段性调研？
阶段性调研的三个时间节点：
1.接触新产品
PM接手某个产品方向的时候，花时间摸透这个方向，清楚接手之后要做什么事情
2.周期性回顾
每个月/季度/半年等固定周期的回顾，做一个整体的评估
3.不定期回顾
其他需要临时回顾整个产品现状时，比如老板要了解的时候
三、如何去做阶段性调研？方法论
策略产品经理通用方法论：
定义理想态——拆解未达理想态的情况——提出解决方案——验证是否解决
具体情况具体分析，在阶段性调研这块我们更注重分析前两部分的内容，这一套方法根据对应情况延展后变成了三步，即：
Step1 找到理想态
定义理想态，并以数字化的指标或其他明确标准来衡量。
Step2 抽样分析
将所有不到理想态的case抽样分析，并做统计分类，明确满足不好的原因。
Step3 优先级判断
汇总所有问题，综合影响面、问题严重程度和解决成本确定优先级，作为接下来的项目计划。
2.4.1策略产品经理如何找到产品理想态？
策略产品经理通用方法论：
定义理想态——拆解未达理想态的情况——提出解决方案——验证是否解决
回顾：
阶段性调研的方法分为三步：
Step1 找到理想态
定义理想态，并以数字化的指标或其他明确标准来衡量，说明产品的目标，理想状态。
Step2 抽样分析
将所有不到理想态的case抽样分析，并做统计分类，明确满足不好的原因。
Step3 优先级判断
汇总所有问题，综合影响面、问题严重程度和解决成本确定优先级，作为接下来的项目计划。
正文：
阶段性调研第一步：如何找到理想态？
1.定义理想态
任何一个产品都是用来解决用户的问题，产品的理想态即给出的方案确实解决了用户的问题。
举例子说明什么是产品的理想态：
百度搜索：用户使用百度搜索是为了查找信息的，那产品理想态就是用户找到了他想要的信息
滴滴：用户使用滴滴是为了前往其他地方的，那产品理想态就是用户到达了目的地
头条：用户使用头条是为了愉悦自己消磨时间的，那产品理想态就是用户在头条上找到了自己想看的内容，花了很久的时间
墨迹天气：用户使用墨迹天气是为了了解天气情况的，那产品理想态就是用户获取了准确的天气信息
2.找到数字化指标或其他明确的标准来衡量理想态
以上四个案例的产品理想态又有些异同，可以简单分为两类：一种简单情况（滴滴、墨迹天气），一种复杂情况（百度搜索、头条）。
简单情况：
理想态的描述相对简单一些。
滴滴的理想态可以简单的用订单成交率这样的指标来衡量，用户是为了打车到达目的地的，只要订单完成了，用户到达了目的地，这就可以衡量产品确实达到了理想态。
墨迹天气的理想态可以用天气信息的准确率来衡量，只要天气准，我就认为到达了理想态。
简单情况：对于大多数刚需和工具型产品、或只是其中的策略模块，通常都可以以【帮用户解决了问题】作为理想态，并找到单一的数据指标来衡量。
复杂情况：
比如百度搜索，其实很难以单一的指标来衡量用户找到了他想要的信息。是否可以用点击率来衡量？用户点了不就是满足了吗？但事实上很多时候用户点来点去没有一条结果有用，所以点的多，并不一定表示满足。没点击也不一定意味着没有满足，比如搜索天气，这时候判断会更难。因此，对于搜索产品，他的理想态的描述是一件相对复杂的事情。
头条，理想态是用户在这里开心的消磨了时间，那要用什么指标衡量呢？是停留时长吗?停留多少时间是理想呢？
复杂情况：但依然存在很多产品，其理想态的描述是相对复杂的。
那么如何描述复杂情况的理想态呢？
搜索：
像百度这种综合的搜索平台，很多时候用户输入了关键词，但是背后隐含的需求是多样的，平台给的方案是猜测，只能满足大多数人的需求。
比如这个例子：在百度中，用户搜索苹果的需求可能是电子品牌苹果、电影苹果、水果苹果等多种情况。
在描述产品实现效果的时候，PM通常会基于对用户的理解、并参照竞品结果，给出根据需求影响面排序的各类搜索结果。
对用户的理解：用户搜索苹果的上下文（搜索苹果之前还搜索了什么），点击行为（大多数人搜索什么），用户更改搜索词等 。
搜索产品通常以平台当前能够给出的最佳产品方案作为理想态。
推荐：
平台是在猜测用户的非刚需求，我们永远不清楚最准确的答案是什么。
所以推荐类产品同样以平台当前能够给出的最佳产品方案作为理想态。
再评估策略推荐出的结果在所有候选集合中是否是最佳结果，用户行为指标作为发现问题的辅助手段。
3.理想态的定义变化
所有的【理想态】都是为阶段性的产品目标服务的，随着产品的进化，理想态的定义也随着进化。
总结
大多数工具属性的产品都可以以【帮助用户解决了问题】作为理想态，并找到单一的数据指标来衡量。
同时也存在一些产品，其理想态的描述是相对复杂的。
无论是简单还是复杂的理想态，都会随着产品进化而发生变化。
2.4.2策略产品经理如何通过抽样分析明确问题原因
策略产品经理通用方法论：
定义理想态——拆解未达理想态的情况——提出解决方案——验证是否解决
回顾：
阶段性调研的方法分为三步：
Step1 找到理想态
定义理想态，并以数字化的指标或其他明确标准来衡量。
Step2 抽样分析
将所有不到理想态的case抽样分析，并做统计分类，明确满足不好的原因。
Step3 优先级判断
汇总所有问题，综合影响面、问题严重程度和解决成本确定优先级，作为接下来的项目计划。
正文：
阶段性调研第二步：抽样分析
1.为什么要进行抽样分析？
策略面对的是难以枚举的一群人的问题，通常需要通过样本来代表群体情况。
2.case
样本们通常被叫做case.
描述理想态的时候需要用case说明、验证产品效果时要用之前的case再回归一遍等等 ，策略PM在工作过程中将随处可见case。
3.抽样的基本步骤
Step1.确定调研目标
首先我们需要明确调研的目标，帮助确定抽样的对象和方式。
首先我们需要明确调研的目标，帮助确定抽样的对象和方式。
首先我们需要明确调研的目标，帮助确定抽样的对象和方式。
重要的事情说三遍！！
案例：
1）分析【相关视频】推荐策略的问题——>抽取所有推荐视频列表，分析问题。
2）分析以上策略模块中广告视频推荐策略的问题——>抽取所有展现广告视频的视频列表，分析问题。
以上案例中，1）的做法是正确的，2）的做法是错误的。因为1）中只涉及准确率问题，但是2）中不仅涉及准确率问题，还涉及召回率的问题，所以不应该只抽取展现的广告视频，应该抽取所有的推荐视频列表，展现了的分析是否准确，没展现的分析是否覆盖。
Step2.确定抽样对象
通过一定规则筛选出的待分析的全量集合。
筛选规则：核心指标未达到理想态、可以代表全体用户的行为的最小时间窗口内的全量数据。
样本类型：根据策略类型，可以是：
用户个体、
行为片段（session）、
搜索词（query）、
订单、
...其他维度
案例：
1）分析滴滴成交问题：直接在全国一周内所有未成交的订单中抽样
2）分析美团搜索问题：因为无法直接通过数字性指标精确筛选哪些是不满足的行为，所有只能退而求其次从一天的全量用户session中抽样，然后人为进行进一步筛选
Step3.选择抽样方法
我们常用的抽样方式是简单随机抽样。
简单随机抽样：从总体N个单位中任意抽取n个单位作为样本，使每个可能的样本被抽中的概率相等。
Step4.确定抽样数量
从统计角度将，抽样数量越高统计准确率越好，然而调研成本也会随之上升。
所以数量是精度和成本的balance，通常只要代表某类问题的样本数量有统计意义即可。
经验值：尽量使代表某问题的样本数量>=5,或者影响面>=3%
案例：
策略相对程度已经没有影响面>5%的显著问题，接下来要看影响面1-5%量级的问题：
为了使1%问题的case数量至少达到5，那抽样数量最少要500。或者在1k的量级、即代表单个问题的case在至少为10个左右，此时得到的问题影响面数据才有较高的置信度。
Step5.样本分析标注
标注方法参见2.1 策略产品发现问题的四个方法（一）：用户反馈收集文章中的描述
Step6.整理汇总问题
将标注出的问题按照合理的逻辑框架整理汇总。（金字塔原理）
上下层级：总分关系
同层级之间：相互排斥，不重复、不遗漏
案例：
爱奇艺视频详情页的【相关视频】推荐策略的问题分析框架。标注后发现有如下问题：
没有收录相关资源
可以考虑同导演推荐的推荐
同系列的推荐个数过多，其他维度没有排上来。。。
整理汇总：
1）结果反推原因
2）也可以直接将问题抽象
问题的框架并不唯一，只要逻辑合理就可以：
标注前有初版预设
标注中不断调研，直到完善
4.总结
抽样分析是帮助我们了解问题全貌的重要环节。
在抽样开始时需要牢记调研目标，最终使用合理的逻辑框架汇总和整理问题。
2.4.3 策略产品经理如何通过优先级判断构建项目计划
策略产品经理通用方法论：
定义理想态——拆解未达理想态的情况——提出解决方案——验证是否解决
回顾：
阶段性调研的方法分为三步：
Step1 找到理想态
定义理想态，并以数字化的指标或其他明确标准来衡量。
Step2 抽样分析
将所有不到理想态的case抽样分析，并做统计分类，明确满足不好的原因。
Step3 优先级判断
汇总所有问题，综合影响面、问题严重程度和解决成本确定优先级，作为接下来的项目计划。
正文：
阶段性调研第三步：优先级判断
得到现状的问题集合后，需要进一步给出优先级判断，确定接下来的项目计划。
1.单位成本下的项目收益
按照【单位成本下的收益】从大到小排序。
单位成本下的收益（简称ROI）=项目收益/项目成本
注意点1：
如果出现ROI相同的多个项目，通常情况下绝对收益较高的项目优先级较高
【10天拿到10点收益的项目】>【2天拿到2点收益的项目】
注意点2：
外部环境瞬息万变，很难保证200天后项目依然能拿到对应收益，从期望值来说，20天的项目更稳妥。
【20天拿到20点收益的项目】>【200天拿到200点收益的项目】
注意点3
存在一些紧急项目，因为待解决问题的恶劣程度较高，优先级高于其他常规项目。
2.ROI计算
1）项目收益=待解决问题的影响面*解决后的体验提升程度*预期解决比例
待解决问题的影响面：通过调研得到直接的统计数据
解决后的体验提升程度：通过调研得到，由于该问题导致的【实际数据指标与理想态指标的差距】
预期解决比例：通常由研发给出
2）项目成本=通常仅指研发成本
3.优先级判断的工作流程
课程截图
4.总结
优先级判断是阶段性调研的最后一步，直接决定后续的产品计划。
进行优先级判断时，在关注项目成本和收益之外，pm要灵活应对外部环境的变化，综合决策。
2.4 【实例】滴滴叫车成交率阶段性调研
阶段性调研的方法分为三步：
Step1 找到理想态
定义理想态，并以数字化的指标或其他明确标准来衡量。
Step2 抽样分析
将所有不到理想态的case抽样分析，并做统计分类，明确满足不好的原因。
Step3 优先级判断
汇总所有问题，综合影响面、问题严重程度和解决成本确定优先级，作为接下来的项目计划。
评估对象：滴滴打车的叫车成功率
第一步：理想态的定义
理想态定义：用户发出需求后有司机应答并将其送至目的地
核心指标及拆解：成交率是核心指标
第二步：
未成交的情况：
课程截图
将不到理想态的case抽样分析：
课程截图
第三步：优先级判断
课程截图
2.4【实例】百度搜索结果阶段性调研
阶段性调研的方法分为三步：
Step1 找到理想态
定义理想态，并以数字化的指标或其他明确标准来衡量。
Step2 抽样分析
将所有不到理想态的case抽样分析，并做统计分类，明确满足不好的原因。
Step3 优先级判断
汇总所有问题，综合影响面、问题严重程度和解决成本确定优先级，作为接下来的项目计划。
评估对象：百度搜索结果的效果
第一步：理想态的定义
理想态定义：用户以最低成本找到了想要的东西
核心指标及拆解：什么情况下用户确实得到了满足，以什么指标衡量
得到满足的情况：
1）用户没有点击行为，需求可以通过结果摘要得到满足，同时无后续变更搜索词或切换tab等行为。
2）用户点击了1条可以满足需求的搜索结果，同时无后续行为。
第二步：抽样分析
随机抽取一天中的5k个session，分析其搜索结果满足程度 。
课程截图
分析未满足情况：
1.用户没有点击行为、或点击1条或多条结果，但是没有满足：
1）提示无结果、占比4%
query解析出现问题、未收录合适结果
2）相关性太差、占比11%
query解析出现问题
2.点击多条结果才满足：
1）最佳结果未rank到第一位、占比37%
基础赋权出现问题
3.变更query重新搜索：
1）原query的解析出现问题、占比28%
2）原query下的需求扩展不够、占比17%
4.点击图片/地图tab：
1）原query有图片/地图需求，query需求识别未包含该需求分类、占比3%
第三步：优先级判断
总结
阶段性调研后，产出的分析结论最能代表产品问题全貌，可以有效指导下阶段的产品计划。
第二章结束，下面是第三章
网友评论