一个故事

有个段子，把产品经理改需求做了形象化类比（内容来源于网络，部分有修改）：

你=用户，服务员=产品经理，大厨=程序员

原始需求

你去饭店，坐下来。

用户：“服务员，给我来份宫保鸡丁”

产品经理：“好勒！”

中途需求变更

厨师做到一半。

用户：“服务员，菜里不要放肉”

产品经理：“不放肉怎么做啊？”

用户：“不放肉就行了，其他按正常程序做，不就行了，难吗？”

产品经理：“好的，您稍等。”

改动太大，部分重构

厨房

产品经理：“用户说菜里不要放肉了”

程序员：“你大爷．我肉都回锅了”

产品经理：“顾客非要要求的，你把肉挑出来不就行了吗‘

程序员：”行你大爷“

然而还是一点点挑出来了

低估改动成本

餐厅：

用户：“服务员，菜里能给我加点腐竹吗？ '

产品经理：“行，这个应该简单。”

新需求引入了新研发成本

厨房，

产品经理：“用户要加腐竹”

程序员：“你 TMD ，不知道腐竹得提前泡水？ 炒到一半才说？跟他说，想吃腐竹就多等半天“

产品经理：‘’啊你怎么不早说？”

程序员：”早说你大爷，我怎么知道他想要往宫保鸡丁里放腐竹”

然而还是去泡腐竹了

某一功能点摇摆不定

餐厅，

用户：“服务员，还是把肉加回去吧。”

产品经理：“您不是说不要肉吗？”

用户：“现在又想要了”

产品经理：” … 好的您稍等”

甲方是大爷

厨房，

程序员：“日你啊，菜都炒过火了你让我放肉？还好肉我没扔”

产品经理：“客户提的要求啊，我也没办法”

程序员：“你就不能拒绝他吗？啊？”

产品经理：“人家是客户嘛。”

改动开始导致工期延误

餐厅，

用户：“服务员！服务员！”

产品经理：“来了，来了，您好”

用户：“怎么这么慢啊”

产品经理：“稍等，我给您催催啊”

开发者请求重新排期

厨房，

程序员：“催催催，就知道催，腐竹没泡好，还得重新放油，他想吃老的也行，没办法保证质量。”

甲方催活

餐厅，

产品经理：“抱歉，加腐竹的话得多等半天，您稍等哈”

用户：“我去，要等那么久吗？我现在就要吃，你们能快点吗？”

产品经理：“行…您稍等。”

开发者开始和中间人PK

厨房，

程序员：“他大爷，逗我玩呢，中间改需求还想那么快，不可能。”

产品经理：“那我问问，能不能让他换个菜”

程序员：“再换我就死了。”

因工期太长再次改动需求

餐厅,

用户：“服务员，这样吧，腐竹不要了，改成黑木耳能快点吗，再加点番茄酱”

频繁改动导致大量冗余

厨房，

程序员：“你TM知不知道黑木耳也得泡水，还有热菜怎么加番茄酱？？”

产品经理：“没泡好的黑木耳吗？番茄酱往里面一倒就好了，很难吗？”

奇葩需求

餐厅，

用户：“服务员，菜里加了茄丁没有，其他饭店都是有的。”

产品经理：“好好好，您稍等”

奇葩需求也得做

厨房，

程序员：“去他二大爷的，宫保鸡丁里放茄丁？”

产品经理：“茄丁炒好了扔里面不就好了吗？”

程序员：“那这叫菜吗？”

产品经理：“客户需求，你就炒了吧。”

程序员：“NND，你问问他腐竹还要不要了，这腐竹还占我地方”

黑暗前的最后黎明

餐厅，

用户：“服务员，还要多久能好啊”

产品经理：“很快，很快”

用户：“再给我来杯橙汁”

产品经理：“…好，”

用户：“我再等10分钟，还不好我就走了，反正也没给钱”

产品经理：“很快，很快啊”

最终决战

10分钟后

用户：“咦，我上次吃的不是这个味道啊”

从厨房杀出来的大厨：“我TM就日了你狗”

故事最终的结尾，是开发着刀来坎用户了，而实际工作中，应该是开发在厨房早就把产品经理肢解了。

从表面上看，这是个用户提奇葩需求的故事，实际上是一个不合格产品经理引发的悲剧。

