“策略产品”虽然有些神秘感，但并不是遥不可及。本文以识别好瓜为例，粗线条对策略PM的工作进行介绍，希望对想了解这个领域的朋友们有所帮助。
圈内有个神秘的职业，名曰“策略产品经理”。在前端产品经理/后端产品经理、社交产品经理/电商产品经理、APP产品经理/WEB产品经理……大行其道的时候，策略产品经理显得格外低调，连论坛上都少有发声。且不说关于策略的方法论、思维方式、职业进阶相关的材料稀少，就连最基本的工作职责、工作流程和工作感想类的水文、鸡汤文都没几篇。
在行业已经如此成熟的今天，这个现象本身就是一件耐人寻味的事情。作为一个喜欢没事“拿耗子”的汪，笔者梳理近期的所见所闻及学习感受，跟读者扒一扒这个职业的基本工作方法和流程。
一、什么是策略
首先需要明确的是，行业内有策略PM和策略RD对于“策略”的定义和理解是不同的。
对于PM来说，策略是以数据驱动产品解决方案的一种方式。即使在非互联网行业，大家对于“策略”也是这么用的，所以才会有推广促销策略、渠道策略等说法。而在互联网行业中，因为数据收集的完备性及便捷性，策略被发挥得更加淋漓尽致。各种基于数据分析的解决方案都会被冠以策略之名，如“订单分发策略”、“搜索推荐策略”、“列表排序策略”等。
对于RD——特别是策略RD——来说，策略是评判模型优劣的标准。要说清楚这个表述，不得不说一下机器学习中的模型、算法、学习、样本这几个概念。此处不介绍复制的概念，就用笔者看到过的一个比喻来说明。吃货版的机器学习是酱紫的：数据好比食材；大厨把食材做成水煮鱼，还是做成西湖醋鱼…这些是模型；具体用的是什么手法是算法选择的问题；而机器学习就好比是整个做菜的过程；为了让菜变得更好吃，厨师得多次对火候、调料等进行调整，这就是调参的过程。一道菜出锅后，判断做法是不是好的，就是策略。
二、为什么需要策略
在产品的用户群和使用场景集中时，用功能的思维能够解决多数问题。但是，当用户增长到很大的量级、不同的用户群体与不同的使用场景交织产生难以计数的诉求时，单纯通过产品功能是不可能满足用户的需求的。
举例来说，一款音乐播放器的主要功能就是播放音乐，这一点毫无毛病。但是，对于用户而言，其根本需求是“听喜欢的音乐”。那么问题来了：首先是用户只想“听音乐”并不想“找音乐”，即使找音乐是刚需，也是不得不承受之重。所以为了能减少用户的搜寻成本，需要给用户推荐音乐。其次是“喜欢”，一千个人眼中有一千个哈姆雷特，更有数不清的关于喜欢的标准，如何让用户满意是个大问题。
这种情况，正是策略大显身手的恰当时机。通过获取用户的兴趣特征和音乐的特征，把用户历史上收听的数据作为正负样本对模型进行训练，一旦有新的音乐出现时就能得出用户是否会喜欢的标签。用户的收听及行为数据越多，模型判断的准确性越高，那么推荐的音乐受用户喜欢的概率就越高。这就是策略的魅力所在
三、如何搭建策略模型
所谓模型是从数据当中发现的一个数学规律。那么，作为一个PM如何搭建策略模型呢？其实和功能PM的工作类似，同样也是围绕着问题的发现、分析、解决和效果评估4大阶段。为了便于理解，就以如何挑选好瓜作为例子，权当是为吃瓜事业做贡献了。
1.发现和提出问题
假设我们是一家专门卖瓜的公司。产品经理在调研业务方时，对方抱怨用户投诉西瓜不好的情况越来越多。通过后台跑客户的历史数据，PM发现大约30%客户因为买到坏瓜而流失。作为一家重视商誉和用户体验的公司，我们当然不希望出现这种情况。可是问题在于：世界上的西瓜千千万，品种、大小、颜色都不一样，whoknows哪个西瓜是好瓜啊？
以上其实包含了问题的发现和定位的过程——通过对业务和用户的调研得到定性的判断，再通过数据分析得到定量的论据。在倒推问题的根源时，需要对业务的全流程进行分析。假设通过对流程的分析，问题落在了如何识别出好瓜上，那么接下来就是如何解决问题了。
2.拆解问题，制定解决方案
产品经理在前一个步骤中首先对问题进行了定义——也就是如何从众多西瓜中识别出好瓜，并且给好瓜打上标签。但是好瓜不会自己蹦出来，所以得通过一系列的模型进行识别。而要做模型识别，PM和RD就得告诉机器好瓜有什么特征。
特征是业务和技术结合的产物，PM从对业务的角度提出有助于模型识别的关键特征，以及判断特征好坏的标准；RD对这些特征进行技术落地。这里需要特别注意的是：
（1）PM在特征表述上一定要具体可衡量，将可能涉及到的范围和标准都明确地定义出来。例如，色泽是判断瓜好坏的一个特征，但是您不能仅仅告诉RD“青绿色的瓜就是好瓜”，这种模糊的需求只会让RD懵逼，你得明确什么是“青绿色”；“瓜”的范围是历史上所有瓜，还是仅限夏天产的瓜/从供应商A采购的瓜等等。
（2）特征需要结构化。PM根据不同的业务目的将特征进行归类并提炼出一个个子模型，但是对于RD来说很可能会将多个子模型合并成少量模型，甚至是就整合成一个模型。例如，在识别好瓜上，根据中国人民“望闻问切”的光荣传统，可能会先问卖家这瓜是哪里产的，是沙地瓜还是山地瓜…然后是看看瓜的外观，最后会轻敲两下听听回声如何。那么相对应的，在机器学习上可能存在准入模型、外观辨别模型、回声辨别模型共3个模型。其中，相同的特征可能会在不同的子模型中被使用；另外，每个子模型都有输入和输出，有些时候还会存在多个子模型共同给出一个输出的情况。
3.跟进策略模型的开发落地
功能产品经理在开发过程中需要做好开发答疑、项目推进、需求调整等工作，策略PM也是一样的。不同的是在具体的操作的层面上。
（1）策略RD接到需求后会先确认和理解数据
对尚不存在的数据进行接入，对已有的数据则是明确口径。然后是对数据进行融合和清洗，这个过程中可能就会产生很多问题，有些可以由RD同学自行解决，有些则需要PM进行确认。
（2）在完成数据清洗后，RD进行模型的构建
这个阶段RD是主导，虽然模型和算法的选择一般没PM什么事儿，但是PM提供的特征以及特征之间的相互关系将会影响RD在开发时做的判断。比如，如果PM能说清楚好瓜和坏瓜的根蒂、色泽、触感…分别是怎样的，那么RD可能会使用决策树这种监督学习的模型；如果PM说不清楚，有可能RD就会改用聚类这样的无监督算法了。有些特征和关系一开始不明确也不要紧，但是在开发过程中是需要给出明确的表述的。
4.制定评估方案，完成效果评估
这里的评估包含两层含义，第一层是模型本身质量的评估，第二层是模型在项目中的价值评估。先说第一层。
不同的模型和算法有不同的评估方法，专业的RD对这方面都了解，不需要PM操心。PM需要关心的是：
了解行业和公司内部普遍达标的标准，并以此标准作为参考对策略提出达标的要求。笔者工作的领域中使用是准召率，其中精准率用来判断模型的准确性，召回率用来判断模型覆盖的情况，这两者往往不可兼得、此消彼长。通过过程数据了解模型最终落地的逻辑，在上线前确定无误，一定程度上起到质量控制的作用。
第二层是模型的业务价值评估。在大公司，业务价值的评估往往结合着小流量测试来做。
假设咱的卖瓜公司在北上广深都有业务，其中广州的业务体量最小，最适合做小流量测试。在广州分公司中有10几个销售组，那么在下发测试时需要选出测试的实验组和对照组。选分组也是有讲究的，需要两个组是同质的，而所谓的“同质”也没有唯一的判定标准，需要根据不同的项目和业务进行举一反三。我们假设这里的“同质”的关键指标是客户流失率（并且最好这两个组的客户数量、客户体量、组内的销售人员、维护人员等等都是相近的）。在以上都确定完毕之后，进行测试下发。测试结束后观察实验组相对对照组的数据提升情况，例如原来实验组和对照组的30%客户因为上面说的坏瓜问题而流失，而测试期间实验组的该项数据降到了15%，那么就可以初步判断这个项目是有足够价值的。
以上是做策略产品需要了解的基础知识，要做好这份工作有诸多不易。在基本素质方面，对思维能力、项目管理能力、业务洞察能力、产品设计能力、沟通表达能力有较高要求；在专业素质方面，需要了解机器学习、统计学等。这里只是冰山一角，后期有更多新认识时再分享。
本文由
霹雳原创发布于人人都是产品经理。未经许可，禁止转载。题图来自Pexels，基于CC0协议
联系电话：