6.1.1 策略产品经理的“术”

6.1.1　策略产品经理的“术”

2.4节介绍了部分关于策略产品经理应掌握的“道”，但在工作中只知道关于价值观和行事准则层面的“道”是不够的，在做事的战术上也应该了解一些需要遵循的准则。图6-2是笔者工作中总结的经验，供大家参考。

图6-2　策略产品经理的“术”

●最小产品原则：如果你想做一个图片分享网站，第一步或许只是一张图片的展示，经过一系列实践才完成正式版网站开发。

●追求规模效应：对于一些有容忍度的项目，可以“先污染后治理”，先将“盘子”做起来，再利用规模效应实现飞速增长，非主流程的体验细节可以之后再完善。

●策略做粗：策略做粗是追求简单可依赖，给模型留足空间。

●特征做细：将特征做细是为了模型训练后使效果更好。

●正则为王：工业上的分类器，正则表达式策略在大多数情况下性价比更高。

●先解决上游的问题：对于有上下游关系的策略耦合，一定优先实现上游策略。

●决策时始终紧盯目标：永远先估算目标指标天花板是多少。路径拆解后，估算每个ROI是多少。

下面详述这几条准则。

1.最小产品原则

最小产品原则也称MVP原则。这里重点说说最小产品原则在B端产品和C端产品的差别。

B端产品大多数时候无法遵循最小产品原则，因为企业的定位用户是付费用户，需要整体服务的交付。比如卖一个软件系统不能第一周只卖给对方一个空壳，第二周再逐步完善其中的功能，那样只会让B端客户流失。

对于C端产品，一部分策略产品经理往往会一口气提出大量完整的策略需求，但以笔者的经验看，往往这种完整的策略需求是不具有实操性的，原因如下。

●结果的改变往往也是遵循“二八原则”的，绝大多数的策略并不会有非常明显的作用，往往是1到2条“拳头策略”可以带来显著的效果提升。

●完整的策略设计是不被需要的，实际工作中存在着大量非主干的流程策略，这种完整的策略设计需求在项目早期不需要在需求文档中体现，但策略产品经理心中要有关于后续策略的设计方案。

真正重要的是要让项目快速地跑起来，对于策略产品而言，大多数后端迭代是不需要发版的，所以可以实现更短周期的迭代频率。

2.追求“规模效应”，需要“先污染后治理”

产品初期通常有两种对应观点存在，一种认为应该把大多数事情做好才能进行下一步，另一种提倡在保证基本质量的前提下尽量追求速度。以笔者的经验看，在质量和速度中存在着一种最佳的动态平衡。早期工作中部分运营同事对许多未修复的体验细节抱怨，但产品技术团队仍然在快速探索新业务和建立更强大的中台系统。那么，应该如何处理“由于快速发展带来的体验细节”呢？

从事后的经验看，“先污染后治理”是一种大多数情况下正确的思路，原因有两个。

●在产品探索期，产品的最终形态没有确认，此时最重要的是迭代速度而非质量，需要快速验证用户的行为是否符合预期。过去项目中的待修复细节可能会受新的产品策略影响，在未来被忽略。

●在产品探索期，需要追求的是“规模效应”，在小范围内实现的需求无法快速触达大规模人群。所以对于初创企业而言，要努力抓住“规模效应”的临界点，这时候需要的是更快的开发速度。迅速达到规模化的临界点是非常重要的。

但要注意的是，并非所有的项目都可以接受“先污染后治理”，需要两个必要条件：“To C产品”和“可容忍负例”。事实上，大多数策略相关的需求均满足该条件（至少笔者亲身经历的项目如此）。

3.策略做粗

部分新入行的策略产品经理往往会犯一个错误，容易陷入自我价值的怀疑之中，容易在与算法团队的沟通配合上处于两个极端。

●作为算法团队的从属职位。团队风格呈现出偏技术导向。策略产品经理负责配合研发的需求而开展一些细节工作，比如收集标注数据、召开会议等偏技术的日常工作。

●作为算法团队的强势需求方，在每周的算法团队的周计划排期会上提出大量精细策略需求，这给算法团队带来了大量的策略开发工作量，但带来的线上效果往往又不理想。