因为这个产品经理从头到尾做的工作就是个传话筒，把用户的需求原模原样转达给开发。由此可见，该文的作者认为，产品经理的工作也就是个传话筒。因此，我推测这个故事大概率是程序员写来黑产品经理的。

回到故事，如果是一个优秀的服务员，当客户点菜想要宫保鸡丁的时候，应该怎么反馈？

1.您有什么忌口吗？
2.听口音您是北方人，宫保鸡丁有南北方两种做法，给您按照北方口味做，加点茄丁怎么样？
3.您有什么特殊口味偏好吗？
4.你主食要米饭还是面食，酒水饮料有需要的吗？

客户回答：我最近减肥，别放肉。腐竹吃起来口感像肉，可以加点腐竹。
产品经理：好嘞，你主食吃什么？需要酒水饮料吗？最近有新上的使用网红褚橙鲜榨橙汁，卖的特别好，客户都点，您要不要品尝下？
客户：主食米饭，来一杯橙汁。
产品经理：您稍等，马上好。

产品经理到厨房：
做一份宫保鸡丁，少油，不要肉，加腐竹和茄丁，加肉精粉。

作为一个合格的服务员，应该弄透彻客户想吃什么，不想吃什么，潜在想吃什么，配套可以多吃点什么。然后加工成最合理的做菜方案传达给厨房。

作为厨房，做的菜稍微奇葩一点，只要在大厨能hold住的范围内，大厨只会吐槽一下客户奇葩，但是只要没有返工，与服务员的合作还是可以非常顺畅的。

产品经理的价值

上面的故事，可以类比互联网公司接B端客户需求的场景。

在互联网的工作流程里，产品经理就是有需求的人和实现需求的人之间的接口人。若接口人只是传话筒，公司找个服务员来就行了，何必花那么多钱找产品经理呢？

作为接口人，应该体现接口人在接口层面的核心价值，总结一下应该包括：
1.明确客户要解决的问题
2.拨开问题表象，抓住问题本质
3.设计最合理的解决问题的工程方案
4.将方案明确传达给开发，跟进并验收方案的实现效果。

其中，第一步是最根本的。

我曾经中途接手过一个低水平产品经理负责的后台数据产品。在web控制台上，有十几个菜单，在花了一个月的时间的研究之后，我终于认识到这个产品的十几个菜单几乎是没有任何关系的，甚至某些功能点还有重复。众多功能点中，有一个叫“自助取数”。其功能的使用流程是：
    1.使用人先去数据库工具中找到数据库里的表名
    2.在web后台填入想要取数的表
    3.在web控制台选择列然后加上过滤条件把数据取出来。
初一看，除了有点脱裤子放屁的感觉，问题也不太大。第一个从数据库里把表找到，导入到web控制台之后，后面的人就可以不用到数据库里找表了。当然前提是后面的人能直接从导入的表名清晰的知道该表的内容。

但是仔细研究后，我发现问题很大。之前的产品经理说，这是客户直接提的，所以就给做了。

然而，我从客户那里了解到，事情背景是这样的：客户本来提了个需求是，把可视化部分的数据能导出。产品经理询问开发后，开发说导不出来（原因比较特殊），所以产品经理就给客户答复说做不了。于是与客户沟通后，问能不能把表导入web控制台，然后再web控制台导出表里的数据？客户同意了，于是就有了了“自主取数”的功能。

而客户需要把数据可视化的结果导出的原因是：
1.需要把可视化的结果导出到excel后进行一定的加工后发给他们的客户。
2.导出部分明细数据用于后续运营等。

这两个问题继续探究，
对于问题1，在客户与他们的客户签订的合同中，包括数据服务。也就是客户必须为他的客户提供必要的数据报表。
对于问题2，当时要解决的问题是，某些特殊用户的特殊设备需要升级为特殊的版本，需要在数据平台找出来这些设备，导出后给设备OTA后台。

也就是说，其实客户想解决的问题是：
1.当前web控制台的数据对外共享给自己的客户。
2.数据平台的结果用于业务运营

所谓“自助取数”是客户根据自己的理解提了一个“需求”后发现不被满足而妥协的一个“需求”。

这里合理的需求，应该是：
1.数据图表的可控分享
2.数据平台的表提供下钻到明细层的能力。
3.数据平台对外提供开放接口工业务平台调用。

所以，第一步是最关键的。前面错了，后面做的越多越错。做到越多越是资源的浪费，进而导致后面纠偏的难度更大。因为所有的做这个“错误”的事情的人都成了这个事情的既得利益者，纠错就变成动别人的利益。从程序员的角度出发，你来纠偏，也是对他之前工作的否定。一个低水平产品经理会毁掉一个团队。

