你配叫「产品经理」吗？

互联网的「产品经理」这个岗位，发展到今天，我认为，至少有一半从业者，不配被称为「产品经理」，今天我就从以下几个层面来扯一扯，希望被喷到的话，也可以理性讨论，或虚心接受。

如果看了不爽，不负任何责任。

互联网的「产品经理」这个岗位，发展到今天，我认为，至少有一半从业者，不配被称为「产品经理」，今天我就从以下几个层面来扯一扯，希望被喷到的话，也可以理性讨论，或虚心接受。

需求管理

需求管理是产品经理的最基本的能力吧？

那么，作为「产品经理」的你，是如何做需求管理的呢？

最简单的需求管理：

各级负责人：提出者（谁提出的？最初怎么说的？）、需求负责人（这个需求是哪个 PM 在管理？）、开发负责人（谁是负责开发团队的 Leader？）、测试负责人（谁来负责测试团队按期测试？）、运营负责人（上线后谁来运营？）

状态：需求中（提出者正在准备提需求）、待讨论（需求已提出，详情待确认）、已拒绝（需求被干掉了）、暂缓（需求不明确，还要再讨论；需求明确了，但现在优先级不高，需要等待重新激活……）、已确认（已经确认需求）、开发中、测试中、已上线……

时间信息：提出时间、录入时间、发布时间

作为产品经理，你是否是通过这种方式去做最简单的需求管理的呢？

进阶一点的需求管理，你除了要有这张表，还要能从需求方的表达中，去寻找完整的逻辑，这个需求是从何而来，为何提出，为何要做，不做会怎么样，优先级的判断都要基于「真实需求」的管理。

什么是真实需求？

有两个故事被说了无数遍。

故事一：

美国营销大师菲利普·科特勒曾经讲过这样的故事：

一个顾客首先来到第一家店问，「你们家有 12 寸的钻头吗？」第一家店主说：「没有，只有 10 寸的钻头。」然后顾客就走了；

他来到第二家店铺，问店主：「你们家有 12 寸的钻头吗？」店主说：「我们家只有 10 寸和 11 寸的钻头」于是便走人了；

他来到第三家店店主还是这样的结果。

到了第四家店铺，他问店主：「你们家有 12 寸钻头吗？」店主说：「没有，只有 10 和 11 寸的钻头，但是，不知道您用 12 寸钻头做什么用啊？」顾客回答：「哦，因为我们家墙壁需要钻一个 12 寸的洞来装修房屋。」店主说：「原来是这样啊，我们家的 10 寸钻头就可以帮您这个忙，您按照 12 寸规格来钻，然后稍微再往里面深入打磨一下就可以了，而且还经济实惠，比 12 寸的价格便宜很多。」顾客想了想说：「真如您所说？」店主回答：「管不管用，您试试不就知道了吗？」于是 10 寸钻头就这样成交卖出。」

这就是著名的「客户要买的不是钻头，是洞」的故事。

第二个：

100 多年前，福特公司的创始人亨利·福特先生到处跑去问客户：「您需要一个什么样的更好的交通工具？」几乎所有人的答案都是：「我要一匹更快的马。」

很多人听到这个答案，于是立马跑到马场去选马配种，以满足客户的需求。但是福特先生却没有立马往马场跑，而是接着往下问。

福特：「你为什么需要一匹更快的马？」客户：「因为可以跑得更快！」福特：「你为什么需要跑得更快？」客户：「因为这样我就可以更早的到达目的地。」福特：「所以，你要一匹更快的马的真正用意是？」客户：「用更短的时间、更快地到达目的地！」

于是，福特并没有往马场跑去，而是选择了制造汽车去满足客户的需求。

这就是著名的「福特造车」的故事。

多少产品经理听过这些故事？最后工作的时候，有几个能落实到真正的需求管理中去？

请自己反省。

决策逻辑

产品经理的屁股通常坐在用户一侧，追求让用户使用更好、更爽体验的产品，是很多产品经理毕生的追求。

