“吃瓜”为例,谈策略PM和模型搭建

圈内有个神秘的职业,名曰策略产品经理。在前端产品经理/后端产品经理、社交产品经理/电商产品经理、APP产品经理/WEB产品经理……大行其道的时候,策略产品经理显得格外低调,连论坛上都少有发声。且不说关于策略的方法论、思维方式、职业进阶相关的材料稀少,就连最基本的工作职责、工作流程和工作感想类的水文、鸡汤文都没几篇。

在行业已经如此成熟的今天,这个现象本身就是一件耐人寻味的事情。作为一个喜欢没事拿耗子的汪,笔者梳理近期的所见所闻及学习感受,跟读者扒一扒这个职业的基本工作方法和流程。当然,和功能产品经理相似,支撑策略PM工作的也是一整套复杂的体系,而这篇文章能涉及的只是很基础的部分。

“吃瓜”为例,谈策略PM和模型搭建
什么是策略

“吃瓜”为例,谈策略PM和模型搭建

首先需要明确的是,行业内有策略PM也有策略RD,而两者对于策略的定义和理解是不同的。

对于PM来说,策略是以数据驱动产品解决方案的一种方式,在这个维度上,策略的含义和大家通常理解的并没有太大的不同。即使在非互联网行业,大家对于策略也是这么用的,所以才会有推广促销策略、渠道策略等说法。而在互联网行业中,因为数据收集的完备性及便捷性,策略被发挥得更加淋漓尽致。各种基于数据分析的解决方案都会被冠以策略之名,如订单分发策略搜索推荐策略列表排序策略等。

对于RD——特别是策略RD——来说,策略是评判模型优劣的标准。要说清楚这个表述,不得不说一下机器学习中的模型、算法、学习、样本这几个概念。简单地说模型是从数据中抽象出来的数学规律;算法是实现模型的具体方法;学习是使用数据样本训练模型的过程;样本是数据集,可分为正样本和负样本。一个模型要达到一定的性能要求,就必须不断进行调优,这主要是通过模型调参实现的。

上面的说法略抽象。笔者看到过一个简单易懂且恰当的比喻。吃货版的机器学习是酱紫的:数据好比食材;大厨把食材做成水煮鱼呢,还是做成西湖醋鱼,再或者松鼠桂鱼这些是模型;具体用的是什么手法是算法选择的问题;而机器学习就好比是整个做菜的过程;为了让菜变得更好吃,厨师得多次对火候、调料等进行调整,这就是调参的过程。一道菜出锅后,判断做法是不是好的,就是策略。同样是鱼,如果把水煮鱼的模型套用在金枪鱼这样的食材上,恐怕从策略的角度看是要打低分的。

“吃瓜”为例,谈策略PM和模型搭建
为什么需要策略

“吃瓜”为例,谈策略PM和模型搭建

笔者是从功能产品经理转为偏策略的PM的。对于多数的功能PM而言,往往面对的是数量有限的场景和用户,需要用归纳的方法进行抽象和总结。这部分的工作是行业内多数产品经理都在从事的,也是大家相对熟悉的。不少同行从入门开始就在梳理业务流程、使用场景、产品流程、用户画像,进行功能设计和模块规划。由于这部分的工作相对而言集中在深度方面,因此需要产品经理有很强的需求发掘、用户洞察、流程梳理能力,以及一定的设计品味和对用户体验的极致追求。

在产品的用户群和使用场景集中时,用功能的思维能够解决问题。但是,当用户增长到很大的量级、不同的用户群体与不同的使用场景交织产生难以计数的诉求时,单纯通过产品功能是不可能满足用户的需求的。