那不要产品经理了

由于让一堆代码在服务器或者终端设备上运行起来怎么说也是有一些门槛的，而产品经理的工作看起来就是动动嘴毫无门槛，所以大批量各种水平的人涌入来做产品工作。实践中，有大量的产品经理，就是做个传话筒的工作 ，导致的一个结果是，在很多开发眼里，产品经理是没有价值的。更要命的是C端的产品经理，由于不像 B段产品经理还有明确的客户的话可以传，只能自己编造需求，由于需求的奇葩导致公司内部矛盾频发。如网上有个经典段子，一个产品经理个开发说，需要根据手机壳的颜色自动改变APP的主题颜色。另外，我也曾亲耳听闻两个开发讨论问题的是，一个开发说，产品经理说xxx，另外一个开发说，别搭理他，产品经理啥也不会。

那干脆不要产品经理了吧。开发直接去对接需求方或者客户，岂不是效率更高？

自打流水线发明后，社会的分工是大势所趋。越是成熟的产业往往分工越细致。在芯片产业，早期的公司都是类似现在英特尔一样，一家包揽从设计到生产封装销售全部工作。然而，到现在芯片行业已经细分的每个步骤都可以独立成立公司并且做到很大规模看。例如：
    1.专门做IP（intelligence property）核的ARM，MIPS等公司，主要工作类似于写单元模块的代码。然后以卖代码授权创收。
    2.基于ARM核的CPU，然后集成GPU、USB、基带等周边IP核做出整体SOC的华为、展讯、联发科等纯芯片设计公司。相当于拿别人的轮子做方案的公司。
    3.专业做芯片生产的台积电、中芯国际等代工厂。大家都知道苹果手机是富士康代工的，在芯片行业也是一样，华为，联发科自己也没有芯片工厂，他们设计好了之后找台积电、三星、中芯国际等大厂代工生产。
    4.把代工厂做好的裸芯片做封装的艾克尔、江苏长电等公司。芯片代工厂生产的是裸露的硅片，极其脆弱，沾染点灰尘就可能挂了。所以还需要封装厂把硅片使用塑料、陶瓷或者金属给包起来变得耐操。

其他还有辅助设计的EDA工具厂、为代工厂提供光刻机的ASML厂等。

当一个系统有一定复杂度的时候，每个人做自己最擅长的事情得到的是整体效率最高。

Foxmail早期是张小龙一个人做出来的，然而张小龙世上又有几个呢？

优秀的开发直接去聊需求然后搞实现自然问题不大。但是绝大多数人还是普通的。产品经理的存在，是让广泛普通的人合作得到整体结果的最优。

另外，考虑到懒惰是根本的人性，开发对于用户的问题，最直接的反映都是怎样最简单的解决。在很多情况下，最简单不等于最优。有家劳务公司找外包开发了临时工管理系统，劳务公司的结算希望能导出来临时工的发薪同商家的付款单对账，外包公司给了结算员一个SQL客户端和数据库地址还要一串SQL代码。每次需要导出的时候，要结算员手动改下SQL代码中的日期范围并美其名曰这是最灵活最方便的。从外包公司的角度绝对是最低成本解决问题，只是这个劳务公司后来自己招聘开发去了。

所以，虽然产品经理让真正“干活”的很多人非常讨厌，但是依然是流水线上必不可缺的一个存在。另外，产品和开发本质也不过是资本家流水线上的工人，也就不要互相为难了。

产品经理的要求

作为一个在互联网公司里，仍然是必不可少的工种，要做好这份工作，对人还是有一定要求的。

往往越是门槛低的职位，做到高水平难度越高，因为相对于开发高水平的硬实力，高水平的产品经理需要的是高水平的软实力。很多产品经理的招聘JD（job description）里都会要求有“良好的沟通能力”、“逻辑思维能力强”、“执行推动能力强”、“有团队精神”、“有担当，责任心强”。没有一个应聘者会说自己满不足这几项要求。然而，这几项要求套到开发、运营、销售身上一点问题没有，因为这是对一个人职业素质的要求。所以，很多时候对产品经理的水平的评判，与对一个人的评判是非常接近的。甚至于可以说，高水平的人都可以做到高水平的产品经理。

