产品经理是否该考虑算法？

2017-03-27 10:14:00

算法是不是产品经理该考虑的？作者答曰：是。

知乎上有个问题如下：

经常被研发同事问倒，这个功能应该怎么做呢？算法问题应该是实现层面的问题了，不知道各位在实际过程中的经验是怎么样的。其实职能本来没有一个特别清晰的界定，但是一定有最效率的方式。这么说太虚了，举个例子，比如，产品需要根据用户添加“喜欢”的内容向用户推送用户喜欢的内容，就是一个“猜”的功能，那么这个猜出来的内容是怎么算出来的，这个算法。

我的回答是：

去年在点我达，我接手了调度模块的设计，有几个月时间一直在搭建产品框架和协作流程。在此之前，调度的产品、算法以及除了开发的方方面面，都只由一个同事负责。

与此同时，公司成立了算法研究院，请来了机器学习相关的博士，负责以调度为主的各项算法的设计。

于是原本从接受需求、设计功能，到研究算法、跟进实施的步骤，拆分成了两块：我带的调度产品组负责调度产品，而研究员团队负责调度算法。

现在的协作流程大概是这样的：

1. 需求方提出需求

例如，运营的同事认为，鲜花订单的派单形式要有新的产品和算法支撑。这里讲一下背景。我们的即时物流平台会有外卖、商超、快递、鲜花等一系列类型的订单，其中外卖订单是比较核心的，我们做的也比较久，因此很多产品模块包括调度的设计，都是适应外卖场景的。当时鲜花则是相对新的业务。

2. 产品经理承接需求，并抽象

我们小组的同事小 C 接到了这个需求，于是跟运营的同事多次沟通讨论需求背景，以及跟相关的其他同事（比如销售、商务的同事，以及骑手）确认实际场景。最终，抽象出算法问题。

比如，以下就是典型的算法问题描述：

在时效要求不高（以天为单位，而外卖是 1 小时内送达）、起点集聚终点分散（外卖的起点终点都是分散的）、每个骑手可携带鲜花订单数量为 n （外卖的上限 m < n）的前提下，应该如何基于外卖调度逻辑来设计鲜花调度逻辑。

3. 算法研究员承接算法需求，解决算法课题

算法研究员常博接受了算法需求，于是会把产品经理的描述再抽象一层，变成约束条件下的最优派单策略。以这些可量化的指标，就可以搭建起算法模型，依据已有的历史数据，来跑出最合理的算法策略以及相关的参数设置。当然，在此过程中，不免会与小 C 和运营的同事持续沟通，有许多策略涉及的因素，比如在产品逻辑中的耦合性、比如在具体业务场景中的合理性，都要做大量探讨。

像下图就是典型的算法描述（是我们已弃用的一个算法）：

4. 产品经理整合算法模型成为产品功能

此后，小 C 会考虑模型的细节，然后就跟把引擎装入发动机一样，设计出模型相关的配套产品功能。真正的需求文档会是算法文档长度的几倍甚至十几倍。后续就会跟技术协作，跟进研发。过程中也是会跟常博经常沟通，但在此阶段负责人始终是小 C。

这种协作模式可以算是一种可参考的模板。我们运行了半年多，一直没有问题，而且双方的协作极少有模糊地带。

那么回到题主的问题。可能现在没有专职的算法研究员，那么产品和研发直接协作该怎么办？

就推送喜欢的内容这个需求来说，首先，需求的目的、背景是产品经理要搞清楚的。推荐这些内容，是为了什么？浅显的目的是为了让用户点击，那背后相关的需求是什么？是现在用户活跃度比较低、是用户发掘优质内容的路径过长，还是并不清楚老板说好像大家都有那就做吧？

其次，最关键的，需求的实现方式是产品经理要搞清楚的。需求和算法是两个层面的事情，作为产品经理不能丢给研发说「做个推荐」就行了。显然，推荐不是一种具体的算法课题。就好像告诉研发说「做个个人中心页面」一样不具体，这个页面应该有什么、要达到什么效果，跟其他功能的逻辑关系……都是产品经理要考虑的。

就推荐来说，是基于什么数据做推荐呢？用户的历史浏览、用户的已有关注、用户的资料画像，还是用户的社交关系？即使作为产品经理，你不清楚基于规则、基于内容和协同过滤都是什么概念，你也要知道推荐不是凭空做的，是要根据具体的数据做分析的。

一个合理的梳理结果就像前文提到的，应该是类似于：「基于用户已有关注对象的类型和这些对象发布内容的特征，来推荐更多同类的关注」或者「基于用户目前的社交关系和相关的互动情况，推荐更多他可能喜欢的用户」。

再之后，是跟研发搞清楚，所给出数据的意义（比如相关因素的权重），以及沟通逻辑上的合理性。比如，拿基于社交关系的推荐来说，用户 A 给用户 B 经常点赞意味着什么？用户 A 跟用户 C 每周有 15 次互动意味着什么？用户 A 拉黑了用户 D 意味着什么？这些不是算法课题！这些是产品经理应该以自己对用户或主观或客观的感知，得出的功能判断。

然后是建模。在这里确实有一个模糊地带，如果是非常懒的研发，不愿意自己研究算法课题、自己建模，是有点尴尬。在职责划分上，坦率地说有计算机背景的研发做建模和算法研究会更合理一些。但如果是我，我会很开心有往前多走一步的机会。如果把这件事做好，就相当于多了一项不错的核心竞争力（可以想象未来懂算法、懂机器学习的产品经理会越来越吃香），也许会大大有利于你在公司甚至未来市场上的竞争力。

即使是你并不想有这项核心竞争力，在争执不下的场景中，我也建议你暂时把这个任务做起来。毕竟产品经理是要为产品的方方面面负（tian）责（keng）的，产品因为任何问题没有如期完成，产品经理都跑不了。

接下来就是根据建模的结果，梳理功能了。推荐当然不是简单的建模而已，具体什么时间节点收集用户信息？在什么功能模块下推送给用户？推送的数量有没有限制？展示交互和界面都是怎样的？这也都是产品经理要整理好的。

最后，具体用什么样的代码、什么样的系统框架来实现，那就是研发的事情了。

大致来看，就是这样的：