前滴滴出行产品经理刘飞：写给产品经理的说明书（下）

嘉宾介绍

刘飞，资深产品人，前滴滴出行司机方向前产品负责人，点我达前产品专家，嘟嘟美甲联合创始人，锤子科技产品经理。在知乎累计446579次赞同，224900人关注，“产品经理”话题下的优秀回答者。虎嗅网、36kr、雷锋网、人人都是产品经理、知乎等媒体专栏作者，通过“在行”平台线下帮助200余位产品学员进阶。开有公众号“刘言飞语”。

新书《产品思维》将产品经理工作中必须要面对的认知盲点和实践痛点掰开揉碎进行讲解，毫无保留地分享了产品新人迫切需要却很难在公开渠道获取的知识，现全网热卖中。

Q1. 产品经理如何在设计产品时避免给开发挖坑? 

1. 搞明白基本的一些技术背景和技术概念

产品经理需不需要懂技术是老生常谈的问题，我的回答是肯定要懂，关键在于，懂的技术是怎么样的技术。

懂技术并不是就要能自己成为架构师、自己成为工程师，又可以规划技术架构又能实现产品功能。懂技术是要明白技术实现的逻辑。

比如，我们在做的配送业务，需要有配送员、订单、商家多种信息，每种信息是存放在各自的数据结构里的，它们之间又通过逻辑关系串联起来。这些产品上都未必体现得出来，但在很多产品设计的时候要考虑到，要做某个新业务时，发现商家要分截然不同的两类，那中间的逻辑怎么样成本最低，是同一张表用属性区分、还是新造一张表，都是要跟技术一起讨论研究的。 

平时，也建议多看些技术相关的文章和科普。注意，千万不要买什么《七天掌握安卓系统》之类的书，看一些跟产品息息相关的比较好。

2. 学会梳理产品逻辑 

这个逻辑不是 APP 上有几个 tab 页，也不是功能之间简单的关系，说的是背后的几个逻辑：数据结构、信息流程和其它的逻辑关系。

然而我见到的很多产品经理，并不太把这个当回事。「只要给我实现就行了，我不关心怎么实现。」

数据结构其实是第一重要的东西，可以让产品经理非常深入地理解技术实现的逻辑。

比如，这是美团酒店销售的数据结构。可以让整个酒店商品的逻辑一目了然，而不是零散的需求。 

信息流程则是在有一个信息通路、存在一些状态转化逻辑的情况下，需要考虑的。比如常见的订单从生成到支付到结束的环节，如果也只是零散地提出功能需求，那很可能出现纰漏，技术实现上也不明晰。 

比如，这是嘟嘟美甲最初交互草稿里，我们梳理的订单状态转化图。

还有很多其他的逻辑，也需要梳理清楚。

比如，我们前段时间在设计取消订单机制的时候，发现有很多种情况，每种情况的文案也不应该一样，这时候就要梳理出每种具体的提示，不能让技术去帮你完善。

对于应该梳理什么、怎样梳理比较好，可以多问问程序员哥哥们的意见。如果他们看到你的文档，立刻就能想到该怎么实现，那就证明起到作用了。如果每次都要花费大量的时间拆解和讨论，那就是梳理得还不够。 

3. 出现坑的时候，多复盘 

不同的产品差异很大，即使再有经验的产品经理，也不一定就永远不会埋坑。

坑出现了之后，除了尽快填起来，还要去复盘，多想想，怎么避免下次再进坑。

如果是文档写得不周全，那就尽量写得周全些；如果是缺乏沟通，那就在协作时多设立沟通会；如果是需求总会变动，那就研究需求变动的根本原因，把它大事化小小事化了。

关于产品技术协作，在我们公司，是设置了一套复盘机制的。每次出现大的问题，都会在解决之后，召集一次大会，所有相关人员加产品和技术的总负责人都在场的情况下，把事情说清楚，搞明白原委，并且会上要制定解决方案。 

