聊一聊策略产品化思维？
为什么要聊这个话题？
起因是最近我发现一个现象，团队的小伙伴在输出策略方案的时候，很容易陷入一种的怪圈：优化策略直接去看逻辑是否有漏洞，而当优化逻辑的时候则复杂即正确，牛逼即效果好。
很奇怪。
这种思路已经脱离了一个做产品经理的的思考方式。
如果在面试的时候问大家怎么去做一款产品？
相信每个产品经理脑海中都会浮现出一个相对完整的流程：规划，调研，分析，方案，落地，到最终上线迭代。做产品需要看业务，看用户，看场景等等。
但是，当让他们做策略的时候，却没有了这样的一个思路，不会做了。
其实，策略从形态上来讲没有固定的形式，但是策略的本质其实就是一个解决问题的方案，只不过相比C和B端产品来说，策略更多的时候是基于大量的数据去输出方案，而最终他们都是为了解决业务问题，带来业务指标收益。
所以，做策略也需要产品化的思维。一个策略从提出的落地，你之前做产品流程同样不会少。下面我之前画的一个做策略流程图，目前看来基本还算适用：
什么是策略产品化思维？简单来说，就是做策略同样需要产品化的思路去执行，要把一个策略当做一个完整的产品需求去做，哪怕是一个很小的优化。
如何去塑造这种产品思维？在我看来，你可以在工作和学习当中去刻意练习下面几点：
一、做策略必做数据前置分析
通常情况下我们做产品调研主要集中在用户，行业以及业务这三个方向上，但是，对于策略需求更重要的是需要进行数据调研。重点关注以下几个方面：
1. 数据现状以及预期提升值。了解当前指标现状，明确策略上线后的ROI，制定核心指标用于后续迭代依据。同时通过影响流量大小及过往项目经验判断本次策略需求的预期提升值。同时，我也在训练营多次提到预期提升值跟AB测试的关系。
2. 策略需求覆盖范围及影响面判断。策略需求相比其他C和B的需求，他是比较难以直接进行定位到某些具体的场景的具体case。比如优化一个排序策略，你是很难判断到底策略上线后的排序效果是什么样，但是你需要去预判策略影响的范围并且进行提前测试。比如GSB。
3. 数据能够支持策略落地。这是一个非常容易忽视的环节。有很多策略产品同学想到解决方案就可以需求推荐流程：写方案，做评审，等到开发的时候发现这里缺数据，哪里缺数据，造成需求的延期。
在策略产品的实施过程中，我们一般主要关注用户，物品，事件相关的数据是否都具备，且可进行分析处理。策略在具体的落地过程中实际就是一个数据工程化逻辑的实现，而保证数据质量的最主要的手段就是高质量的数据采集能力。
二、策略需要关注业务背景
策略是在某个业务场景下，来解决某个问题的方案，因此在产出策略要以解决业务问题为前提。这是最直接，也是最重要的一个环节。
但是，现实情况是，很多策略产品经理在输出策略方案时候更关注这次策略优化了是什么算法，增加了什么逻辑，而不是解决了什么问题，能解决多少。
在很多人的潜意识当中，觉得没用算法的策略不会起到好的效果，所以，策略方案的输出都以是否采用复杂的逻辑，牛逼的模型作为是否能产出效果的必要条件。
但是，好的策略不一定就等于高大上的算法。还是那句话：撇开业务谈策略都是无源之水，好的策略一定是基于把当前的业务问题，用户预期都定义清楚之后产出的。
在做一个策略之前重点思考以下几个方面：
1.策略解决的业务问题是什么？包括业务指标，业务需求等
2.当前场景下的用户预期是什么？也就是用户在这个场景下想要看到的是什么样的结果
3.当前的方案产生的结果能够满足多大部分的情况。
三、策略需要关注影响面
在很多公司，尤其大厂，策略部门通常是以中台的形式存在，也就是意味着策略通常来说都是支持多种业务的，尤其类似搜索推荐这种，必然是一个综合流量分发的场景。
所以，这个时候每当上线一个策略通常都需要考虑其影响面，一般需要关注如下几个：
1. 业务范围界定。做策略之前需要明确本次策略的业务生效范围，很多时候我们的策略都是针对某个，或者某几个策略生效的。假如范围界定出现错误，那么会导致策略上线后发生异常情况。
2. 关联环节的影响。类似搜索，推荐系统涉及到的环节很多，而且都是环环相扣的，所以当你对其中某个环节的策略进行优化的时候，需要同时考量对其他环节的影响。比如你需要再意图识别环节增加一些同义词，那么你需要考量新增的同义词会不会对其他正在使用意图接口的环节产生影响；同时，新增的排序特征是否仅适合当前场景，但是其他场景不会使用。
3. 策略业务目标预估。如何估计一个策略能给当前的业务指标带来多大的收益。可以按照下面的思路进行展开？
· 策略影响的流量范围确定
· 当前策略核心指标现在确定
· 计算可能带来的收益
以上，就是在做策略过程当中需要考虑的点，我把它叫做产品化思维的点在于：大家做策略的时候不要把它狭义的理解为就是做逻辑的优化，而是就像你在做一个完整的产品，这样你的策略可能会是一个比较“好”的策略。
作者： 夏唬人