举例来说,一款音乐播放器的主要功能就是播放音乐,这一点毫无毛病。但是,对于用户而言,其根本需求是“听喜欢的音乐”。那么问题来了:}首先是用户只想听音乐并不想找音乐,即使找音乐是刚需,也是不得不承受之重。所以为了能减少用户的搜寻成本,需要给用户推荐音乐。其次是喜欢,一千个人眼中有一千个哈姆雷特,更有数不清的关于喜欢的标准,如何让用户满意是个大问题。这种情况,正是策略大显身手的恰当时机。通过获取用户的兴趣特征和音乐的特征,把用户历史上收听的数据作为正负样本对模型进行训练,一旦有新的音乐出现时就能得出用户是否会喜欢的标签。用户的收听及行为数据越多,模型判断的准确性越高,那么推荐的音乐受用户喜欢的概率就越高,对比前面提到的问题是不是瞬间柳暗花明了呢。

“吃瓜”为例,谈策略PM和模型搭建
如何搭建策略模型

“吃瓜”为例,谈策略PM和模型搭建

前面说过,所谓模型是从数据当中发现的一个数学规律。那么,有的朋友可能就疑惑了:我是PM,又不是数学家,能发现啥规律啊?确实,从实战角度来看,如果PM具备统计学或者数学的背景,做策略是有一定优势的。但是并不意味着没有这样的背景就做不了策略PM。那么,作为一个PM如何搭建策略模型呢?其实和功能PM的工作类似,同样也是围绕着问题的发现、分析、解决和效果评估4大阶段。为了便于理解,就以如何挑选好瓜作为例子,权当是为吃瓜事业做贡献了。

“吃瓜”为例,谈策略PM和模型搭建

a.发现和提出问题

假设我们是一家专门卖瓜的公司。产品经理在调研业务方时,对方抱怨用户投诉西瓜不好的情况越来越多。通过后台跑客户的历史数据,PM发现大约30%客户因为买到坏瓜而流失。作为一家重视商誉和用户体验的公司,我们当然不希望出现这种情况。可是问题在于:世界上的西瓜千千万,品种、大小、颜色都不一样,who knows哪个西瓜是好瓜啊?就连卖西瓜的业务方都不知道哪个好哪个不好,自然卖给用户的时候就会出现良莠不齐的情况。

以上其实包含了问题的发现和定位的过程。一般而言,策略产品经理会通过对业务和用户的调研得到定性的判断,再通过数据分析得到定量的论据。在倒推问题的根源时,需要对业务的全流程进行分析。假设通过对流程的分析,问题落在了如何识别出好瓜上,那么接下来就是如何解决问题了。

b.拆解问题,制定解决方案

模型可以用一个简单的公式来表示:Y=f(X)产品经理在前一个步骤中首先对定义问题进行了定义——也就是如何从众多西瓜中识别出好瓜,并且给好瓜打上标签。但是好瓜不会自己蹦出来,所以得通过一系列的模型进行识别。而要使用模型识别好瓜,PMRD就得告诉机器好瓜有什么特征,而这些特征正是X

X是业务和技术结合的产物,PM从对业务的角度提出有助于模型识别的关键特征,以及判断特征好坏的标准;RD对这些特征进行技术落地。这里需要特别注意的是:

PM在特征表述上一定要具体可衡量,将可能涉及到的范围和标准都明确地定义出来

1

例如,色泽是判断瓜好坏的一个特征,但是您不能仅仅告诉RD“青绿色的瓜就是好瓜”,这种模糊的需求只会让RD懵逼,你得明确什么是“青绿色”;“瓜”的范围是历史上所有瓜,还是仅限夏天产的瓜/从供应商A采购的瓜等等

特征的表述需要结构化

2

PM根据不同的业务目的将特征进行归类并提炼出一个个子模型,但是对于RD来说很可能会将多个子模型合并成少量模型,甚至是就整合成一个模型。例如,在识别好瓜上,根据中国人民“望闻问切”的光荣传统,会先问卖家这瓜是哪里产的,是沙地瓜还是山地瓜然后是看看瓜的外观,最后会轻敲两下听听回声如何。那么相对应的,在机器学习上可能存在准入模型、外观辨别模型、回声辨别模型共3个模型。

这里需要说的是相同的特征可能会在不同的子模型中被使用;另外,每个子模型都有输入和输出,有些时候还会存在多个子模型共同给出一个输出的情况。

“吃瓜”为例,谈策略PM和模型搭建