经过一两个月的尝试，我们发现，大多数的坑都是同样的原因，我们就重点攻克这个难点，慢慢让坑变少，原来的大坑也变小了。

Q2. 作为产品经理，你是如何分析和管理你的产品需求的？

下面是我的经验，我都写在新书《产品思维》中，在这里也简单讲一下，解决这个问题未必是只从需求管理来做，而是整体流程上把控。 

1. 获取阶段 

需求的来源有很多。业务越复杂，需求就越杂。一个淘宝，产品需求就可以拆分成分类、检索、排序、商品展示、营销活动、支付、配送、售后等等。

你的职级越高，也代表着身边人提需求的可能性越大。初入行的产品专员或助理，主要是得到被安排的任务；初级产品经理，需求来源主要是用户和上级；产品负责人，需求来源就要增加老板和其他相关部门；而作为老板，谁都可能跟他提产品需求。

所以在获取到需求这一时刻，就必须做一个判断，并且记录。如果不做判断堆在那里，等做的时候根本没办法梳理出头绪，可能大部分时间都在疲于折腾需求清单。记录当然是为了方便回溯。获取到的再小的需求也记下来，不要指望你随时能想起来每天听过的每个需求。

做判断的内容具体是什么呢？

第一，判断需求本身的重要性。

同样是页面写错了一个字，把「登录」写成「登陆」，和把「奖励 15 元」写成「奖励 50 元」，重要性不言而喻吧。有个大致的预估。 

第二，考虑需求来源。

需求来源会表明一些事情，要慎重思考。比如老板提到的，未必是目前你能理解的，但他认为特别重要，就暂且把这个当成特别重要的，这是政治任务。再比如是用户提到的，但细想他并不是目标用户，他的需求就不必太关注。

第三，简要得到需求背景。 

我自己工作中有三类需求绝对不记：没说清楚原因的，不记（你做个XX出来，别管那么多）；不说清逻辑的，不记（啊，这里我也没搞懂，你先看看）；不是实际遇到的，不记（哎，我觉得可能有人会这样用）。 

需求背景没搞清楚，完全是浪费时间。有一句话的记录，但不说背景，也是浪费时间。记的时候，我会确保格式是问题+方案，「XXX 在用我们的 XX 功能时，感觉 XXX，我们可以尝试 XXX 这样的方案」。 

最后，依据这三个因素，判断属于大致哪个类别的。一般的需求管理都会分 P0-P3 或者 P1-P4，总之先打个标签。这里的技巧是尽量标记为比估计的更重要一层的需求，就是你感觉是 P2 的，暂且先标为 P1。这样以防错漏，低优先级的标成高的没关系，但高优先级的标低了会出现麻烦。这时候的预估往往不准确，但没关系，等后面第二步再说。

比如这样： 

 2. 讨论/设计阶段

隔一段时间，我们会开需求讨论会，整理需求池，也就是记录所有获取到需求的表单。

我们会详细讨论每个需求的情况，确认几个事项：

一，需求的优先级

之前的判断是粗估，这里的判断就要精细了。一般需求的重要程度很难量化，尤其来源复杂的情况下。营销部门着急要我们配合做活动，不做就少赚好多钱，业务部门着急要我们配合做一套自动化结账工具，做了能节省很多成本... 有时抉择很痛苦。

这里还是用最常用的判断方法，紧急重要四象限法则：四象限法则_百度百科。重要程度大致按这种排序：

• 不做会造成严重的问题和恶劣的影响的

• 做了会产生巨大好处和极佳效果的

• 跟重要合作对象或投资人有关的

• 跟核心用户利益有关的

• 跟大部分用户权益有关的

• 跟效率或成本有关的

• 跟用户体验有关的

紧急程度按这个排序：

• 不做错误会持续发生，造成严重影响

• 在一定时间内可控，但长期会有糟糕的影响

• 做了立刻能解决很多问题、产生正面的影响

• 做了在一段时间后可以有良好的效果

大家把能考虑到的因素想全，会标上 P1 - P4 的优先级。

