互联网的「产品经理」这个岗位，发展到今天，我认为，至少有一半从业者，不配被称为「产品经理」，今天我就从以下几个层面来扯一扯，希望被喷到的话，也可以理性讨论，或虚心接受。
需求管理
需求管理是产品经理的最基本的能力吧？那么，作为「产品经理」的你，是如何做需求管理的呢？
最简单的需求管理：
１、各级负责人
提出者：谁提出的？最初怎么说的？
开发负责人：谁是负责开发团队的Leader？
测试负责人：谁来负责测试团队按期测试？
运营负责人：上线后谁来运营？
２、状态：
待讨论：需求已提出，详情待确认
已拒绝：需求被干掉了
暂缓：需求不明确，还要再讨论；需求明确了，但现在优先级不高，需要等待重新激活……
已确认：已经确认需求）
开发中
测试中
已上线
……
３、时间信息：
提出时间
录入时间
发布时间
作为产品经理，你是否是通过这种方式去做最简单的需求管理的呢？进阶一点的需求管理，你除了要有这张表，还要能从需求方的表达中，去寻找完整的逻辑，这个需求是从何而来？为何提出？为何要做？不做会怎么样？优先级的判断都要基于真实需求的管理。
什么是真实需求？有两个故事被说了无数遍。
故事一：
美国营销大师菲利普·科特勒曾经讲过这样的故事：一个顾客首先来到第一家店问，「你们家有12寸的钻头吗？」第一家店主说：「没有，只有10寸的钻头。」然后顾客就走了；他来到第二家店铺，问店主：「你们家有12寸的钻头吗？」店主说：「我们家只有10寸和11寸的钻头」于是便走人了；他来到第三家店店主还是这样的结果。到了第四家店铺，他问店主：「你们家有12寸钻头吗？」店主说：「没有，只有10和11寸的钻头，但是，不知道您用12寸钻头做什么用啊？」顾客回答：「哦，因为我们家墙壁需要钻一个12寸的洞来装修房屋。」店主说：「原来是这样啊，我们家的10寸钻头就可以帮您这个忙，您按照12寸规格来钻，然后稍微再往里面深入打磨一下就可以了，而且还经济实惠，比12寸的价格便宜很多。」顾客想了想说：「真如您所说？」店主回答：「管不管用，您试试不就知道了吗？」于是10寸钻头就这样成交卖出。」
这就是著名的「客户要买的不是钻头，是洞」的故事。
故事二：
100多年前，福特公司的创始人亨利·福特先生到处跑去问客户：「您需要一个什么样的更好的交通工具？」几乎所有人的答案都是：「我要一匹更快的马。」很多人听到这个答案，于是立马跑到马场去选马配种，以满足客户的需求。但是福特先生却没有立马往马场跑，而是接着往下问。福特：「你为什么需要一匹更快的马？」客户：「因为可以跑得更快！」福特：「你为什么需要跑得更快？」客户：「因为这样我就可以更早的到达目的地。」福特：「所以，你要一匹更快的马的真正用意是？」客户：「用更短的时间、更快地到达目的地！」于是，福特并没有往马场跑去，而是选择了制造汽车去满足客户的需求。
这就是著名的「福特造车」的故事。多少产品经理听过这些故事？最后工作的时候，有几个能落实到真正的需求管理中去？请自己反省。
决策逻辑
产品经理的屁股通常坐在用户一侧，追求让用户使用更好、更爽体验的产品，是很多产品经理毕生的追求。
但是，我接下来要说产品经理的决策逻辑，因为我敢说，大多数产品经理在做拒绝需求的理由是：
会伤害用户体验
好，看到这里，如果你是一个用这个理由去拒绝需求的PM，请你大胆的仔细的看下去。
在盛大的时候，企业文化中，对于争议的决策树是这样设计的：
1.有数据时，数据第一。没有任何人的观点可以大于客观数据的权重。如果数据说，这个产品烂，那么它就是烂，你要想办法去让数据涨起来。
2.没数据时，逻辑第一。如果大家在讨论的事情，没有数据可以做支持，或者数据并不能说明问题，那么就要比拼逻辑，所谓逻辑就是从A到B，是有顺序，有因果，有联系的。如果从A到B，没有顺序，没有因果，也不能证明其联系，那就是没有逻辑。
3.碰到逻辑也解决不了的问题，谁负责，谁拍板决策。谁负责，拼的不是title，拼的是谁要为最终结果负责。运营如果和产品争执某个功能的需求，这个需求，没有数据支持，逻辑也无法互相说服，那么很简单，谁来负责这个需求上线后的数据表现，谁来背这个KPI，谁拍板决策。
或许是我做这一行太久了。见过很多有数据sense、逻辑清晰、敢于负责的产品，但也见过很多完全没有数据sense，甚至没有基本逻辑，只知道听老板指挥的产品。可想而知这两类PM日后的发展会如何。
曾几何时，BAT的各种人都被猎头追捧，现在，有些公司的有些岗位，都得看入职年限了，因为被坑的次数有点多了，就知道背景漂亮对于PM或者运营或者开发来说，并没有太大意义，关键的还是能力和业绩。
思路清晰
我非常喜欢思路清晰的产品经理，同时，我又非常讨厌一种PM：思路混乱，还要滥用对标。譬如，BAT这样做，所以我们也应当这样做，BAT不这样做，所以我们也不该这样做。
请问，微信现在体量这么大了，不敢随便做动作，所以很多产品经理都在做维护工作，是不是你现在也不要做迭代了呢？
弄清楚自己的产品所在的阶段，很重要；弄清楚不同阶段的产品应当负担什么职责，很重要；弄清楚产品本身是1，需要运营、市场让它壮大，更重要。
所以，思路清晰对于PM来说，非常关键。你要很明白为什么别人做这个设计，你是否可以做这一类的设计。
你要明白为什么需求是这个样子，背后究竟意味着什么。
这些都依赖于产品经理的思路是否足够清晰，而不是通过简单的对标来完成。
舍我其谁
最后要说的，是责任感问题。
一个产品做出来了，做得好，数据会告诉你；做的不好，数据也会告诉你。但，你能否承担相应的责任。一个数据表现不那么好的产品，是继续让它拖着苟延残喘，还是当断则断，干掉它或者去重构？有些产品经理的责任感，真的不行。而责任感的缺失，和产品经理的考核有直接关系。
过去，在项目制架构下，产品经理是断不敢说，这个需求我不接，因为影响用户体验这种废话的，因为，这个产品从无到有，要活下去就是靠数据来证明，于是单独做出产品其实没什么卵用，还是需要运营、市场的帮助，让它持续的成长。
