策略产品在工作中如何与算法、运营、研发实现高效合作，进而建立岗位的长效核心壁垒？关于这一问题，作者做了解答，一起来看看吧。

作为开年第一篇想给大家分享一下被高频问到的问题，今天的内容与策略关联度不大，文章理解强度可放心食用。主要想讲讲关于策略产品工作当中的——怎么和算法、运营、研发实现高效合作，建立岗位的长效核心壁垒。

这也是很多Arthur读者困惑的问题，“难倒了解清楚搜广推召回、排序策略就可以建立壁垒了吗”，“卷一卷算法就能高工资了吗”，那怎么和运营、研发合作呢，策略产品岗位的优势究竟在哪里呢？

带这个问题请大家拿好小桌板和笔记本，Arthur老师小课堂开课，Arthur把过往5年多的一些工作思考沉淀总结出来分享给到大家去做参考，同时也欢迎大家讨论。

一、策略产品的核心主线

首先，策略产品诞生背景所需要的技术能力栈并不是本文期望讨论的点，Arthur已经写过非常多的文章进行介绍了，既然是产品经理那我们也用最通俗易懂的方式给到策略产品进行定位说明，我们需要通过这个定位说明来延伸，交代清楚策略产品的工作边界，以及通过边界怎么和其他岗位的合作。

策略产品定义：明确核心业务目标建模/目标构建，在一定的约束条件限定下，通过规则或者是模型的方式设计相应的产品能力，以达成业务目标的产品经理岗位。

这里需要额外强调一下业务场景目标的点，很多投身策略产品岗位的同学都会对算法/模型一类“魅”，觉得懂算法是策略产品致胜的关键，这句话也对也不对，这个是策略产品的重要能力，而不是关键点。

第一个点，可以看到Arthur给到的定义——明确业务目标建模/目标构建，具体业务才是策略产品的生命线，而所有的规则和模型都只是为了达成业务（公司商业化指标）的过程工具，以推荐为例换言之我们所有的模型离线过程指标推AUC、精准率、准确率、F1-Score最终都是为了线上业务指标CTR、下拉深度等商业化业务指标服务，最终的落脚点还是公司商业化效果的提升。

第二个点，为什么提到一定的约束条件，所有的策略设计都会带有一定的约束项，这个约束可能来自于线上的计算资源或者消息qps约束。有可能来自于平台物料客观的限制（例如召回物料类型的单一性），同时也有可能来自于广告主日预算上限的控制，如下图1-1所示。

这些都是需要策略产品在设计业务目标建模和产品方案的时候需要考虑到的点，在设计产品方案的时候脚踏实地的出发点，如何有限资源集合中最大化资源效率，提高单位效率，非常类似背包算法的构建，这也是策略产品需要着重建设的点。

图1-1 广告排序当中收到来自计划预算约束

第三个点，通过规则或者模型的方式设计对应的产品能力，很多同学在浅显了解完策略产品的工作之后，觉得只有用到非常复杂网络的模型才是真正的策略产品，这个认知也过于流表面。并不是使用规则实现目标建模就不是策略产品。

其实前面多次强调无论是模型还是规则都只是达成业务目标的手段，很多预估当年库存调度/销量都回用年同比规则、时序预测的方法进行融合，这一类也是策略产品。只是说模型在样本充足的前提下个性化效果更好，更加准确，并不是绝对的最优。样本数量偏少的情况下，我们就需要前期通过规则的方式完成“样本的原始财富”积累，以便于后续通过模型的方式实现更好的效果。

总结：Arthur说完以上三点是不是大家对策略产品的定位和战略边界有一定认知了，基础技能与业务的术层面Arthur写过太多文章了，包括还有策略产品思维相关的文章。如果说基础技能和思维方式是写给大家关于提高武力的招数，那么对于策略产品定义和明确方向就是术的层面，是武功心法，只有真正清楚策略产品做什么，怎么给公司带来业务价值的提升，才能真正达成策略产品的持久战。

二、策略产品与业务方合作的方法

和各业务方合作的方法，对于算法和运营部分Arthur结合工作合作流程详细的讲解一下需要注意的核心点以及梳理清楚详细的工作流程，对于和研发还有数据的工作就简单概述一下，主要是帮助大家梳理正确的业务合作意识，从而提高自己合作的效率以及工作结果的产出。

1. 策略产品与算法的合作

策略产品和算法合作相信是大家最为头疼的一个合作场景，从很多咨询沟通的同学都有和算法合作沟通大大小小的问题，这里枚举几个涉世未深的策略产品常见的场景。

