如何做一名AI产品经理

AI这个概念在这几年都非常火，风口之下，有许多人都想跻身这个领域，成为一名AI 产品经理。笔者通过自身经验告诉我们，想要做一名AI 产品经理，系统掌握数学和算法知识是必备步骤之一。

AI（Artificial Intelligence，人工智能）这个词对大家并不陌生，甚至已经泛滥了。任何产品、任何项目、任何公司和AI沾上边似乎就会显得很高大上，可以“讲故事”。

之前参加过几次会议，有观众现场问到关于产品经理的一些问题时，大家比较关注的是——“产品经理的职责范围是什么？”“如果没有技术背景，能不能做产品经理？”“AI产品经理是不是一定需要有丰富的AI知识？”等问题。

结合这些年AI的发展趋势，对AI产品经理的需求也有所增多。今天这篇文章，就讨论一下“如何做一名AI产品经理”这个话题。也算是自己工作这些年，结合自己的知识和经验，提出自己对于“如何做一名AI产品经理”的一些观点，就当是是抛砖引玉，欢迎大家多多交流。

一、现状

如何做一名AI产品经理，很多想转型做AI产品经理的朋友们，估计也没有一个清晰的感觉；而如何招一名合适的AI产品经理，可能在很多公司在招聘时也会存在一定困惑，也不知道如何清晰地定义。我自己也观察了一些企业招聘AI产品经理的职位需求，似乎也没有说到关键点上，只是强调，要求有BATJ经验，似乎通过BATJ这些大厂的认可，自己招过来就一定合适。

这是存在一定误区的。

BATJ里的确有非常优秀的产品经理，但还是占少数，大多产品经理只是这些大厂众多产品的一个小螺丝钉而已，只是负责产品很小的一个点。而那些掌控全局的大厂产品经理，是非常昂贵的。

不是说企业要求有BATJ经验，你就一定能招到BATJ的人；招个BATJ普通的产品，不一定比在小企业的产品经理能力强。所以招到合适的才是最好的。接下来还是从实战的角度出发，来分析一下如何做一名AI产品经理，一方面解答想从事AI产品经理的朋友们的疑问，另一方面也可以解决企业在招聘AI产品经理所存在的困惑。

二、实战

1. 产品功能点描述

假如你所在的一家企业是一家外卖平台，你的领导和你说：

“我们看到XX外卖智能配送调度做得不错，我们现在通过人工派单效率太慢了，而且随着业务的增长，要不断新增人力，我们也需要做一个智能调度的产品，实现高效派单，提升配送效率，节省运营成本。这个事情就交给你来负责了，你就是这个智能调度产品的产品经理。”

你接到这个任务打算怎么做？

一般来说，我们准备做某个产品时，肯定要做一下可行性分析，技术可行性、经济可行性，看一下市场，做一下竞品分析。写BRD、写MRD。然后用一大堆数据，将论证过的评估结果呈现给领导，以便于给公司管理层做决定——产品是否继续推进。

各领域的产品经理的这个过程都差不多。以我们实战为例，这个产品肯定是要做了，这时产品经理更多要考虑的，就是要如何尽快落地。

如何尽快落地，就到了这款AI调度产品的设计工作。这个阶段的工作产出就是PRD了。

一般行业的产品经理写PRD，更多的是熟悉业务，把业务流程梳理清晰，画出原型，再把每一个产品流程细节和逻辑写清楚就可以了。

产品经理的工作，无非是梳理业务流程、画画原型；需求评审完成；再推进一下开发；然后SIT、组织UAT；上线；投产后观测。说是产品经理，其实更像是BA（Business Analyst，业务分析师）。工作内容比较简单，稍微复杂点的，看看业务数据，不断通过迭代来完善产品功能。

而上述产品经理，在今天的场景下，明显就不能胜任了。

领导让你设计一款AI调度产品，你就画几个原型；和软件开发工程师说，就按这个来，但具体怎么调度，是什么逻辑？开发也不知道。那产品怎么推进？这样就很容易造成产品失败。所以，你在梳理业务的同时，你要在PRD里详细描述出调度的计算逻辑，你可以不懂编程，但一定要把计算逻辑写清楚，这样软件开发工程师可以把逻辑转化成程序代码，从而实现产品功能。

计算逻辑怎么写？这个时候是不是就需要你有AI知识？AI知识归根到底是数学知识。这就用到最优路径规划的知识。我们设计的AI调度产品，希望通过给定的派送到目标点数量以及到达每个派送目标点之间的距离来计划出最优路径。

产品逻辑描述就是：