c.跟进策略模型的开发落地

功能产品经理在开发过程中需要做好开发答疑、项目推进、需求调整等工作,策略PM也是一样的。不同的是在具体的操作的层面上。

策略RD接到需求后会先确认和理解数据。对尚不存在的数据进行接入,对已有的数据则是明确口径。然后是对数据进行融合和清洗,这个过程中可能就会产生很多问题,有些可以由RD同学自行解决,有些则需要PM进行确认。例如,一部分西瓜的生产日期是1970-01-01,这可能是PHP的起始时间戳,但是这个时间肯定是不能使用的。那么是否可以由业务确认取一个公司最早采购的时间呢?这时就需要产品经理去完成调研了。

在完成数据清洗后,RD进行模型的构建。这个阶段RD是主导,虽然模型和算法的选择一般没PM什么事儿,但是PM提供的特征以及特征之间的相互关系将会影响RD在开发时做的判断。例如,如果PM能说清楚好瓜和坏瓜的根蒂、色泽、触感分别是怎样的,那么RD可能会使用决策树这种监督学习的模型;如果PM说不清楚,有可能RD就会改用聚类这样的无监督算法了。有些特征和关系一开始不明确也不要紧,但是在开发过程中是需要给出明确的表述的。

d.制定评估方案,完成效果评估

模型开发出来后,需要达到一定的准确度才能正式上线,所以就需要进行模型的评估。这里的评估包含两层含义,第一层是模型本身质量的评估,第二层是模型在项目中的价值评估。

先说第一层。不同的模型和算法有不同的评估方法,专业的RD对这方面都了解,不需要PM操心。PM需要关心的是:

了解行业和公司内部普遍达标的标准,并以此标准作为参考对策略提出达标的要求

1

通过过程数据,对模型的整体逻辑进行了解,一旦出现问题,就和策略RD共同探讨改进的办法。

2

通用的一个惯例是将80%的样本作为模型的训练集,剩下的20%样本作为验证集。模型开发中几乎有将近一半时间用来调参,以使模型在验证时能通过评估。这里的评估标准不一而足,笔者工作的领域中使用是准召率,其中精准率用来判断模型的准确性,召回率用来判断模型覆盖的情况,这两者往往不可兼得、此消彼长。

         第二层是模型的业务价值评估,这个结果往往决定了一个项目有无价值和能坚持多久。在大公司一个新功能上线后是不会马上进行全流量发布的,而是先从小流量测试开始,有时甚至是从少数天使用户测试开始。

假设咱的卖瓜公司在北上广深都有业务,其中广州的业务体量最小最适合做小流量测试。在广州分公司中有10几个销售组,那么在下发测试时需要选出测试的实验组和对照组。选分组也是有讲究的,需要两个组是同质的,而所谓的“同质”也没有唯一的判定标准,需要根据不同的项目和业务进行举一反三。我们假设这里的“同质”的关键指标是客户流失率,那么需要选出的实验组和测试组在过去一段时间(例如6个自然月)中流失率就得是相同的或者是很接近,并且最好这两个组的客户数量、客户体量、组内的销售人员、维护人员等等都是相近的。

在以上都确定完毕之后,进行测试下发(在测试期间还需要进行各种协调和运营,此处不细说)。测试结束后则是观察实验组相对对照组的数据提升情况,例如原来实验组和对照组的30%客户因为上面说的坏瓜问题而流失,而测试期间实验组的该项数据降到了15%,那么就可以初步判断这个项目是有足够价值的。

以上是做策略产品需要了解的基础知识,要做好这份工作有诸多不易。在基本素质方面,对思维能力、项目管理能力、业务洞察能力、产品设计能力、沟通表达能力有较高要求;在专业素质方面,需要了解机器学习、统计学等。这里只是冰山一角,后期有更多新认识时再分享。

来源:产品霹雳,本文观点不代表自营销立场,网址:https://www.zyxiao.com/p/53183

发表评论

电子邮件地址不会被公开。 必填项已用*标注

侵权联系
分享本页
返回顶部