二，方案的方向

需求有不同的解决办法，我们会讨论清楚到底用哪种解决。比如我们发现有刷单现象，可以事前提醒，告知用户目前地理位置或订单信息有嫌疑；可以事中限制，必须到达指定地点、拍摄当地照片等等操作来限制用户；可以事后惩戒，提供给客服或者业务部门疑似刷单的名单和证据，罚款或者封号。这几项到底做哪个？还是做其中哪几个？优劣在哪？需要好好讨论。 

有时会有大概的方向，再去跟相关部门和需求相关的同事确认。这不在本文讨论范围内，暂且不提。

三，指定负责人

我之前经历过两种需求分配制度。一种是每个人负责的需求范围有清晰的边界，那需求对应哪个模块，就直接分配即可；另一种是团队作战，每次指定或者认领，谁都有可能接手任意需求。

前一种的好处在，模块清晰，负责人可以对自己负责的部分足够熟悉，但缺点是，工作量很可能不平衡，有的同事一直在忙，有的可能就比较闲，因为需求不是平均按模块分布的。

在我们需求分配时，大致还是按照模块分配，但在出现工作量不平衡的情况时，会酌情调整一下，让活少的同事予以配合。

不管怎么样，一定一定要指定负责人，他需要对需求负责，一直到产品上线后，出了的问题他也要承担责任。要保证运营良好的工作责任制。 

四、划定时间节点

许多产品经理会疏漏这点，只是觉得尽快去做，但总是做不完。

时间节点至少也要包括方案完成的时间。就是这个需求，能够完好提交给开发的时间。如果没有这个时间，对需求的管理就没有一点意义了。

另外，如果是要跟相关部门再确认、或者要跟用户调研、或者要统计各种数据再作判断的需求，那还要有调研/讨论完成的时间。

这个时间节点的划定，主要是按照方案的复杂程度，用经验做个简单判断。最长的时间周期也不能超过一周，保证需求的推动进度，因为很难有复杂程度超过一周的产品需求。对于有严格上线时间的需求（经常会出现，比如很苛刻的老板需求、投资人需求、政府需求等），要倒推出最合理又富有余地的时间节点。 

讨论完刚刚入池的一批需求，我们会再整理和讨论其它状态（有方案或者调研结论）的需求。这样会议结束，每条需求都会得到更新。

我们在这个时刻，一般会让负责的产品经理，及时更新需求状态给需求来源方。当然，来源方 95% 的情况下会对进度不满意，这很正常，但除非来源方有确凿的理由，我们不会轻易调整优先级和时间节点。 

3. 待开发阶段 

有了确切方案，我们会尽快跟研发的同事做可行性评审。这一步必不可少。我感觉题主出现的「落不了地」和「频繁更改」的问题，要着重在这个步骤里解决。

可行性评审上，完成的是对需求的大致评估，要做的有这么几件事：

第一，方案本身的可行性。

在技术方案上，是不是能够完成？就是让技术部门评估这个问题。

第二，有没有更好的方案？ 

一定要跟技术部门灌输清晰的需求背景，让他们也想一些可行的方案。方案未必是完整、准确的，但他们提供的思路，一般是可行性较高的。

第三，涉及的产品和技术环节有哪些？

这个需要相关的同事仔细讨论。尤其是很多公司产品线比较多，有可能存在牵一发动全身的情况，如果相关的产品同事和技术同事不知情，必然会延期，必然会扯皮，必然会造成麻烦，必然会有各种改动。即便是再小的产品，也要分前后端，让技术的同事来判断有哪些人需要知情和参与评估。

第四，方案的成本如何？ 

看方案需要多少人、多少资源、多少时间来完成，也要看方案在技术层面耗费的不太明显的成本，比如服务器成本、带宽成本，给用户造成的流量成本等。

有了这样的讨论，会议输出的，就是比较严谨的可执行方案（或草稿）了。

如果会上遇到各种问题，要确认解决问题的时间节点。

4. 开发阶段

