百韵网 >>  正文

策略产品经理 策略工作通用方法论

来源:www.baiyundou.net   日期:较早时间
3.1 策略PRD的撰写方法

一、需求文档

确定项目计划后,PM开始撰写需求,产出需求文档,正式发起项目。

1.需求文档的目的?

让项目的参与方和其他对项目感兴趣的角色更好的理解需求的来龙去脉。

2.一个完整的需求文档应该包括以下几个部分:

项目背景、项目目标、 需求概述、需求详述、 (统计需求、监控需求)

本文主要讲述策略PRD与功能PRD不同的地方:需求概述、需求详述。

二、功能产品与策略产品给出的解决方案

1.功能产品

收敛 的解决方案,通过 流程和原型 表达产品的实现效果

2.策略产品

发散 的解决方案,通过 逻辑描述和效果示例 表达产品实现效果

三、策略产品四要素

课程截图

四、策略分类

1.简单策略

逻辑简单直接的需求,通常开发成本较小

2.复杂策略

逻辑复杂的需求,通常开发成本较大

五、需求描述方法

1.简单策略

PM可以 直接给出策略规则 (包括待解决问题、输入、计算逻辑、输出四要素的部分或全部)

例子:

课程截图

方法:

1)基于历史数据给出 (已有一定数据积累的情况下)

2)参照竞品给出 (多用产品从0到1搭建,没有数据积累的时候)

案例:

课程截图

为什么是3分钟?

首先明确产品目标和策略目标

【输入密码】产品的目标:保障安全性,同时不影响用户的正常操作体验

【输入密码间隔】策略的目标:找到那个不影响体验的最短时间间隔

如何利用基于历史数据和参照竞品的方法确定策略规则?

1)基于历史数据

课程截图

定义完整使用流程

抽样分析用户全天的行为记录,得到一次完整使用流程的定义:任意两个动作间间隔小于30分钟的动作序列。(人工分析判断)

统计流程中间隔

课程截图

找到目标间隔时间

课程截图

2)参照竞品

经过多次重复尝试,确认竞品定义了超过3分钟用户就要再次输入密码,那自己的产品也可以暂定为3分钟

2.复杂策略

PM详细描述解决问题、输入因素、输出效果,包括总结性的概述和示例case(来源于问题调研)。

计算逻辑由策略RD开发实现。

实际工作中的两类项目:

1)从0到1的项目:更多描述理想态,在怎样的输入下要达到怎样的输出效果

2)策略迭代的项目:更多描述策略现状,待解决的问题是什么,针对这些问题,理想的输出效果该怎样的。

案例1:

课程截图

需求描述: 待解决问题

需求详述:

输入因素和输出效果的概述

各类特殊情况下的计算逻辑补充

输入因素和输出效果的详述(case示例)

例子:

课程截图

课程截图

案例2:

课程截图

课程截图

六、需求文档自检清单

结构: 逻辑清晰,层次分明

背景: 需求背景描述清晰,待解决问题一目了然

目标: 产品理想态或考核指标是什么

示例: 通过示例辅助,让问题更明确和清晰

七、总结

策略需求文档的核心是将策略的四要素描述清楚。

其中针对复杂策略,可以跳过计算逻辑这个要素,但是需要通过具体的case示例将问题和产品实现效果更清晰地表达出来。

3.2策略PM如何跟进开发评估

一、策略类项目的流程

课程流程

二、为什么要做多轮评估?

课程截图

三、评估类型

课程截图

四、策略质量评估

策略质量评估用来说明 策略本身的质量

输出结论: 该策略的召回率和准确率

1)召回率=希望被覆盖的案例中,策略实际覆盖到的案例/理想态下希望策略覆盖到的案例

代表策略对问题的解决程度

2)准确率=策略覆盖的案例中,真正希望被覆盖到的/策略覆盖的所有案例

代表策略有没有带来其他伤害

(我们希望两者越高越好!)

例子:

课程截图

以上例子中,

召回率=6/10=60%

准确率=6/9=66.7%

策略质量评估方法:

课程截图

案例:性别识别策略

在所有用户中随机抽取1k人,通过策略识别,其中368个人为男生。对1k个人进行人工标注,共标注385个男生、78个无法识别,剩余女生。其中策略识别为男生的对象中有314个真的为男生、22个是人工标注的无法识别,策略识别成女生的里面还有71个是男生,那么:

召回率 =识别出的男生314/所有男生385=81.6%

准确率 =(真正的男生314+无法识别22)/策略识别的所有男生368=91.3%

(注意这里的无法识别问题)

五、Diff评估