事实上，这两种情况并不罕见，那应该和算法团队如何配合呢？如何避免成为算法团队的“附庸”？

笔者的经验是策略方案要做粗粒度的可复用策略，策略设计的要点在于策略的“粒度”和“可复用”。百度有一条价值观叫作“简单可依赖”。这句话放在策略设计上也合理。策略设计应该站在用户的视角上，作为功能型产品和算法团队的连接点，为达到目标最大化（包括可测指标和不可测指标）而平衡各方的策略，达成妥协。

（1）关于策略方案的粒度问题

这里只是简单说明。策略是对模型结果极端情况的补充，客观世界中数据是稀疏的，在特定情况下（比如数据不充足、不准确）模型难以得到令人满意的结果，比如漫画产品中的相关推荐页面。一些情况下为了服从产品的顶层设计（换言之为“高层意志”），需要出现强可解释性的推荐结果，这种情况下算法策略设计不能遵循模型导向，而要遵循产品顶层设计，本质上是为了达成不可测指标的最大化。

但是在一些情况下，比如内容型产品的新用户冷启动策略设计中，部分策略产品经理会设计大量非必要的人工规则（必要的规则需要策略产品经理自行判断）。还是以漫画产品为例，目标是提升新用户首次启动App的推荐效率，部分策略产品经理可能会制定如下细致策略。

●对于填写了年龄的、15岁以下的男性用户的前xx位推荐作品A、作品B、作品C……

●对于填写了年龄的、15岁以下的女性用户的前xx位推荐作品E、作品F、作品G……

●对于X省份的、未填写年龄的女性用户的前xx位推荐作品H、作品I、作品J……

但这样的策略真的是必要的吗？完全不是。

首先有两点关于策略设计的常识需要铭记：一是10%的拳头策略可以达成90%的效果，即效果的达成并非靠策略的堆砌；二是算法需要留出空间来自适应。

笔者的工作经历中，在大多数项目上加的人工规则都会让客观可测指标下跌。模型算出的结果始终是数学上的最优解，若执行了上述罗列非常细致的策略，会产生以下几点问题。

●服务端开发工程师通常需要增加大量的开发工作量。

●在新用户冷启动策略中，如果这些新用户的规则持续保留在线上，则大多数用户看到的都是这几个定制化的作品，那么模型将缺乏充分的用户有效行为数据。换言之，模型很难“学”到用户的真实兴趣，对于推测模型效果的“天花板”是不利的。

●如何保证策略的自适应？如何验证策略是正确的？为什么男性用户一定喜欢作品A而不能喜欢女性向的作品B？策略本身也是不可解释、不可迭代的。

●策略如何维护？如果你对代码开发有一些了解，可以看到开发机中存在着大量陈旧策略。策略的目的、负责人随着业务线变化和入职离职等频繁更迭，留给算法团队的只有大量陈旧的历史策略，缺乏注释，也不敢轻易下线，这大大地增加了后续的算法复杂度。

对于一个项目而言，笔者的经验是在早期加入一些基于先验知识的粗粒度策略，在项目收尾的后期瓶颈期再考虑逐渐加入当时的各种策略。事实上，笔者在三家公司工作中的很大一部分精力花在历史策略池的迭代优化上，这部分工作需要非常规范和高频率的文档。

那什么“粒度”的策略是没问题的呢？在上述例子中，笔者可能会给出这样的策略。

●通过数据分析（比如聚类算法）找到趋同的作品，可以得到“广义人群的作品池”和“主要影响维度”。

●对区分度比较大的影响维度（比如性别）做加权策略。加权策略优点是无级变速的，如对男性用户做某些男性向作品的加权（如加权20%，同时设定加权的退出机制，如“用户两次不点击则取消加权”），不同的加权权重可以通过服务端配置A/B测试实验进行在线测试，选择相对效果最佳的某一种。

●在策略设计时少做或不做定制化策略，在大热作品中掺杂小众兴趣作品，逐渐小步迭代、挖掘用户兴趣，为模型提供充分的数据空间。