开发需求的次序，我们不是完全按照需求池里的需求优先级来的。刚才说到，在可行性评估会上，我们会核算大致的需求成本，那成本结合需求的优先级，就可以得出需求的性价比了。 

大概是用这样的表格： 

提交开发之后，相当于关闭需求。原则上，本次迭代不再加入新的需求。

当然啦，如果什么事情都是原则上那样...就不会出现这么多扯皮的情况了。 

在开发中，扯皮的问题归纳起来就是三种：需求太多，没按时做完；需求有改动，导致了额外工作量以及开发的不满；有新的紧急需求，导致发布延期。 

这三种问题，再抽象一下，导致的原因很多，大概有几类，分别是：

 一，产品方案不完整

方案不完整往往是没有考虑全面。这个跟需求管理本身没关系，就是在出方案的途中，看能不能把事情想全。

之前我们经常出现，做的时候技术才发现卧槽这里有个逻辑没想通啊。然后喊产品来一起讨论的时候，大家发现需要加一些功能才能完善逻辑。最后结果就是周六加了个班，大家很不开心。

这种事情也不好追责，毕竟参与者很多，流程拖得很长。硬要说是负责需求的产品经理有问题倒也可以，但总是片面的：他也不一定知道技术上开发才发现的逻辑。 

后来我们反思，各个流程中的环节都要做一些调整，才能确保最终产品方案的完整： 

• 分析需求时，先梳理逻辑再出方案。能画流程图的画流程图，能画逻辑图的画逻辑图，能画脑图的画脑图，穷举整体的逻辑。

• 讨论方案时，所有产品经理参与小组讨论，一起提出疑惑，发现问题。

• 可行性评审时，技术从逻辑角度提出质疑，发现问题。

之后再出问题，会回溯原因。如果是前两个环节出的问题，那就是产品经理的责任；如果是产品经理未知的逻辑，那就是可行性评审中，技术的同事的责任。

二，需求方的主观改动

这种情况基本都是需求方或者产品经理的问题：他们在提交方案前没有完全想清楚。

有时候都开始开发了，业务部门来人说，哎我们发现这个问题好像不存在了，大家不要做了。他们觉得无所谓，还减轻了开发负担。但对技术部门的同事来说，就好像在说「你被耍了，哈哈哈」。造成的影响是恶劣的。

产品经理在对接他们的需求时要做判断，他们是不是完全想清楚了，是灵机一动的小点子，还是不得不解决的问题。

另外，还有一种情况，是需求方跟产品经理对接时出了问题。表述有误，并且方案没有跟他们核对清楚，结果产品功能上线，才发现并没有解决问题。

我们的做法刚才多少提到了一些：要在任何需求的属性（内容、时间点）发生变化时，跟需求方同步。让他们知道我们的情况，也获取他们的意见和建议。

比如这是我们的需求同步流程： 

三、无法预测的客观原因

这种是唯一一种能够接受的原因，不需要有谁承担责任。 

比如，本来要做一个功能狙击对手，结果做了一半，竞争对手倒闭了，那这个功能就没有意义了，确实要废除。

还有一些业务上的确无法预测的各种原因，导致原本存在的问题不存在了，也无可厚非。

这种情况下，产品经理最重要的是安抚技术的同事，尤其是跟他们解释清楚背景和详细的原因，不要让他们误以为是刚才提到的前两种理由。 

5. 复盘阶段

需求从获取到上线，走完生命周期之后，还要有一个很重要的复盘阶段，尤其是在需求管理出过故障和问题的时候。

略靠谱的团队，都会有复盘的机制，主要是防止问题再次发生。解决问题很简单，如何尽量规避下次再出问题很复杂。 

大致就是，要搞清楚之前出现问题的所有逻辑和流程，再去看在哪些环节可以做点什么，去防止再次出现。这块的内容说得多了又得写一篇文，就不多讲了。 

以上就是我的经验，仅供参考。没有什么流程和机制是完美的，关键在于怎么去解决自己的问题。如果哪些思路给你了启发，那就够了。

