1.4　策略产品经理的工作内容

1.4.1　团队配置：策略团队的工作分工

大多数规模较大的公司，产品策略是团队协作完成的，所以策略团队内部会涉及一些分工问题，在此将做一些简单的整理。

除了策略产品经理外，策略团队中往往还有研发工程师、运营经理、功能型产品经理、标注专员、数据分析师等岗位。

●研发工程师：主要以推荐算法工程师、服务端工程师为主，较少涉及前端/客户端开发工程师。

●运营经理：包括用户运营经理、内容运营经理和平台运营经理。

●功能型产品经理：不同公司的合作模式也会有所不同，比如，有些公司是纵向合作模式，策略产品经理从后台做到前端；有些公司是横向合作模式，策略产品经理和功能型产品经理分别做自己擅长的部分，共同完成某一个项目。

●标注专员：当涉及后台流程且由策略产品经理主观评估时，经常要与标注专员打交道。

●数据分析师：主要负责一些数据库表的口径、埋点咨询工作，同时还要负责提出一些高难度的数据需求。

策略产品经理小组内部也会进行分工，具体分工如表1-1所示。

表1-1　策略产品经理小组内部分工

另一方面，算法工程师一般分为4类，分别是负责系统架构的工程师、负责推荐算法的工程师、负责内容画像的工程师和负责策略评估的工程师。产品经理和研发工程师是有某种对应关系的，在大多数公司中策略产品经理往往和后两者交集较多。

接下来，将概述策略产品经理与其他角色的工作交集，并分别介绍策略团队4个方向的日常工作及在数据方面的通用技能。

1.通用策略

通用策略其实主要以优质性、相关性、及时性、多样性4个考察指标为主，如表1-2所示。

表1-2　通用策略的4个考察指标

在信息流产品中，以上策略在实现过程中遵循筛选、过滤、排序策略和信息流规则（比如打散、置顶等）。

●筛选逻辑：比如“选择过去近30天所有含有图片的图文动态内容”。

●过滤策略：比如“过滤掉居于类型A的内容”。

●排序策略：比如“对全体用户，将类型B的内容权重提升50%”。

●打散规则：比如“连续5条内容中，最多连续出现两条类型C的内容”。

●置顶规则/沉底规则：比如“类型D的内容需要置顶、类型E的内容需要下沉至第10位”。

不过，有一个规则容易被大多数策略产品经理忽略，即所谓的“规则优先级”。对于很容易出现冲突的策略规则，需要制定规则的生效优先级，并且制定在规则发生冲突时的优先逻辑。

也许你会问，刚刚列举的这些规则怎么知道是对的？规则之间发生冲突时有没有更好的解决办法？这通常是困扰策略产品经理的两个比较棘手的典型问题。别着急，答案会在第6章中给出。

2.垂类策略

垂类策略是另一类重要的策略，它和刚刚讲过的通用策略有共同之处，但也有许多的不同。接下来将通过对比的方法来帮助读者理解垂类策略。

垂类策略和通用策略的第一个不同之处是用户比例和评估指标的不同。垂类策略会根据用户群体的不同有不同的业务指标，不像通用策略，各家公司的总体指标是接近的。垂类策略针对的用户如下。

●新增用户：比如来自应用商店、手机预装等的新增用户。

●召回的流失用户：比如通过各种渠道召回的流失用户。

●潜在流失用户：比如通过各种数据手段定义的将要流失的用户。

●低活跃用户：比如通过数据手段定义的产品使用频率较低的用户。

垂类策略不是只针对上述这几类用户，毕竟原则上说只要某个策略的覆盖人群比例不足100%，就属于垂类策略。对于细分的垂类用户，策略产品经理会根据不同的项目制定不同的评估指标，这一点是和通用策略不一样的，所以在做垂类策略的时候往往没有做通用策略时那么体系化，毕竟用户群的种类较多。

