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

2 评论 7128 浏览 48 收藏 13 分钟

“策略产品”虽然有些神秘感,但并不是遥不可及。本文以识别好瓜为例,粗线条对策略PM的工作进行介绍,希望对想了解这个领域的朋友们有所帮助。

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

在行业已经如此成熟的今天,这个现象本身就是一件耐人寻味的事情。作为一个喜欢没事“拿耗子”的汪,笔者梳理近期的所见所闻及学习感受,跟读者扒一扒这个职业的基本工作方法和流程。

一、什么是策略

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

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

对于RD——特别是策略RD——来说,策略是评判模型优劣的标准。要说清楚这个表述,不得不说一下机器学习中的模型、算法、学习、样本这几个概念。此处不介绍复制的概念,就用笔者看到过的一个比喻来说明。吃货版的机器学习是酱紫的:数据好比食材;大厨把食材做成水煮鱼,还是做成西湖醋鱼…这些是模型;具体用的是什么手法是算法选择的问题;而机器学习就好比是整个做菜的过程;为了让菜变得更好吃,厨师得多次对火候、调料等进行调整,这就是调参的过程。一道菜出锅后,判断做法是不是好的,就是策略。

二、为什么需要策略

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

举例来说,一款音乐播放器的主要功能就是播放音乐,这一点毫无毛病。但是,对于用户而言,其根本需求是“听喜欢的音乐”。那么问题来了:首先是用户只想“听音乐”并不想“找音乐”,即使找音乐是刚需,也是不得不承受之重。所以为了能减少用户的搜寻成本,需要给用户推荐音乐。其次是“喜欢”,一千个人眼中有一千个哈姆雷特,更有数不清的关于喜欢的标准,如何让用户满意是个大问题。

这种情况,正是策略大显身手的恰当时机。通过获取用户的兴趣特征和音乐的特征,把用户历史上收听的数据作为正负样本对模型进行训练,一旦有新的音乐出现时就能得出用户是否会喜欢的标签。用户的收听及行为数据越多,模型判断的准确性越高,那么推荐的音乐受用户喜欢的概率就越高。这就是策略的魅力所在

三、如何搭建策略模型

所谓模型是从数据当中发现的一个数学规律。那么,作为一个PM如何搭建策略模型呢?其实和功能PM的工作类似,同样也是围绕着问题的发现、分析、解决和效果评估4大阶段。为了便于理解,就以如何挑选好瓜作为例子,权当是为吃瓜事业做贡献了。

1. 发现和提出问题

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

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

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需要关心的是:

  1. 了解行业和公司内部普遍达标的标准,并以此标准作为参考对策略提出达标的要求。笔者工作的领域中使用是准召率,其中精准率用来判断模型的准确性,召回率用来判断模型覆盖的情况,这两者往往不可兼得、此消彼长。
  2. 通过过程数据了解模型最终落地的逻辑,在上线前确定无误,一定程度上起到质量控制的作用。

第二层是模型的业务价值评估。在大公司,业务价值的评估往往结合着小流量测试来做。

假设咱的卖瓜公司在北上广深都有业务,其中广州的业务体量最小,最适合做小流量测试。在广州分公司中有10几个销售组,那么在下发测试时需要选出测试的实验组和对照组。选分组也是有讲究的,需要两个组是同质的,而所谓的“同质”也没有唯一的判定标准,需要根据不同的项目和业务进行举一反三。我们假设这里的“同质”的关键指标是客户流失率(并且最好这两个组的客户数量、客户体量、组内的销售人员、维护人员等等都是相近的)。在以上都确定完毕之后,进行测试下发。测试结束后观察实验组相对对照组的数据提升情况,例如原来实验组和对照组的30%客户因为上面说的坏瓜问题而流失,而测试期间实验组的该项数据降到了15%,那么就可以初步判断这个项目是有足够价值的。

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

 

作者:霹雳,微信公众号:产品霹雳

本文由 @霹雳 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Pexels,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 棒棒 期待后续

    来自北京 回复