Q3. 产品经理如何给用户需求排序？

需求分析有两种核心的方法：定性分析和定量分析。我就从这个维度来解释下怎样对需求做判断。

1. 定性分析

1.1 KANO 模型

KANO 模型是现在大家都比较认可的方法。实际上，这个模型即使你没有系统学习过，也肯定对其理念有一定体会。 

那具体怎么区分这些需求呢？KANO 模型就是提供了这样的方法。

我这里用的是飞哥简化版，大概是这样的：

解释下这个图。

作为一个功能， 每行对应的是如果有的话，用户会开心、无所谓还是不开心，每列则是如果没有的情况。具体说：

矛盾：如果用户觉得功能存在和不存在都很开心，或者都不开心，显然是有问题的，所以说是矛盾的情况，是存在逻辑问题的，不予考虑。

错误：如果功能不存在让用户很开心，或者功能存在让用户不开心，那这个功能显然是错误的功能，不予考虑。

无关：如果功能存在和不存在，用户都觉得无所谓，那功能也就无关紧要了，同样不予考虑。

最重要的就是剩下的三类了：

必要：如果功能存在用户并没有特别的感觉，但不存在会不开心，说明这个功能是要满足基本需求的，也就是大家常说的『痛点』。 

期待：如果功能存在用户很开心，功能不存在用户很不开心，这就是满足用户最直接、最明显的需求了，是用户内心已有期待的。

惊喜：如果功能不存在的时候用户并没有感觉，说明这个功能用户之前没有预期，但功能存在用户很开心，也就是说达到了惊喜的效果。这就是小米常说的『惊喜点』，所谓让用户尖叫的功能。 

任何需求都可以分为『惊喜型』、『期待型』和『必要型』。大家考虑需求的价值，就要基于这三种来做判断了。

很多公司和产品利用的产品运营手法就是在满足后两种需求的同时，不断用第一种需求激活用户的热情、促使用户传播。

1.2 用户访谈

除了通过常识对需求做以上提到的判断，深度访谈可以作为配合，来验证之前的考虑。

访谈的时候尽量用开放性的问题来沟通，不要直接问『如果有这样的功能你会不会用？』、『你到底想要什么样的功能？』，而是了解用户背后的需求、TA 使用的场景以及 TA 过去满足相同需求的方法，这些信息能提供关键的证据，来辅助验证你的判断。 

沟通时，对同样的功能，也可以用多种问法来试探用户，以防用户不够理解；同时，也要反复对同一个功能做深入的探讨：『这样不好的话，那如果是那样呢？』『你觉得它不符合你要求的原因是什么呢？』再即时地做出反应，能获得更有价值的信息。 

2. 定量分析 

如果定性分析不能保证效果，那定量分析就可以获得更准确的信息，相应地，成本会偏高一些。 

2.1 数据获取 

数据获取有两种，一种是功能设计前获取一些能辅助做判断的信息，一种是功能上线后观察一些用户使用的行为数据。 

对于前者，具体方法很多，公开渠道、咨询公司或者调研都可以，就不展开说了。对于后者，关键就是观察用户是不是在用某个功能和在用这个功能时的具体行为。

很重要的还是：数据只是提供信息，做判断一定要经过逻辑分析。之前某老板说从大数据判断出去洗脚店和去医院看病的因果关系，让人跌眼镜，就是滥用数据做判断的典型例子。用户数据是最有价值的信息，但怎么用，是很讲究的。 

2.2 快速验证 

访谈的结果有时候不会特别可靠，快速验证是最重要的方式。具体方法有很多，包括大家常提到的 Demo 或者 MVP（最简化可实行产品） 或者灰度发布或者 A/B 测试都可以作为验证手段。 

其实大部分手段只适用于功能已经比较完善的情况下，也就是做事后判断，而不是事前的预测。

折衷的方案是：用最简陋的方式做一个满足需求的功能出来，投入到市场中观察用户的反馈，来确定功能的重要程度。如果用户反馈良好，就做得更完善、优化得更好用，反馈糟糕就砍掉。 