• 第一种，算法的打工人，样本标注师、特征工程数据清洗处理大师。看似接触了模型相关的工作，却脱离了产品的实际，为了了解模型而去了解模型，成为脱离业务给算法打工的下手，当然接触样本标注、特征工程数据处理事策略产品的重要工作之一，完全脱离业务投入在模型的细节工作当中容易让策略产品快速对岗位失去兴趣和信心。
• 第二种，算法与业务传话筒与报信人，即没那么懂业务更没那么懂模型，甚至连业务都一知半解。纯粹中间传递，岗位作用堪称“鸡肋”食之无味弃之可惜，长此以往被人看出半吊子水平，直接工作被绕过。无论算法、运营给出的工作信任度极低。
• 第三种，纯粹的Copy产品，这里Arthur用了纯粹，光顾着看业界头部的论文、宣传文，拿来主义的就给算法说“我要实现，具体怎么做我不管”，去了解和学习竞品是策略产品的重要信息渠道和来源，类似火影忍者的纯粹的Copy技能，不谈和公司业务场景的结合，不谈收益背景的预期推演，这一类策略产品实际业务当中毫无工作价值，属于岗位可有可无的存在。

如果期望能够真正做到和算法高效合作，和衷共济，培养出来长期合作的信任感，Arthur觉得浓缩就是两个词语：战略清晰 和 能打胜仗。这两个词是Arhthur合作超过上百个算法得出的核心结论，不僭越他人的工作，“能他人之不能”就是和算法合作的最好方法。

策略产品能算法之不能的核心点就在于对于业务痛点的深刻分析与剖析，对于集团业务方向的把控（例如业务目标究竟按照什么来建模、集团推荐系统目标的战略究竟是点击率还是下拉深度一或者是GMV），算法并不需要你太过细致的去干预选什么排序、召回模型（究竟用LR还是GBDT+LR）。多建立自己在合作算法之间的影响力和信任感，带领他们多做出业务产出，达成算法和产品晋升的双赢才是最重要，至于如何建立我们细说。

第一个方面，业务场景机会点科学分析&行业调研：

首先，在和算法做需求评审当中需要做需求背景的交代，这个是Arthur认为PRD当中最重要的部分，无论是用于汇报还是用于和算法业务评审，背景是交代策略需求的痛点业务问题/发展方向/业务增长点。所以需要格外重视需求背景部分，强调清楚做该策略来源，预计提升的核心业务指标，模型指标只是过程辅助性指标，数据预演一定要有逻辑性与科学性切忌盲排。

其次，要做清楚的行业调研门路与方法，行业头部怎么做的、应用什么场景和我们的客户、目标有什么差异，例如做交互式推荐，美团外卖与淘宝就有很大的差异，背后的思考几何，要给算法分享，协同带领算法明确方向，多利用自己产品之间的行业信息差给算法去做。

第二个方面，制定逻辑的产品与科学的实验方案：

首先，需求文档这一块Arthur对学员的要求就是产品方案一定要清楚、细致以及逻辑自恰，方案的实现有千万种，但是实现的过程、正负流程一定要梳理清楚，这是产品的基础文档要求不赘述，PRD是产品展示给各方的作品更是你对于行军打仗的重要战略布局。

其次，科学的实验评测方案，实验前置方案设计如何分桶、是否需要正交，关注的指标，实验周期，实验置信标准，实验组胜出标准，实验中途出现异常的兜底方案，都需要尽可能的详尽，这里可以移步看Arthur写的关于策略产品AB实验的完整流程，记住一句话就好，科学的AB实验是策略产品协同算法一起评估策略和功能价值的尺度。

第三个方面，与算法深度参与方案过程开发：

前面方案制定完成切勿不要做甩手掌柜，既然要做知其然知其所以然的策略产品就需要深度参与技术方案的制定过程和开发，将个人业务知识能够输入至整个算法策略开发过程中，帮助算法找寻到达成效果的途径。

算法方案的制定&模型的选型：例如排序rankscore的建模因子、公式约束项，广告ROI投产比出价、Nobid出价背包定理算法的制定，这些建模的方案都与业务强相关，建议可以和算法进行深度参与，了解公式因子构建过程，关于建模思维的部分，可以移步Arthur关于建模思维的文章。模型选型属于附加项，不一定需要对模型的网络结构知根知底，了解大概，知道模型的优缺点即可。

特征工程：虽然目前特征工程都已经模型化了（自14年Facebook诞生GBDT+LR开始），仍然会有大量业务场景需要策略产品进行输入，例如淘宝88VIP人群推荐策略，基于业务场景更多考虑用户的消费能力、所处地域等等特征，并且了解特征数据清洗、归一化/标准化，特征分类也有利于策略产品对于业务知识的加深，特征工程部分，大家也可以移步Arthur特征工程文章内容。

模型效果指标优化与样本标注：样本标注可能是绝大多数初阶策略产品做的比较多的工作，不能简单认为为算法打杂，做不了高大上的策略，样本标注与喂养本身就是模型效果优化的重要步骤，大家都为结果负责，划分清楚工作内容即可。