第二个不同之处是策略强度不同。由于垂类策略是对少数用户做的定制化策略，所以与温和的通用策略相比，垂类策略相对会更激进，甚至有时可以突破一些既定的产品规则，比如正常对用户做应用推送每天最多推送一条消息，但是单独针对低活跃用户时可以每天推送两条定制化的消息。

第三个不同之处是应用垂类策略时用户生命周期特征会增强。所谓“生命周期策略”，与自然年、自然月、自然周相区分，它是针对用户在前X天或者前X次进行某种行为（通常是登录）时会触发的策略。

通用策略中虽然也有一些基于用户生命周期的策略（比如，对于全量用户，首次登录时赠送大礼包，每隔30天进行一次问卷访问），但是针对垂类用户应用这种策略效果会更好（比如，对于新用户的前3次登录，给予新用户“新手大礼包”，并且在前7天给予某种激励）。这是由于随着用户群的缩小，策略产品经理对用户的理解更加深刻，从而制定出更加个性化的生命周期策略。

3.内容画像和用户画像

第三部分要介绍的是内容画像和用户画像方面的策略，这部分工作包括对已有特征的评估、对已有特征的生产维护、对新特征的构建，如表1-3所示。

表1-3　内容画像和用户画像的主要工作

算法职位和业务职位哪个更需要用户画像？答案其实是负责业务的相关职位。这并不是说模型算法不需要用户画像提供的数据，只是在机器学习中可以使用矩阵分解等效果更好的隐向量方式来运用用户行为数据，对用户画像依赖程度没有那么高。

但大多数模型都是不可解释的，比如某篇文章为什么推荐给你，算法工程师大多数也只能说这是模型计算的结果而不能给出更通俗的解释。用户画像就是这样一种帮助公司业务人员理解用户的手段。有了用户画像，策略产品经理和运营经理才能更好地通过标签来多维度理解用户。

换一个新的例子，比如“用户点击来自小红书的SKII洗面奶广告”，对于小红书内部的运营经理来说，可以对这种用户行为进行归因解释，经过数据分析可能得到以下信息。

●点击SKII洗面奶广告的用户89%是女性，但也有11%是男性。

●点击SKII洗面奶广告的用户28%在广东省，11%在北京市。

●点击SKII洗面奶广告的人群中，设计师最多，产品经理次之。

●……

本例是虚构案例，目的是方便各位理解用户画像和内容画像的作用。策略产品经理和运营经理可以根据这些画像基于数据分析制定更细致的规则，毕竟推荐算法的可理解性也是非常重要的。

用户画像和内容画像的构建工作主要分为两个大的部分。

●首先要建立画像体系，其中所用特征部分是自动生成的，部分是平台标注专员标注的。策略产品经理要时刻监控特征库的完备性，保证准确率与召回率的提升，并且要设计好后台和数据流程、定义监控特征完备度的描述统计量。需知，算法模型效果与特征的准确率和召回率是息息相关的。

●有了画像体系以后，通用策略、垂类策略的产品经理会根据不同的业务目标制定不同的策略规则。特征做得越好，实现平台共享越容易。业务各相关方共用一套基础数据体系，再融合中台体系，可充分发挥公司的规模效应，从而助力业务人员取得更好的业绩。

4.平台生态和功能体验

策略产品经理当然还属于产品经理，在平台生态和功能体验方面的主要工作分为如下三类。

●前台体验：处理与后端、策略有关的用户端体验。

●生态把控：平衡创作者、读者和平台的利益。

●完成用户反馈的收集，进行用户访谈。

第一类：前台体验

仅就前台功能而言，策略产品经理与功能型产品经理的区别主要是前者负责一些策略相对较多的功能模块，比如大多数内容型产品都会有的“相关推荐”模块，再比如滴滴拼车的“拼车流程”，这些都是需要进行精细策略设计的产品模块。这部分的数据导向相对前三个方向的策略工作偏弱，需要综合考量用户体验和数据指标。