在第一种策略设计中，开发工作量由于策略需求减少而大量降低，策略的准确度得到上升。策略的设计是基于数据分析和产品判断的，尽管罗列了所有的用户维度，但事实上只有少数维度对用户兴趣有强区分度。第一种策略缺乏自适应的迭代空间，而第二种策略是可以通过A/B测试实验达到局部最优解的，如果性价比足够高，甚至可以在参数上做多次实验。第二种策略使指标的“天花板”有所提高，对模型来说有效数据的积累是长期收益。

对策略设计而言，有一句俗语叫“少即是多”，企业需要的也并不是能罗列所有规则的策略产品经理，而是有判断力的、能找到拳头策略的策略产品经理。

（2）策略的可复用性

对于这一重要的设计准则，同样举一个信息流产品中的通用策略例子。1.3节介绍过，通用策略中的一个目标是推荐多样性，为了保证用户的浏览体验，需要打散一部分内容。举例来说，在某职场实名社交产品中，需要对用户动态中的发布者按公司打散，这个策略需求有多种表述方式（实现方式）。

●入门策略产品经理：两条同公司的帖子不能连在一起出现。

●初级策略产品经理：如果两条帖子属于同公司，则它们不可以相连出现。

●中级策略产品经理：若发帖人的公司（提供数据库表字段名）相同，在某信息流形态中，连续的2条内容最少出现0条，最多出现1条。

●高级策略产品经理：应该区分软打散还是硬打散，本例属于软打散，在极端情况下可接受同公司的帖子连续出现的情况，所以策略细节为：若发帖人的公司（提供数据库表字段名）相同，在某信息流形态中，如果原始排序列表中存在连续2条内容满足上述情况，第1条内容正常推荐，第2条内容加权0.01，对得分进行重新排序得到最终推荐列表。

这个例子中的重要差别在于4个级别的策略产品经理对于可复用性的表述，入门级和初级策略产品经理的差别主要在于策略文档是否有清晰的逻辑关系。

●入门级的表述是文学化的而非逻辑化的，而初级的表述则是“如果……则……”的逻辑化表述。

●初级和中级的差别在于可复用性和清晰度。对于中级策略产品经理的这一表述，技术人员可以开发出相应的技术模块，比如提供清晰的数据库字段名，避免了双方对字段标识的差异，因为在实际层面公司相同的这个概念可能引申为全文匹配还是包含匹配，如果某人处于子公司而另一人处于母公司，是否也算是公司相同？在技术实现上需要避免含糊不清，所以策略产品经理需要进行通盘考虑，这就需要熟悉数据库表，从而知道数据分布是什么样的。另一方面，中级策略产品经理的表述是具有可复用性的，有类似需求的时候可以套用这个可复用的模板。比如某一次刷新中的频控策略，调整上限（最多x条）是频控策略，调整下限（最少y条）是保底策略。中级策略产品经理的这个可复用的表述是值得推广的，在与算法团队的交流中也会更得心应手。

●中级和高级表达的差别在于是否考虑到了未来的项目复杂度。高级策略产品经理的表述根据目标的容忍度情况将打散策略分为可容忍和不可容忍两类，进而判断需求是否是可容忍的策略，在项目复杂度高的情况下，由于项目中存在着数十条的可容忍打散策略，这些策略之间哪些优先级更高，如果规则冲突优先保证哪条规则生效。高级表述提供的是一种无级变速的实现方式，借由数学加权运算实现不同策略的优先级排序，与前述策略相比更易维护和迭代。

综上所述，策略设计准则中策略的粒度和可复用性是非常重要的，通过策略文档可以看出该策略产品经理的思考深度，而策略文档本身同时反映了产品未来的数据“天花板”。

4.特征做细

前文讲了为何策略产品要把控好策略的粗粒度和可复用性，但策略产品经理也并非是在所有场景下都保持粗放的工作模式，在特征级别需要切得越细越好。

特征做细中的“细”有两层意思：一是维度要多，二是每个维度的粒度要细致准确。

工业级的推荐模型往往对应着数百维的特征（可能需要更高维度的特征），算法工程师的职责包括构建尽可能多的特征训练模型，但由于对特征的管理不足，在大多数情况下只通过构建用户行为数据不足以支撑模型。