在一个复杂的策略体系中,各种策略会相互作用,共同影响最终效果,比如搜索、推荐。

在迭代其中某条策略时,除了评估策略本身的召回和准确,还要关注在策略变化前后, 用户角度直接感受到的产品效果变化是怎样的。

输出结论: diff影响面、good:same:bad

1) diff影响面: 策略调整后,用户感知发生变化的比例,通常小于策略影响面

2) good:same:bad(简称g:s:b): 随机抽样有变化的case,站在用户体验角度评估效果变好了、无变化、还是变差了。

例子:

课程截图

Diff评估方法:

课程截图

案例:性别识别策略

在所有用户中随机抽取1k个人,新旧策略分别识别后,有210个结果不同。98个新策略男、旧策略女,112个新策略女、旧策略男。

对这210个结果进行人工标注,其中135个是新策略对、旧策略错,24个新策略错、旧策略对,还有51个人工判断不出性别,认为新旧策略识别是男是女都可以、新旧变化为same,那么:

diff影响面: 新旧结果不同的210/所有样本1000=21%

G:S:B= 135:51:24

六、策略评估三步方法论

策略PM通用方法论

课程截图

第一步:基于理想态,找到问题

策略召回率理想是100%,目前只有60%,剩余40%没被策略召回

策略diff评估中占比10%的bad case

第二步:汇总和抽象问题,提出解决问题思路or方向

40%未召回case主要是3类问题,分别应该通过xxx思路解决

目前占比10%的bad case主要是xxx原因,需要解决

第三步:给出结论

问题依然很严重,需要继续优化or问题可接受、策略可以上线了

老问题:以投入产出比为主要考虑因素,通常以项目预期为终点

新问题:通常容忍度较低。以pm认为的不可忍受的体验为标准

七、简单策略评估循环的案例

课程截图

课程截图

课程截图

项目目标:准确识别出图中的蓝色点

第一轮评估:

第一步:基于理想态,找到问题

绿圈里的蓝点没有被曲线覆盖

错误覆盖了红圈里的两个点

第二步:汇总和抽象问题,提出解决问题or思路

1、2的点在曲线上方,3在下方,至少是2次函数

1和2的斜率不一样,可能是3次或更复杂函数

第三步:给出结论

目前方案只能勉强覆盖三个点、召回率不到30%;

准确率也一般,召回了两个绿点,准确率只有60%。

还需要继续优化。

课程截图

课程截图

第二轮评估:

第一步:基于理想态,找到问题

圈2里还有一个点没有召回

第二步:汇总和抽象问题,提出解决问题or思路

之前提过的呀,1和2的斜率不一样,可能是3次或更复杂函数,用2次函数搞不定的

第三步:给出结论

其实目前召回率已经90%+了,准确也非常好。可以上线了。

不过如果成本可控的话,再努力下最后一个点?

第三轮评估:

课程截图

八、总结

开发过程中的评估是策略PM的必经之路,是PM和RD通过深度配合在黑暗中找到道路的重要环节。

召回率、准确率、diff影响面、g:s:b四个指标是策略评估的主心骨,所有评估都是围绕着他们发现和抽象问题的过程。

3.3策略PM如何做效果回归

课程截图

效果回归作为策略产品工作循环的最后一步,不仅仅是结束,更是新产品问题的开始。

一、什么是效果回归?

无非是要回答三个问题:

课程绩图

二、如何做效果回归呢?

也是用到了策略工作的基础方法论

课程绩图

效果回归五步法:

第一步:明确预期:产品/项目目标是什么

第二步:指标体系:该目标可以用哪些数据指标来衡量

第三步:确定上线方式

第四步:收集第二步的指标,看是否达到第一步的预期

第五步:分析问题,产出结论

1.项目启动前

课程绩图

建立指标体系

回答三个问题

1)问题和目标是什么: 找到核心指标

2)解决问题和实现目标的关键路径是什么: 找到过程指标

3)新的路径伤害了谁: 找到观察指标

2.开发上线

课程截图

1)全流量上线

如果核心/过程/观察指标仅与本项目有关,评估效果很好、希望尽快上线拿到收益时,可选择全流量上线

回归方法: 实验期同比上个时间周期,变化了xx%

2)小流量上线

如果核心/过程/观察指标变化可能受项目外的因素影响,或者项目效果存在一定不确定性时,尽量选择AB test

回归方法: 实验流量比基线流量,变化了xx%

注意:

抽样方法是否足够随机。

样本集合是否有天然差异。

先进行流量空跑,避免问题。

3.上线后

课程截图