不过这样的验证可靠，但显然成本很高，要酌情使用，对于特别拿捏不定的可以用这方法，但如果每个需求或功能都用这套方法，其实意义就不大了。还是要通过更准确的判断来对需求和功能定性，从而节省成本。

最近我看过一个最有趣的快速验证方法，特别鸡贼，是国外的，可以参考。

他们在想检验用户是不是对他们的服务有兴趣时，并没有考虑做个简陋的 MVP，因为他们认为没有良好体验的功能版本并不能很好地检验，所以他们就做了个精美的官网、列举了他们要提供的所有的功能和服务、甚至支持真实支付成为会员。但是，他们没有做任何功能和服务。 

这是他们官网首页 

这是询问用户是不是要使用他们的服务。（做得跟真的似的......）

最后再告诉用户：都是假的，还没做好那。虽然都是假的，但用户真正来到了哪个页面、有多少关注这个服务、有哪些有付费意愿，这些数据是都拿到了。觉得靠谱接着做完，不靠谱就退款给用户，成本极小。

是不是很牛逼的方法？

Q4. 算法是不是产品经理应该考虑的问题？

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

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

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

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

1. 需求方提出需求。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大致来看，就是这样的：

从题主的描述看，其实有点像省掉了「需求抽象」和「功能设计」的步骤，认为这纯粹是个算法课题，需求来了就硬生生扔给研发，等待产品出炉了。我觉得这是不太合理的。

前文提到了，在点我达初期，实际上所有实现之前的步骤，都是由我一位同事完成的。这也是我推荐的方式。 

Q5. 如何看待「产品经理的时代正在慢慢结束」这个观点？

用我的话归纳下就是：人人都是产品经理的时代结束了，职业产品经理的时代开始了。

大家可以回忆下程序员刚出现时，每个码农都称得上是「全栈工程师」吧。当时很多项目开发流程并不标准，对品质的要求也不会太高，所以除了巨头企业，并不会分工太细。 

但十年过去，现在即便是一个小创业团队，也至少会分清服务端工程师、iOS 工程师、安卓工程师和 Web 工程师，不会轻易招一个安卓工程师来写后台，也不会找个前端工程师做手机端。而且显然对专业性方面的要求更高了。你不仅需要实现功能，还要保证代码不冗余；不光让代码简洁，还得有极强的扩展性。

两点：对领域的细分更多；对专业的要求更高。也正在产品经理身上发生。 

要证明这个论点，有这么几个论据： 

1. 互联网产品的类别越来越多、差别越来越大

过去的互联网产品，最早的巨头是清一色的门户网站。再后来，BAT 三分天下，开始走不一样的路。时至今日，全国有几千万个互联网项目在折腾，每个市场几乎都有互联网产品在觊觎。

最早的产品形态也很趋同，网站的形式简单、软件的形式也很简单，后台产品更不用说了，就那么几家。移动互联网出现后，产品之间越来越不一样。比如布局的方式，就有宫格、列表、边栏、标签等各种各样的。 

再比如对于线上社交的产品，和涉及线下服务的产品，产品逻辑也全然不同。

另外，由于业务需要，像后台产品，规模稍大些的公司，都不会用第三方。后台产品经理的需求也是节节攀升。更不用说其他比如 CRM、客服等内部使用的产品，自己招募团队完成，应该会成为常态。 

我并不觉得现在同质化严重。反而是每天都有新花样的产品出现、每时每刻都有新产品在挑战旧霸主。

从这个角度说，对产品经理的要求真的不仅仅是「想个主意」这么简单。

2. 用户的需求越来越杂、产品的复杂度越来越高 

相应的，随互联网发展，不仅是用互联网产品的用户多了，他们的需求也变多了。原本可能只是满足基本需求（能完成任务、做成这件事，专业说法是「可用性」），现在也要追求附加价值，比如是不是用着顺心、用着舒服、用这个产品的时候又快又好？

