互联网的「产品经理」这个岗位,发展到今天,我认为,至少有一半从业者,不配被称为「产品经理」,今天我就从以下几个层面来扯一扯,希望被喷到的话,也可以理性讨论,或虚心接受。 需求管理 需求管理是产品经理的最基本的能力吧?那么,作为「产品经理」的你,是如何做需求管理的呢? 最简单的需求管理: 1、各级负责人 提出者:谁提出的?最初怎么说的? 需求负责人:这个需求是哪个PM在管理? 开发负责人:谁是负责开发团队的Leader? 测试负责人:谁来负责测试团队按期测试? 运营负责人:上线后谁来运营? 2、状态: 需求中:提出者正在准备提需求 待讨论:需求已提出,详情待确认 已拒绝:需求被干掉了 暂缓:需求不明确,还要再讨论;需求明确了,但现在优先级不高,需要等待重新激活…… 已确认:已经确认需求) 开发中 测试中 已上线 …… 3、时间信息: 提出时间 录入时间 发布时间 作为产品经理,你是否是通过这种方式去做最简单的需求管理的呢?进阶一点的需求管理,你除了要有这张表,还要能从需求方的表达中,去寻找完整的逻辑,这个需求是从何而来?为何提出?为何要做?不做会怎么样?优先级的判断都要基于真实需求的管理。 什么是真实需求?有两个故事被说了无数遍。 故事一: 美国营销大师菲利普·科特勒曾经讲过这样的故事:一个顾客首先来到第一家店问,「你们家有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来说,非常关键。你要很明白为什么别人做这个设计,你是否可以做这一类的设计。 你要明白为什么需求是这个样子,背后究竟意味着什么。 这些都依赖于产品经理的思路是否足够清晰,而不是通过简单的对标来完成。 舍我其谁 最后要说的,是责任感问题。 一个产品做出来了,做得好,数据会告诉你;做的不好,数据也会告诉你。但,你能否承担相应的责任。一个数据表现不那么好的产品,是继续让它拖着苟延残喘,还是当断则断,干掉它或者去重构?有些产品经理的责任感,真的不行。而责任感的缺失,和产品经理的考核有直接关系。 过去,在项目制架构下,产品经理是断不敢说,这个需求我不接,因为影响用户体验这种废话的,因为,这个产品从无到有,要活下去就是靠数据来证明,于是单独做出产品其实没什么卵用,还是需要运营、市场的帮助,让它持续的成长。