那数据从哪儿来？答案是自己“造”。这部分工作对应着1.3节中的内容画像和用户画像，在此不再赘述画像的生成过程。提升模型的召回率和准确率并持续地训练模型，完成算法工程师不擅长“造”数据的过程，是策略产品经理的一项重要工作。

5.正则为王

在学术论文中，我们经常可以看到新的分类器取得了越来越好的数据效果（至少在论文测试集上的结果如此），但大多数情况下，策略产品经理可以仰仗“万能”的分类器吗？很遗憾，答案是不能，至少现在不能。

笔者的从业经历中，在分类领域，正则表达式策略在大多数情况下性价比更高。学术论文中的分类器是实验室的大量数据集结果，或多或少具有统计偏向性，如果将所有命题转换为等价逆否命题重新训练，效果会大打折扣。工业应用与学术应用的两个重要差别可以概括为“时间紧、任务重”。在实际工作中一类方法是有监督学习，但训练的模型往往需要长期投入，不仅需要标注大量样本，标注样本同时还需要保证样本的主观一致性和持续生产，这无形之中增加了几倍的人力投入。另一类方法是无监督学习，当前的模型较两年前有了弥足的进步，但在数据量较小的情况下效果还是较差的。

在这种情况下，往往正则表达式可以产生奇效。正则表达式是通过经验和模式识别得到的归纳规则，有三个优点。

●迭代方便，甚至可以配置为后台，实现小时级迭代。

●对目标的达成见效快，稳准狠，且可以自适应优化。

●正则表达式具有强可解释性。

这三个优点足以让正则表达式成为备受策略产品经理青睐的“法宝”。在数据量较充裕的后期可以逐渐撤掉正则表达式部分，但在紧张的项目周期中，正则表达式承担了非常重要的角色。

6.先解决上游问题

在日常工作中策略产品经理经常遇到一些彼此耦合的线上问题。举个例子，假设你是美团外卖的配送端的策略产品经理，某一天在做数据分析时发现，外卖骑手在北京市某小区送餐时经常超时，超时率比其他临近区域高出了30%，而该小区的运力是充分的。经过排查发现，该小区的地理定位有问题（或者附近在修路，送餐需要绕路），导致模型的预估配送时长过于乐观，而配送员难以按系统规定的配送时间点击“已送达”按钮。

这个问题如何解决？对于这个问题的解法，很重要的一个“术”是注重解决问题的顺序。这个问题是由于POI定位不准导致的模型预估配送时长不准，顺序应该是：对于有上下游关系的策略耦合，一定优先解决上游策略。首先要尝试解决POI定位问题，分析解决POI问题的技术难度有多大，如果实在难以解决才考虑解决模型配送时长不准的问题（比如增加修路工期等限时生效的策略）。

7.始终紧盯目标

做策略产品最重要的是目标导向，策略产品经理需要每天都问问自己：

●今天的工作能否提升最终的目标？

●指标的“天花板”是多少？

●在达成目标的路径中，是否有更好的解决方案？

笔者在工作前两年的项目中经常有这样的情况：有时会钻牛角尖，看不到全局，对于项目的潜力也估计不足。对于某些“钻牛角尖”的项目没有意识到这种手段基本已经到达“天花板”，从而忽视了其他更好的办法。也就是说，缺乏判断力，而这也是年轻策略产品经理的共性问题。

经过反思，笔者认为这种情况的产生主要是两种原因。

●最主要的原因是行动具有“惯性”，不愿意逃离舒适区。即使某些项目在“小步快跑”的迭代中被论证了没有潜力（此结论一般由资深产品经理判断得出），但笔者自身已经适应了项目节奏，由于懒惰而希望继续按惯性做下去，但也会有不甘心的情绪。

●次要的原因是年轻产品经理的“通病”，即缺乏足够的判断力来判断某个项目目标的“天花板”，于是“胡子眉毛一把抓”，把能想到的所有策略都尝试一遍，但这就违反了策略设计“少即是多”的原则。

策略产品经理应该成为一个理性的逻辑思考者，对于判断好的方向敢于尝试，对于效果不佳且判断没有发展潜力的手段敢于中止，将精力投入到其他手段上。