从诺基亚到苹果，飞跃的既是产品的复杂度，也是用户的需求。大家不只满足于「能够打电话」、「能够看照片」和「能够上网」，而是要「很爽地打电话」、「很爽地看照片」和「很爽地上网」。进一步说，大家还需要苹果手机本身给自己带来的光环加成，不然为什么买 6s 都选玫瑰色。

要解决这些问题，可不是工程师够多就行了。会需要更多牛逼的产品经理、更专业的产品经理，去满足大家日益增长的需求。 

试想下 10 年前我们使用互联网产品的心态，往往都是费劲心思一定要搞定，出了问题甚至会查攻略、给朋友打电话、向客服求助。现在呢？注册的时候多一个步骤，你就滚犊子吧。

这些也给产品经理更高的要求：要懂各种知识，要理解各种用户，要完成更难的工作。有个很简单的例子：很多老板觉得做产品经理很简单，自己去兼任，结果出来的产品都是惨不忍睹。

3. 产品经理将随互联网渗透进各行各业 

我之前提过，互联网在过去可以称得上是特有的「行业」，就跟旅游业啊、出版业啊、房地产业啊一样的概念。但未来互联网肯定是会渗透进各行各业的，未必是所谓「互联网 +」的形式，但未来人们看待互联网，不会把它当成是特殊的领域，而是会当成是谁都用得上的工具。 

现在的层面都还比较浅，但也有了雏形。只要是有点规模的公司、企业、单位，都在做自己的 APP，不管功能体验如何，这些 APP 都是产品经理做出来的。未来它们会起到更多的作用，道理很简单：过去的很多信息方面的记录、传递、处理，都是落后的。互联网就是解决这个问题的。 

比如我认识一个传统行业的朋友。他告诉我现在他们的记录和通讯方式特别落后，每个人平时工作都要拿厚厚的本子，整理的时间花去工作时间的大半。在需要拿到一些领导签字的时候也是无比麻烦，需要挨个去找，费时费力。这样的流程，未来必然是会被手机工具取代（在线记录、电子签名）。 

类似的行业有很多。只不过没有到时候。

就跟个人电脑普及之前，大家用的还都是手写表格、手写文档，觉得电脑是个新奇玩意儿一样。未来互联网工具普及之后，任何人都会对在手机上完成生活工作的大部分任务习以为常的。 

而这些产品、工具，都是要有产品经理去做的。

上面说的三方面，其实就是在表达「移动互联网并没有成熟」、「产品经理并不只是做创新」和「产品显然并没有在同质化」。 

综上所述，我觉得职业产品经理的时代刚刚到来。 

未来，产品经理可能会细分到「技术型产品经理」、「运营型产品经理」、「体验型产品经理」，或者按领域区分为「社交产品专家」、「后台产品专家」、「电商产品专家」等等。

产品经理也会有更成熟的培养体系和成长体系出现，在高校里产品设计、项目管理这样的课程会越来越多、更加专业。

整个行业，也会出现公认的教学著作和指导思想，产品方面的知识不再是零散的、虚无的或者有些模棱两可的（看看张小龙被解读成了什么样子吧...），而是逻辑自洽、经过实践检验的、屡试不爽的。 

那时候，可能就不会有人对产品经理有这么深的误解了吧。至少不会觉得产品经理就是每天在想 idea 的人吧？

PMCAFF问答专场是一场与PMCAFF用户互动的问答活动，我们每期都会邀请知名互联网公司的一线产品从业者和咖友们共同交流，目前已成功举办过60+期，先后有来自腾讯、百度、阿里、360、小米、京东、去哪儿等大厂嘉宾入驻。

这个世界问题太多，我们需要一个能够解决问题的人。

如果你有足够的能力解决来自PMCAFF用户在你的专业领域中，以不同的角度提出各类刁钻问题，那么欢迎你参加PMCAFF问答专场。

活动申请可以添加工作人员微信沟通咨询，加好友请备注：问答专场。