输入：派送目标点数量，源送目标点间的距离
输出：最优路径

为了便于大家理解，我们用个简单的场景。

假如一个派送员在位置1，要到3个地点送外卖。如下图1各派送点距离所示，自己简单用PPT的画图版画的，比较丑，不过意思到就OK。各地点间的距离也在连线上进行了标示。

图1 各派送点距离

我们接下来要实现的就是派送员路径最优。我们要把这个计算逻辑写到PRD中，这样开发工程师就可以根据我们定义的逻辑，实现AI智能调度中的最优派送路径，系统就可以对派送员的派送路线进行最优规划。从之前的由人来调度，实现了机器智能调度。不仅速度快，还比人工计划外送员的派送路径更优。

我们可以将派送员的派送路径，看作是一个n元组。我们的实战中的情况，所以步骤可以表示为：{X1，X2，X3，X4}。如果我们把这个转化成一棵排列树，如下图所示：

图2 派送路径树

X1=1表示第1步在编号为1的地点，X2=2，表示第2步去编号为2的地点，如果X2=3，则表示第2步去编号为3的地点。

上图便列出了派送员可去派送目标点的所有路径。

我们如何来描述呢？这就用到了大学时数学中的矩阵。

我们定义一个矩阵：P[ i ][ j ]，如果一个点 i 到 j 有边，则 P[ i ][ j ]=<i , j>。

例如：从图中的点1到点2，距离是16，则有边；而点1到点1，我们认为是没有边的，则为0。按照这个逻辑，我们生成如图3路径的矩阵表示所示：

图3 路径的矩阵表示

根据矩阵的显示，我们是不是一眼就可以看出哪条路径最优了？因为是数据量比较少，而现实中的场景肯定比这个复杂的多，一个派送员可能在一段时间内会接到数十个派送任务，而派送员也不可能只有1个。还是需要计算机来完成，所以，我们需要把业务逻辑转变成软件开发工程师可理解的描述。

一般产品经理写到这一步，可以直接在文档中描述，使用最优路径原则，从而忽略这一块的细节，具体实现由软件架构师在技术文档中体现。但有个问题是，最优路径有多种实现方式，产品经理如果希望对自己的产品知其然也知其所以然，要尽可能地对自己产品的功能特性的颗粒度掌握得更细致一些，这样在今后产品功能的扩展和再升级，会更加自信，更加游刃有余。

对于我们这款智能配送调度的实现逻辑，我们在PRD里可以这样描述：

前置条件：每次派送完整的路径中，去过的派送点不再去，不走重复的路线。

STEP1：定义矩阵P[ i ][ j ]，如果一个点 i 到 j 有边，则 P[ i ][ j ]=< i , j >，否则P[ i ][ j ]=0。

STEP2：设当前走过的路径长度为 PL，当前最优路径为BP。

STEP3：第一步从点1出发，借助辅助结点P，生成结点A，则X[1]=1，从A点出发，则 PL=P[1][1]=0。到下一派送目标点，若我们的派送目标点为2，则X[2]=2，所以PL+P[1][2]=0+16=16，PL=16 ，有效，因此生成目标点B。

STEP4：B点对应的是“图1 各派送点距离”中的点2。然后从B点出发，到下一个派送目标点3，则：PL+P[2][3]=16+6=22，PL值更新为22，即PL=22，有效，因此生成目标点C。

STEP5：C点对应的是“图1 各派送点距离”中的点3。然后从C点出发，到下一个派送目标点4，则：PL+P[3][4]=22+3=25，PL=25，有效，因些生成结点D。

STEP6：根据我们的前置条件，从D点直接回出发点1，则：PL+[4][1]=25+9=34。这时的最优路线：BP=PL=34。找到第1条派送路线。

STEP7：之后，从生成的D点开始回溯到C点，C点满足条件的路径只有到达D点这一条，于是继续回溯至B点，B点之前是到C点（派送点3），发现B点可以至派送点4，即从B点出发，到下一个派送目标点4（结合STEP3中PL的值），则：PL+P[2][4]=16+10=26，PL值更新为26，即PL=26，有效，因些生成结点E。

STEP8：从结点E（派送点4）这时满足条件的只有到派送点3，然后从派送点3回出发点1。因此：PL+P[4][3]=26+3=29，PL值更新为29，即PL=29，有效，因些生成结点F。

STEP9：从F点（派送点3）回出发点1，则PL+P[3][1]=29+20=49， PL更新为49。找到第2条派送路线（PL=49），但是大于之前第1条派送路线（BL=34），因此，最优路线BP仍然等于34。