在一些小公司，策略产品经理也需要做一些横向的工作。在完成客户端产品功能设计后，策略产品经理还要根据功能型产品经理提出的一些需求进行策略设计，在这种合作模式下策略产品经理更像是支持角色。在这类公司中策略产品经理可以接触更多的产品线逻辑，但是受功能的限制也会有策略无法全力发挥的不足之处，同时因为增加一个角色会增加整体项目的人员复杂度，所以笔者不很推荐这种合作模式。

第二类：生态把控

生态把控通常由策略产品经理小组的负责人主导。如果是社区这种涉及三方参与者的产品，负责人需要平衡平台、内容消费者和内容生产者三方的利益。如何设置调配指标？如何让公司内部的其他角色认同该指标？如何在多策略设计冲突的时候进行取舍？这些都是生态把控的决策者需要考虑的事情。

第三类：用户反馈收集+用户访谈

在“用户反馈收集+用户访谈”方面，策略产品经理和其他产品经理不一样，其他产品经理的用户数据来自用户体验研究团队，但用户体验研究团队为获取用户数据而设计的调研问题往往较少涉及推荐策略、效率方面，即使有涉及，也往往难以满足策略产品经理的要求。而推荐策略、效率方面的用户数据是策略产品经理的主要关注点之一，所以策略产品经理需自己设计这方面的调研方式。

接下来，介绍策略团队在数据方面的通用技能。

数据方面的通用技能

虽然策略产品经理主要分为4个方向，但有一个工作技能是上述每一个方向的策略产品经理都必备的——数据分析能力。

策略产品经理本身需要具备较高的数据分析能力，但这并不说明策略产品经理可以和数据分析师“划等号”，所以需要厘清哪些事情应该由数据分析师团队来完成，哪些事情应该由策略产品经理来完成。

数据分析师需要完成的工作如下。

●为较为复杂的业务数据提供零散支持：比如为急需的、获取难度较高的、需要较多计算资源的数据提供支持。

●客户端埋点的字段定义：主要由数据分析师以及前端相关人员、后端相关人员、数据产品经理共同完成。

●日常数据变更：App发版以后，处理一些埋点变更、报表口径的改变梳理等工作。

●日常数据（尤其是核心指标）的涨跌分析：策略产品经理发现数据问题→策略产品经理简单排查数据问题→数据分析师深度排查并形成深度报告。

●生成页面级/战略级的项目数据报告。

策略产品经理需要完成的工作如下。

●为简单的业务数据提供零散支持：比如为常用表单、日常业务数据提供交叉分析。

●A/B测试实验的通用指标日报设计和与具体实验相关的特异性指标设计。

●A/B测试实验开启前与数据产品经理确认埋点有效性。

　•对A/B测试实验数据的涨跌进行预估及实验数据分析，包括数据排查和涨跌原因的分析。

　•给出实验数据报告，报告中应包括时间、数据、结论和下一步工作。

●生成非页面级/战略级具体子模块相关的数据报告。

1.4.2　个人配置：策略产品经理的日常工作内容

介绍完策略产品经理小组的分工与日常工作内容，你是否对这个职位有了更多的了解呢？本节从更微观的视角来看看策略产品经理这个职业方向。

先从身边的事情说起吧。你可能在各种会议室看到策略产品经理忙碌的身影，那他们到底在忙些什么呢？列举几项工作中常见的策略产品经理工作的场景。

●与客户端开发工程师、功能型产品经理讨论某个强策略项的产品需求，比如内容类产品中的相关推荐页面的逻辑。

●与后台开发工程师讨论某项特征的后台维护流程、日报格式以及特征准确度的计算方法。

●与算法工程师、数据分析师和当时做该数据埋点的数据产品经理共同讨论某项实验数据的异常情况，并追溯原因。

●充当“翻译”，与运营经理、功能型产品经理就产品某项体验需求与算法团队沟通，将运营经理和功能型产品经理的需求转化成if…else…语句（比较逻辑化的表达）描述给算法工程师，同时将算法工程师的反馈以及需要降低预期的部分合理地转述给运营经理、功能型产品经理。