课程截图

三、效果回归案例

课程截图

1.项目启动前指标拆分

1)核心指标

产品目标: 降低用户输入成本

核心指标: 用户输入时间,预期降低2秒

2)过程指标

课程截图

用户输入效率的影响因素:sug展现的比例,在哪个输入长度下展现,是否被用户点击

过程指标: sug展现率、平均输入长度、sug点击率

3)观察指标

sug改动对输入流程的影响是可控的,对输入后搜索体验的影响是不确定的。

(某种程度上,sug起到了推荐的作用)

观察指标: sug输入query的搜索结果满足度

2.开发上线

选择上线方式

小流量上线: 实验组、对照组各10%流量

3.上线后回归

核心指标: 降低了1.2秒。有收益,但是低于预期。

过程指标和观察指标:

平均输入长度变短,符合预期;

sug展现率变低,点击率没变化,与预期不符;

并且sug输入query的搜索满足度降低,用户体验差。

需要进一步分析问题!

分析后结论:

1)性能有问题,导致长词汇(多term)sug的加载过慢,拉低了平均展现率和使用率。

需要启动性能优化项目

2)在一些热门候选词上做了需求扩展(欢乐颂2剧情介绍),对应的搜索结果质量变差

需要联合搜索排序(基础rank)部门优化效果

四、总结

效果回归是决定一个产品循环终止或再开始的枢纽。

整个工作贯穿项目前后三个阶段;项目启动前 对策略目标和过程的深刻剖析 是效果回归工作最关键和重要的部分。

【消息推送策略】的产生、演化、发展——以京东到家为例

课程截图

以一个小的策略为例,看看在完整的产品循环下策略的通用方法论是如何应用的—— 京东到家的消息推送策略 。

首先回顾下 策略工作的通用方法论

课程截图

理解产品目标

产品目标: 通过消息出大用户,实现相应的转化目的

核心指标: 消息点击率

注意:

本案例中覆盖的消息 仅指活动类消息 ,不包括各类业务消息(比如订单发货、退款、订阅更新等业务环节的提醒)

版本0.0:人工推送

产品方案: 运营同学写好文案,通过简易的消息推送工具给全部注册用户发送消息

推送效果: 点击率只有0.5%

发现问题

采用 阶段性调研 的方法

课程截图

问题分析

理想态: 所有人都点击

未达理想态: 有99.5%的人都没有点击,怎么拆解?

PM对用户的理解还较少,提出新的分析思路: 反向看点击的人,对比点击的人和没点击的人有什么差异,试着分析其中的规律

课程截图

进一步分析:

1)这次推送对活跃用户的效果更好,点击率大概7.4%,非活跃用户只有0.1%。虽然预期会有差异,但是差距太大,需要试着优化针对不活跃用户的推送内容

2)活跃用户中,android点击率23%、iphone用户点击率3.5%。差异非常大,不符合认知,猜测可能大量iphone关掉了app推送

版本1.0:增加基于用户分层的推送

产品方案:

1)基于用户基础信息和历史行为挖掘用户标签:活跃程度、手机平台

2)运营可根据标签配置不同的文案和推通道

3)增加短信推送通道

课程截图

推送规则: iphone增加短信通道一起推送,android仅进行app推送

效果回归

推送效果: 点击率提升至1.5%

1)活跃用户点击率提升至11%,其他用户点击率0.5%,都提升明显

2)iphone点击率0.7%,android用户点击率2.4%,iphone转化率依然不高

结论: 短信通道的效果不好,需要分析问题。另外,可以进一步分析其他待优化点。

问题分析

首先分析短信通道问题,发现:

1)app中没有埋点,所以点击短信短连接后无法调起app

2)而且短信中的短连接没有加统计标识,打开的移动端网页不知道这是短信带来的流量

然后对没有点击的个用户群各自抽样分析,发现:

1)没有点击的用户都是曾经很少买或没有买过肉蛋奶类商品的用户。在活跃用户中表现尤其显著。

2)同时补充抽样点击用户,发现86%的用户都有>2个包含该品类的订单

——可以考虑更细化的推送内容

版本2.0:个性化的内容推送

产品方案:

1)收集更多用户历史行为(订单、收藏、搜索、浏览等),建立更加细化的用户标签,用于内容推荐

2)收集平台商品上架和价格等信息的变化和常规活动信息,作为待推送内容集合

3)根据用户标签和候选内容,生成基于每个用户兴趣的内容

4)设置推送频率限制,在允许频率内,当某用户存在可推送内容时,自动进行推送

此时,运营同学只需要配置各类兴趣维度的模板,系统自动发起推送。