问题是，判定一个人的水平高低，是有难度的。对于开发，可以面试的时候出几个算法，数据结构的题目，甚至于直接上机调试个bug来相对比较客观反映应聘者的水平。对于产品经理，如何通过一个小时的沟通能客观评价候选人有没有团队精神？对于稍微会伪装一点的人来说，团队精神再差的人，面试的时候都可以表现的团队精神非常强。

更可悲的是，对人的水平的评价不是向上兼容的。高水平的人可以评估低水平的人，低水平的人往往无法做到对比自己水平高的人的客观评价。马云创建阿里巴巴的时候，最初的18个员工听马云忽悠都是一脸懵逼的。甚至在阿里巴巴已经有一定规模以后，马云依然在很多人眼里是骗子。同样的，王坚在阿里做阿里云的时候，在阿里内部遭受到了巨大的反对声音和阻力，而站在他背后的男人是马云，马云不懂技术，但是马云懂王坚。

当然，现实中，也不要求所有产品经理都是顶级的。

在很多大厂里，都会使用级别来对员工进行管理。对于产品经理来说，不同等级的产品会有不同的要求的描述。很多描述很抽象，甚至于不同人都可能产生不同理解。我之前见过一个很具象的描述，可以形象说明下不同水平产品经理的要求：
    初级的产品经理，要求是，有个苹果园，告诉施肥、摘果子时，能把肥料施放好了，能把成熟的果子摘下来。
    中级的产品经理，要求能管理果园，需要知道什么时候该组织人施肥、浇水、采摘。
    高级产品经理，是在上级把苹果园交给他，这个产品经理能把果园种出来。
    卓越的产品经理，是给他一片地，他知道该种什么。
    天才级的，是发现一片地。

初级，知道施肥的具体操作方式，知道判断果子成熟的方法就够了。
中级，要在初级的基础上，具有发现问题的能力和组织协调沟通能力。
高级，是在中级的基础上，有系统规划，整体架构的能力。
卓越，是在高级的基础上，有市场判断、商业嗅觉、收支判断能力。
天才，你是老板。

所以，对一个人的水平的判断，可以基于是否有对应等级工作的方法论，若无法判断方法论，最简单的是看否做出过对应等级的成果。

产品经理是否需要懂技术？

这是个在产品经理界老生常谈的问题。不过有个参考，业内最有名的以产品著名的公司是腾讯，腾讯产品的领袖是马化腾和张小龙。据说腾讯现在依然能看到马化腾当年的代码，Foxmail是张小龙一个人做出来的。

同样以果园为例子，产品经理组织人去施肥了，施肥的工作是开发做，那产品经理知道肥料分氮磷钾应该是不过分的要求。

当然，业界也有用户增长产品经理，用户调研产品经理等分工，看起来是不需要技术的，针对这种产品经理，我们的方案是，这里不讨论了。这里主要讨论做toB业务的产品经理。

产品经理岗位的大规模出现是在互联网诞生之后才有的。以至于在当前的大学里是没有产品经理这个专业的。与之最接近的专业应该是软件工程。软件工程专业的专业课程包括算法、数据结构、操作系统、编程语言等程序员的专业内容，但是还有一部分课程也是专业课，容易被人忽略，分别是：是软件项目管理、用户界面设计、软件需求、创意和沟通等。软件工程专业的课程设置包括了从需求到开发到测试一直到运维的全体系课程。对口就业方向包括需求分析师，架构师，开发，测试运维。也就是说，软件工程专业的人做产品经理是真的科班出身。因此，再碰到软件工程专业毕业的人在做产品经理的时候，不要问他为什么不去做开发了，因为产品经理是他们专业的对口就业方向之一。

从工作的角度，产品经理是用户和工程落地的桥梁。日常工作中的沟通部分，至少有三分之一是面对开发的，同时产品的方案还是开发实现的。按照沟通的有效性要求，发送方发送消息，接收方收到后发送应答，发送方收到应答后再确认无误才算有效沟通。

接收方将发送信息加入一些专业处理后再应答时，发送方应该是能够确认接收方的应答中明确确认接收方式收到了发送方的信息的。

工作中的沟通是产品提需求，然后开发加一些技术的反馈，若对技术的反馈完全无概念，那需求的有效传达是无法保证的。当然实际更多的情况是，产品经理不懂技术，会被开发忽悠，简单的问题，由于开发不愿意做，也会变得难度异常高，工期非常长。