以上描述的几种场景是策略产品经理日常工作的一些“切片”，实际工作内容因为岗位设置和项目设置的不同会有一些差别，但是整体的工作框架是不变的。

策略产品经理日常工作内容可以分5部分，如图1-3所示。

图1-3　策略产品经理的日常工作

1.收集和评估实例

这部分工作是最重要的，但也是最常被忽视的。在1.1节中提过策略产品经理最主要的工作是评估和推动，而评估实例（大多数时候叫作Case）是评估工作的一个重要环节。评估实例包括评估推荐算法中推荐的文章是否符合预期、搜索结果中的不当结果是否被过滤掉、评论是否被反垃圾分类模型误处理等。

有时候，笔者会和朋友开玩笑说，策略产品经理实际上一半时间是在做标注专员的工作，这部分工作像是做智力测验题，看着枯燥但其实很有乐趣，通过每天修正一些策略，可以让负例（通常叫Badcase）的比例减少。不要小瞧一点一滴的策略修正，没有任何一款产品是通过一个满分策略而成功的，通常是上线了10个还不错的策略最终达成一个还不错的结果，所以这部分工作的积累是有意义的。

通常，有以下几种评估实例的思路。

●将自己分别放在实验组和对照组，让自己真实体验并据此对用户做判断。自己每天坚持用产品，并逐渐雕琢，使产品达到自己心目中的理想态。

●收集内部反馈和外部反馈，包括实验组内外的用户有哪些评论，区分这些评论中哪些是需要关注的，哪些是不需要关注的。

●对于已确认的负例，要思考是通过正则解决还是模型解决，找到负例的模式（通常叫Pattern），评估各负例的占比和解决优先级。

2.科学系统的评估

策略产品经理通常上班第一件事就是查收邮件，看最近上线的项目的埋点情况，以及最近上线的A/B测试实验的评估结果。这里的评估主要分为4种情况：非A/B测试实验的数据分析指标、A/B测试实验指标、主观指标、无指标，具体内容将在第3～5章展开介绍。

●非A/B测试实验的数据分析指标：主要是指大盘指标的波动观察（通常由数据平台构建），重要数据需要有数据日报，日报中没有的，需要分析一些最近上线项目的数据报告。因为非A/B测试实验中多个变量是相互影响的，所以需要看近日相关数据的波动、环比/同比情况。对于一些潜在异常情况，要综合最近上线项目的日活变化一起评估。

●A/B测试实验指标：成型的公司一般都有A/B测试实验系统和数据可视化系统，随时观察实验结果的变化并做猜想和假设，此时需要观察实验周期、置信度、样本量，还要考虑产品上线可能会带来的干扰、分流情况等潜在因素，并一一予以排除。

●主观指标：用主观评估的方法论可确定新的策略带来的收益，主要用于某个项目上线效果的补充评估。主观指标的目标是输出科学定量结果，比如分类准确率高于某个数值。也有一些问卷包含主观评估指标，比如通过用户问卷得到的反馈投诉率等。

●无指标：有一些项目存在没有评估指标的情况，项目的决策者可能会进入什么都没有、什么都想要的纠结期，这时候需要策略产品经理想好解决方案，并尽快推动领导定下合理指标。

3.项目跟进

关于项目跟进通常有以下几个关键点。

●管理领导预期：在大多数公司中，领导的需求主要是基于商业目的而非技术成本和策略难度。在这种情况下，策略产品经理需要管理领导预期，让领导了解部分项目需求是不合理的，以及为什么不合理，在战略层面影响高层决策的同时让项目得以在正确的轨道上前进。

●紧盯项目：项目开始以后并不会一切顺利，策略产品经理需要紧盯自己项目的进行情况。一般来说，公司实行项目制，所以已经推动的项目要持续推动，策略产品经理要为某几个指标负责。有两种常见的情况需要注意，情况一是某些需求被延期，而这个消息没有被相关人员周知；情况二是研发工程师的实现逻辑和策略设计不相符。