课程截图

课程截图

效果回归

推送效果: 点击率提升至2.5%

1)iphone点击率2.1%,android用户点击率2.6%,两者非常接近了,符合预期

2)优化内容后,各类用户的点击率均有可以明显提示

结论: 比较符合预期,可以进一步分析其他待优化点

继续对比点击和未点击用户差异,并随机抽取用户详细分析,发现:

1)各推荐维度在不同品类上有不同表现

2)不同用户对同一种推荐维度的点击率也差异很大

3)同一用户在不同时间段的点击率有比较明显的差异

——可以在推荐特征中增加品类和用户历史点击数据;可以将推送时间纳入个性化推荐

版本3.0:基于反馈的推荐系统

产品方案:

1)将推送时间纳入推送控制

2)继续丰富推荐使用的标签数据

3)将每个用户的点击行为作为推荐优化的重要依据,不停迭代

课程截图

总结

消息推送的效率本质: 给合适的用户在合适的时间点发送合适的消息

【合适】最初由PM定义,最终根据数据反馈确定

课程截图

在这个完整的案例中,产品一步步进化,从功能到策略、从简单策略到复杂策略,我们依次优化了消息推送的四个要素,达到了相对理想的状态。

在这个过程中,我们仅 以问题驱动 ,并加入了 优先级判断 的分析。

而在实际项目中,限于 成本收益和平台数据的积累程度 ,很多消息推送策略停留在1.0或2.0版本即中止进化了。

【实例】策略工作通用方法论的应用——以滴滴APP的目的地输入模块为例

课程截图

以一个复杂的策略模块为例,看看在完整的产品循环下策略的通用方法论是如何应用的。——滴滴APP的目的地输入模块

策略工作的通用方法论

课程截图

理解产品目标

模块目的: 帮助用户以最低成本完成目的地的输入

衡量指标: 用户平均输入时长(从进入该模块到完成一次输入的平均耗时)

版本1.0:简易搜索

课程截图

课程截图

发现问题

使用阶段性调研的方法:

课程截图

1.0问题分析

课程截图

课程截图

理想态: 可以暂且定为2,【点击目的地框——>点击历史记录】两步

问题拆分: 主要目标34567向2努力,次要目标每个步长都缩短自己的平均时间

随机抽取 一周内 (滴滴有周末效应,POI不同)的用户 完成输入 的session共1000个,问题分析结论如下:

课程截图

搜索sug-过程指标

用户输入效率的影响因素: sug展现的比例,在哪个输入长度下展现,是否被用户点击

过程指标: sug展现率、平均输入长度、sug点击率

解决方案

针对以上各个问题,分别提出解决方案

课程截图

方案收益分析

针对各个解决方案,与RD一起分析可行性后得到项目预期收益

课程截图

产出项目计划

最终得到下个版本的项目计划如下:

课程截图

版本2.0:【搜索建议】+【搜索推荐】

课程截图

课程截图

2.0效果回归

让我们看一下项目上线后,每个问题的解决程度

课程截图

2.0问题分析

针对两个明显与预期不符的问题进行分析

问题1:步长2的输入时间没有按预期降低:

1)部分低频用户数据积累不够,导致排序出现不合理波动,排序策略需要微调;

2)以及随着数据积累整体效果会逐渐变好。

问题2:步长3的用户目的地已在历史记录中:

1)发现在网络不佳的情况下【搜索推荐】加载过慢,所以用户使用低于预期。

2)考虑在启动app时进行预加载

2.0问题进一步分析-还有没有可能更好

课程截图

理想态有没有可能是1,甚至是0?

步长2: 其中50%是非常有规律的通勤订单(基于出发地和出发时间段可以准确预测出目的地)

步长3: 其中20%是有规律的订单

——完全可以考虑把【搜索推荐】的结果前置到发单页!

版本3.0项目计划

综合效果回归的结论,与RD沟通可行性之后,3.0的项目计划如下:

课程截图

目的地推荐(高准确率的【搜索推荐】前置)+【搜索推荐】+【搜索建议】

课程截图

搜索输入策略框架的延伸

1.百度地图APP

搜索起始页

1)搜索框在首页上方,是空白的,没有很多推荐内容,只有一个用户教育的提示

2)在页面中间,表示当前位置的蓝点上有个“回家”的提示,点击之后可以直接发起回家路线的搜索

输入页

~

相关要点总结:
(编辑:本站网友)
相关推荐
关于我们 | 客户服务 | 服务条款 | 联系我们 | 免责声明 | 网站地图
@ 百韵网