STEP10：从F点（派送点3）回溯至E点（派送点4），没有满足条件的路线，继续回溯到B点（派送点2），没有满足条件的路线，继续回溯到A点（出发点1）。

STEP11：从A点（出发点1）到派送目标点3，则 PL+P[1][3]=0+20=20，PL值更新为20，即PL=20，生成结点G。

STEP12：从G点到派送目标点2，则 PL+P[3][2]=20+6=26，PL值更新为26，即PL=26，生成结点H。这时派送员在派送目标点2。

STEP13：从H点到派送目标点4，则PL+P[2][4]=26+10=36，PL值更新为36，即PL=36，生成结点I。这时派送员在派送目标点4。

STEP13：从I点回出发点，则 PL+P[4][1]=36+9=45。找到第3条派送路线（PL=45），但是大于之前第1条派送路线（BL=34），因此，最优路线BP仍然等于34。

STEP14：以同样的方法，进行回溯，回到结点G（派送点3），PL=20，派送点3之前在STEP12派送目标点是2（结点H），这次到派送目标点4，则：PL+P[3][4]=20+3=23，即PL=23，生成结点J。这时派送员在派送目标点4。

STEP15：从H点到派送目标点2，则PL+P[4][2]=23+10=33，PL值更新为33，即PL=33，生成结点K。这时派送员在派送目标点2。

STEP16：从K点回出发点，则 PL+P[2][1]=33+16=49。找到第4条派送路线（PL=49），但是大于之前第1条派送路线（BL=34），因此，最优路线BP仍然等于34。

STEP17：从K点（派送点2）回溯至J点（派送点4），没有满足条件的路线，继续回溯到G点（派送点3），没有满足条件的路线，继续回溯到A点（出发点1）。

STEP18：继续探索新的路线。从A点（出发点1）到派送目标点4，则 PL+P[1][4]=0+9=9，PL值更新为9，即PL=9，生成结点L。

STEP19：从L点到派送目标点2，则 PL+P[4][2]=9+10=19，PL值更新为19，即PL=19，生成结点M。这时派送员在派送目标点2。

STEP20：从M点到派送目标点3，则 PL+P[2][3]=19+6=25，PL值更新为25，即PL=25，生成结点N。这时派送员在派送目标点3。

STEP21：从M点回出发点，则 PL+P[3][1]=25+20=55。找到第5条派送路线（PL=45），但是大于之前第1条派送路线（BL=34），因此，最优路线BP仍然等于34。

STEP22：以同样的方法，进行回溯，回到结点N（派送点3），再回到M点（派送点4），PL=9，派送点4之前在STEP19派送目标点是2（结点M），这次到派送目标点3，则：PL+P[4][3]=9+3=12，即PL=12，生成结点O。这时派送员在派送目标点3。

STEP23：从O点到派送目标点2，则 PL+P[3][2]=12+6=18，PL值更新为18，即PL=18，生成结点P。这时派送员在派送目标点2。

STEP24：从O点回出发点，则 PL+P[2][1]=18+16=34。找到\第6条
派送路线（PL=34），但是等于之前第1条派送路线（BL=34），因此，最优路线BP仍然等于34。

流程结束。为了便于更直观地理解这款AI调度产品的路径规划逻辑，我们以如下图4 路径规划树所示：

图4 路径规划树

这样一梳理，是不是把这款智能调度产品的一个派送规划的一个功能点逻辑描述清晰了？

接下来，软件开发工程师就可以按这种逻辑思路编写代码进行实现了。逻辑描述清晰后，接下来要详细定义这款产品的输入和输出了，以上的逻辑描述，我们只选取了3个派送目标点，而现实中的派送目标点，一定不上3个，所以派送目标点是一个输入。另外，每个派送目标点距离当前派送员的距离也不一样，因此距离也是一个输入点。

综上，智能调度这款产品这个功能点的输入就是派送目标点的个数，和派送员到各目标点的距离。输出就是派送路线规划。

2. 不足之处

以上仅是一个实战的举例，场景考虑的比较少，功能也比较局限。现实中的智能调度，输入参数的维度很多，除了派送员当前位置、派送的目标点，还有派送员的数量、派送员的运力。而且很多参数是实际调整的。有些时候，智能调度为派送员虽然规划出了最优路径，但存在派送的货物已经超过派送员的运送能力，也是会导致规划失败。

作为产品经理需要做的是，把这些现实中的场景考虑清晰。必要时，需要去现场进行调研。身临其境感受一下，这样设计出来的产品才能更符合实际用户需要，才会更接地气。而现实中的大型产品，一个产品经理肯定是不够的，需要各产品经理和各领域专家通力协作的结果。