但是，我接下来要说产品经理的决策逻辑，因为我敢说，大多数产品经理在做拒绝需求的理由是：

会伤害用户体验

好，看到这里，如果你是一个用这个理由去拒绝需求的 PM，请你大胆的仔细的看下去。

在盛大的时候，企业文化中，对于争议的决策树是这样设计的：

• 有数据时，数据第一。没有任何人的观点可以大于客观数据的权重。如果数据说，这个产品烂，那么它就是烂，你要想办法去让数据涨起来。

• 没数据时，逻辑第一。如果大家在讨论的事情，没有数据可以做支持，或者数据并不能说明问题，那么就要比拼逻辑，所谓逻辑就是从 A 到 B，是有顺序，有因果，有联系的。如果从 A 到 B，没有顺序，没有因果，也不能证明其联系，那就是没有逻辑。

• 碰到逻辑也解决不了的问题，谁负责，谁拍板决策。谁负责，拼的不是 title，拼的是谁要为最终结果负责。运营如果和产品争执某个功能的需求，这个需求，没有数据支持，逻辑也无法互相说服，那么很简单，谁来负责这个需求上线后的数据表现，谁来背这个 KPI，谁拍板决策。

或许是我做这一行太久了。

见过很多有数据 sense、逻辑清晰、敢于负责的产品，但也见过很多完全没有数据 sense，甚至没有基本逻辑，只知道听老板指挥的产品。

可想而知这两类 PM 日后的发展会如何。

曾几何时，BAT 的各种人都被猎头追捧，现在，有些公司的有些岗位，都得看入职年限了，因为被坑的次数有点多了，就知道背景漂亮对于 PM 或者运营或者开发来说，并没有太大意义，关键的还是能力和业绩。

思路清晰

我非常喜欢思路清晰的产品经理，同时，我又非常讨厌一种 PM：思路混乱，还要滥用对标。

譬如，BAT 这样做，所以我们也应当这样做，BAT 不这样做，所以我们也不该这样做。

请问，微信现在体量这么大了，不敢随便做动作，所以很多产品经理都在做维护工作，是不是你现在也不要做迭代了呢？

弄清楚自己的产品所在的阶段，很重要；弄清楚不同阶段的产品应当负担什么职责，很重要；弄清楚产品本身是 1，需要运营、市场让它壮大，更重要。

所以，思路清晰对于 PM 来说，非常关键。

你要很明白为什么别人做这个设计，你是否可以做这一类的设计。

你要明白为什么需求是这个样子，背后究竟意味着什么。

这些都依赖于产品经理的思路是否足够清晰，而不是通过简单的对标来完成。

舍我其谁

最后要说的，是责任感问题。

一个产品做出来了，做得好，数据会告诉你；做的不好，数据也会告诉你。

但，你能否承担相应的责任。

一个数据表现不那么好的产品，是继续让它拖着苟延残喘，还是当断则断，干掉它或者去重构？

有些产品经理的责任感，真的不行。

而责任感的缺失，和产品经理的考核有直接关系。

过去，在项目制架构下，产品经理是断不敢说，这个需求我不接，因为影响用户体验这种废话的，因为，这个产品从无到有，要活下去就是靠数据来证明，于是单独做出产品其实没什么卵用，还是需要运营、市场的帮助，让它持续的成长。

「产品经理改变世界」这种口号，我不反对，但这个口号说的是发起点，而不是终结点。

如果仅仅靠产品经理就能改变世界，世界也太简单了些。

所以我说，如果你的需求管理做得烂、决策逻辑又混乱、思路不清晰，还没有责任心的话，你绝对不配叫做「产品经理」。

回过头来，这个世界一定会越来越缺乏有运营思维的产品经理，也会越来越缺乏懂产品的运营。所以，说起来，机会是巨大的，能否抓住机会，看个人修为。

我说完了～

阅读全文: http://gitbook.cn/gitchat/activity/5ddcda1c8fb88240ede88bb1

您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ，阅读更多 GitChat 专享技术内容哦。