而模型效果优化部分也是需要策略产品一同参与的，包括模型的AUC指标、F1-Score、召回率、准确率精准率，搜索的DCG、nDCG等等，虽然离线模型指标并不是和业务指标完全正相关，会存在离线效果好而线上效果差的问题，但是也需要策略产品深度参与优化。

做好资源协同与项目管理：这个是所有产品都需要具备的一定能力，并不是每个公司都有PMO，所以如何保证项目周期的预期推进也是策略产品需要具备的能力点，不进一步赘述。

第四个方面，有问题不甩锅有功一起领：工作中其实最重要的还是人心，不管工作的产品方向，与其他各方的合作在实验上线出现负向效果第一要义就是快速协同各方复盘找问题点，离线和线上实验不统一的问题，是样本问题还是线上环境其他因素影响，找到问题解决问题，切忌甩锅，这样会比较容易破坏各方信任感。在项目成功、项目全量上线的邮件当中，能够说清楚各方在功劳簿的内容，有功大家一起领，回到前面的那句话当中，要学会带着算法打胜仗，拿成果。

2. 策略产品与运营的合作

和运营合作的点其和上述合作内容差不不多，两个词语：战略清晰 和 能打胜仗。这两个词是Arhthur合作超过上百个算法得出的核心结论，不僭越他人的工作，“能他人之不能”就是和算法合作的最好方法。

这里其实又区分行业方向的运营和产品功能运营，多多思考自己工作岗位和他人之间的联系点和差异点，例如运营侧肯定是不如策略产品侧懂背后的原理。那么和运营合作更多还是要借助他们离客户近的优势，多去调研和分析客户的诉求。

我一直都认为策略产品的需求来源不是纯粹的模型升级，或者高能“炫技”，为了做需求而做需求有些本末导致。本质更多还是来自B端广告主客户痛点（例如最早ROI出价、OCPX出价）、媒体C端用户，发现增量/问题->提出问题假设->解决问题。本质思想和流程与其他产品无异，毕竟策略产品的核心价值就是产品。多接触业务场景、有条理有价值，根据重要程度&紧急程度&收益价值象限编排各方的需求来进行需求推进。

运营提出的需求需要有辨识力分清楚是否真正是客户痛点、价值几许（必要性方面），确认要做需求之后简单评估改造量级（可实现性方面）（一般工作时间长久的策略产品很快可以清楚了解预估的排期时间，最后的实际时间还需要工程+算法预估）。

最后，实现上线之后，如何协同运营开通白名单客户、拉动客户使用（Push、短信、广告平台站内信等等），在试验期间需要客户尽可能提高对功能使用率才能保证实验结果的置信程度（搜索/推荐C端一般直接UV/PV分桶即可，不涉及客户拉动，一般适用于广告场景），协同实现功能追踪。

3. 策略产品与工程研发的合作

除了上述的核心特质同样适用于和工程师研发之外，我个人觉得策略产品对于全局架构和数据流图的了解也是同样重要的，项目设计到的模块方上下游（例如推荐和搜索策略涉及到新样式的交互策略，那么APP客户端、服务端、推荐引擎端、创意算法、排序算法）等，能够快速绘制出各端之间的数据正负向流图，这是作为策略产品强化熟悉系统架构的重要方式，先通过几个需求快速熟悉上手局部、再通过全局系统了解所有的数据流。

其次，我建议策略产品在工程向工作当中还是可以积极了解一下各个模块功能，例如下图中Flink、Spark、Hadhoop、Redis各自都是做什么的，承担推荐系统什么职责，至于背后如何处理数据，Redis背后的工程开发原理无需很高的要求，了解即可，这里的学习无法是具备一定的工程思维，了解需求/策略的可实现视角，能够让你真实评估什么可做、什么不可做，有限资源中能做的事多少，而不是天花乱坠的乱提需求。

关于推荐系统架构说明图

三、总结

说完上面部分，不知道大家是否对策略产品和其他业务方的合作有了更加进一步清晰的认知了。Arthur这边还是希望尽可能的把工作当中沉淀、总结思考给大家分享到。

工作其实是一个建立信任感的过程，无论和同级、上级还是下属，能有边界、能打胜仗，有战略清晰，能他人之不能，其实自然而然在工作当中就能提高自己的效率，既然工作是和“人”一起工作，那就是有规律、有技巧的一个过程，大家工作都是为了能够升职加薪、做有价值事情的目标，所以即便是工作合作的矛盾，完全针对个人是没有意义和价值的。

所以新的一年开始也希望大家能够了解和学习一些新的内容，而不是盲头光顾着学习策略知识，提高自己在职场的壁垒，早日实现自己的职场目标。