所以这又就提到了文章之前所讲的，除非你在BATJ的产品岗位是总负责人，才能感知整个产品的全貌，进行产品整体的设计；然后各模块的产品经理依照设计要求，把自己负责的模块完成，最终形成一个大的产品PRD。

如果不是充当产品负责人和总设计师的角色，每个模块的产品经理，也只负责一小块产品功能而已。从这个维度来看，就不如小公司的产品经理负责的多。小公司的产品经理，往往一个人就会负责一个条线的产品，产品论证、产品设计、PRD编写、产品上线、运营推广、数据分析、项目管理，基本上都要亲力亲为。虽然没有BATJ背景镀金，但水平也不差。

因此，企业在招聘产品经理时，更多的是要聚集于工作本身，自己要明确需要什么样的产品人才。

而本文的不足之处也在于，没有把工作背景讲清楚。因为公司规模大小，同样的产品实战，做法是不同的。

如果你的公司规模比较大，各专业领域人才比较多，大家分工明确；如果你是这款智能调度产品的产品负责人，你的PRD就不必要写这么细，而是把总的PRD框架写出来，涉及到具体的实现，由公司里的专业人士来补充完善。

如果你的公司规模比较小，你是这款智能调度产品的产品经理，领导需要快速看到结果，你可以采取MVP（Minimum Viable Product, 最小化可行产品）的方式实现。就可以按文中的这种产品功能颗粒度很细的写法，先实现一个基本功能，然后再不断扩展。

3. 结果

其实按本文的实战，产品逻辑定义清晰后，就可以对产品的原型进行设计了。

定义一些功能交互的接口，从每个派送员的终端获得派送员的位置信息；根据我们的智能调度的计算，把行驶路径下发到每个派送员的终端中，然后派送完成的派送员向智能调度的反馈，然后就可以继续接收派送任务。这样，我们一个简单的AI智能调度产品就OK了。

三、总结

结合本文的实战，相信大家已经对如何做一名AI产品经理有一定的理解。AI产品经理具备基础的AI知识肯定是有必要的。这就是为什么有些产品经理的岗位叫AI产品经理，而有些则叫金融产品经理，其实就是以在这个领域的专业知识所区分。

产品经理是一个不断学习的过程，而且产品经理的成长，除了自我驱动以外，也离不开企业的支持。因为任何一款爆品的出现，背后一定有数百个初级产品。如果你所在的企业，根本不重视产品研发投入，靠产品经理个人的力量，也是很难有所作为的。像类似于MUJI这样的企业，比较重视产品并成立了生活研究所，曾发起一个“享受清洁”的研究课题，用了8个多月的时间同顾客一起思考这个问题。

而现实中，大多数公司不会有关于产品的研究部门，大多数技术驱动的公司，产品经理也没有什么话语权，往往充当着BA的角色。

其实好的产品，是需要花时间去研究的。这就像制药行业的新药研发一样，需要数年数十年可能都不会有结果。互联网的产品周期虽然不像制药行业时间那么长，但至少也要花时间去研究。

而互联网产品的研究，通常不会给太多的时间，太多公司不论是初创期的还是成熟期的，都会多少存在这个问题。技术部门加班加点，产品辛辛苦苦做出来了，发现没有市场，产品卖不出去。所以企业需要对产品经理的工作有所重视，在公司投入宝贵的时间和金钱之前，迅速进行机会评估，找到目标市场和目标客户，明确产品定位和产品需求，这样会极大提高产品成功的可能性。这也是产品经理的价值所在。所以这也就解答了，企业如何去招一名产品经理的问题。

在碎片化知识到处飞扬的今天，产品经理更要沉下心来系统学习一些基础知识。

理论上，三年的时间差不多如果钻研一门技术，博士都快毕业了，为什么大多数人在工作岗位三年的时间，还是毫无建树？归根到底，还是没有努力。工作了一天，回家肯定是休息休息，看看电视，玩玩手机，打打游戏。谁还愿意花时间再去刻苦钻研？所以这就造成了大多数人工作三年，不是有三年的工作经验，而且同样的工作重复了三年而已。

所以，如果你现在已经是一名AI产品经理，需要将某个领域的知识钻研得更深刻一些；如果你准备去从做AI产品经理，就需要将数学和算法知识系统性地学习一下。

当然，这是进阶流程，前提是产品经理的基本知识你已经掌握。

以上是个人的一些建议，可能大家也有不同的看法，也欢迎大家一起交流。