●解答研发工程师的项目细节问题：项目开发过程中会出现一些问题，这些问题可能是服务器的性能问题，也可能是一些依赖的功能模块可复用问题，还可能是一些需求是否可以忽略、拆两期等，这部分工作需要策略产品经理与研发工程师一起解决。

●判断问题优先级：判断优先级是最能体现策略产品经理判断力的工作，一个好的策略产品经理要敢于说“不”。对不合理的需求要拒绝，对合理的需求要评估具体的项目预期收益。对于这部分工作，大多数产品经理是一样的。

●历史项目的复盘：产品经理作为项目的负责人，通常需要主动开复盘会议。复盘无论是为了庆功，还是为了反思，都需要策略产品经理遵循“对事别对人”的原则进行理性复盘，复盘是为了下次做得更好。

另外一点特别要注意的是，策略产品经理负责的算法和代码逻辑是无法让测试人员介入的，因为大多数测试人员只负责客户端版本的上线而很少去检查策略代码的实现。策略产品经理要想做好相关工作，一个比较常用的办法是“以请教问题的方式，让研发工程师从头到尾讲一遍策略代码的实现细节”，这种方式屡试不爽。很多情况下研发工程师在时间要求比较紧的项目中会通过复述的方式，让策略产品经理知道了项目具体的实现细节是否和自己的策略设计相同，同时达到了测试的目的。

4.文档撰写

大多数公司使用的是共享文档，这有利于形成团队“公有知识”。笔者通常从以下4个方面写文档。

●判断问题的本质：从“道”的层面，判断项目是否要启动，也就是“Yes or No”的判断，如果是“No”则不会进入下一步的流程。判断依据主要是这件事是否有收益，是长期收益还是短期收益。

●分解解决方案：把解决问题的所有方案都列出来，分析每一个方案大概能解决百分之多少的问题。

●判断ROI：ROI也称投资回报率，回报率的计算体现在OKR指标的预期涨幅上，成本体现在预期的工作量上，在技术细节上要有一个先行的经验判断。（不要求换算为具体工作人数、累计开发天数等。）

●写详细策略：这部分内容主要在第6章介绍，笔者的方法是依赖数学模型和数学建模的思路来写策略文档。实际上，每个策略产品经理的写作习惯都不一样，所以找到适合自己的方法最重要。策略方案追求的是高效、没有歧义，让开发工程师觉得清晰易懂。一图胜千言，尽可能地用流程图、交互图展现方案。

5.问题发现和行业调研

这部分工作是策略产品经理能力模型中“学习力”的体现，主要包括以下内容。

●竞品监控：大多数策略产品经理手机中会至少安装50款应用，其中不少于3款是竞品，以求随时关注行业内竞品又加了什么策略。这部分工作更有挑战性，因为策略的变化比产品功能变化更难发现。发现渠道主要有公开报道、自己体验、人脉关系了解。对于任何竞品的新策略，策略产品经理都要思考一下竞品方为什么这么改，自己要不要跟进。策略型产品的难点就是很难借鉴竞品，这既是挑战也是机遇。

●技术论文：这部分工作因人而异，对于有技术积累的策略产品经理来说，他们需要了解业界的前沿信息，比如“机器学习的顶尖会议上的获奖论文”，不求看懂但需要知道他们做了哪些改进，比如“在视频理解方面，世界最高水平的公司大概做到了什么程度”。一旦有了新的信息，要同步给团队的工程师。

●抬头看路：主要是看自己手头的业务线有哪些明显的问题。举个例子，如果你是携程的产品经理，就要看自己能不能推动平台建立信用体系，以提升用户的购票体验。

●对工具使用方法的学习：找到自己工作中制约效率的部分，学习使用更高效的工具。

●行业报告：获取权威平台发布的信息，如36氪、虎嗅等公众号发布的科技动态，又如每年互联网巨头发布的财报、一些可信的第三方数据公司发布的数据分析报告等，再如小镇青年、银发经济、男性消费的变迁等发布的数据小趋势。这些数据将提升你对大盘信息的认识。