产品经理的十大顶级错误
【作者介绍】无招、鬼脚七。无招是一淘网的资深产品专家,对电子商务、数据挖掘类、互联网产品有丰富经验;鬼脚七曾经负责过大淘宝搜索产品,对产品设计和产品管理有自己的思考。
产品经理需要创造产品。上帝也是个产品经理,他创造了人这个产品。
做一个成功的产品非常难,除了需要有资源、时机等问题以外,更大因素在产品经理。好的产品经理能协调资源,能把握时机。但产品经理自己也经常犯错误。一直想写一篇文章,关于产品经理容易犯的错误,但担心自己在产品方面的经验不够多,迟迟没有动笔。
最近翻看了之前的记录,发现资深产品专家Marty Cagan 提过类似的观点。Marty Cagan曾经担任过网景的副总裁,负责eBay 产品的资深副总裁,有过非常丰富的产品设计和产品管理经验。无招也参加过Marty Cagan 产品培训,于是我和无招,以Marty Cagan的总结为基础,加上我们对产品设计的理解,整理出了这篇文章,分享给大家。
(1) 将用户需求混淆为产品需求
大部分产品经理的工作流程是:收集完用户需求,开始编写产品需求文档,然后交给技术人员开发,接下来跟踪项目进度,协调资源,验收成果,最后发布产品。
整个流程没有错,容易产生错误的地方在于,产品需求如何确定。在淘宝内部的产品经理也是如此,经常把运营同学的需求直接翻译成文档,交给技术人员开发。最后的结果是产品的功能点越来越多,产品越来越复杂,成为一个大杂烩。
一定要从产品设计的角度思考需求,把用户的需求转化成为产品需求。在火车没有出现的时候,你问用户最想要什么?用户会说,我想要一匹跑得更快的马。用户的需求看上去是要一匹好马,但实际上转化成产品需求就是,需要更快的交通速度。
用户需求是提出的一个问题,产品需求是解决这个问题的可行方案。所以当用户需求被表达为一种解决方案时,要探寻其背后的隐蔽问题。比较好的解决问题的办法是:加强可行性分析和需求评审。
(2) 将老板的需求混淆为产品需求
这可能是很多产品经理内心的痛,对于大多数淘宝的PD都应该遇到过大小老板过来提需求,就算明显不靠谱的需求,也不好反驳,只能安排开发。
老板有老板的视野,有他独享的信息和经验,还有他的权利。老板的需求肯定要听的,老板也是用户之一,他的需求也是用户需求,只是不要听过来直接当成产品需求。
针对老板的需求,更要强化需求追溯。从老板这里深入地理解他的需求来自哪里,是基于什么样的场景和什么样的用户,有没有具体的实例。
老板的需求大部分都是合理的,只是优先级没有那么高。我们可以采用拖延战术来应对:
老板啊,你这个需求很合理,而且相当到位,我计划在下一个版本好好规划一下,这个版本的功能点已经比较多了,开发人员实在太少,啊,老板,能否帮我争取多来两个开发工程师……
等到下一个版本的时候,老板经常忘记了他的需求了。如果他还记得,就帮他实现一部分功能好了,面子还是要给的。
(3) 将发明(invention)混淆为创造(innovation)
这个对于搞创新的产品经理们来说,是常常遇到的问题。尤其是经验尚浅,有强烈使命感的产品经历常常会将一个idea,一个使命直接当做创新来执行。
发明是实验室里的,创造是产业里应用的。实验室的东东是新东西,但是限定了前提条件,而且在商业性验证,市场推广,规模化等方面都不会事先想得太清楚。
创造则是产业级的一个改变,能商业化,能养活团队,能规模化,能真正抵达用户并让用户接受。
最不可接受的是,对于一个新产品,前景非常好,做了很长时间的规划设计,投入了不少工程师开发,过了半年才出来一个有很多缺陷的产品,也无法推向市场;而且这时候市场已经产生了一些变化,还要接着改产品需求,同时又要完善之前的产品。这种产品最后必死无疑。
应该专注最小核心问题,解决最核心的问题,完成小而美的功能,然后快速迭代,用户第一。要能养活团队,让团队成员过上好日子。否则就算公司不停项目,团队也会人心涣散。
(4) 以自己的需求取代用户的需求
大多数产品经理,沟通能力比较强,也比较强势。当产品经理急于求成的时候,或者找不到目标用户,过分超前的时候,容易YY出一些产品需求。他们不找到目标用户验证核心问题及解决方案,以理所当然的想法来描述产品故事(用户场景和用户问题)。
现状很多人强调要重视数据,也容易让产品经理忽略客户,因为自己天天看数据,就把自己取代了客户。我在负责搜索产品的时候,经常跟搜索的产品经理讲,要把用户当人看,不要当成数据看。数据很重要,但数据容易掩盖用户人性化的需求。
产品经理应该学会倾听不同观点,多和那些敢于批评自己观点的人沟通。无论是小用户量的产品还是大用户量的产品,一定要抽时间了解真正用户的需求和感受,哪怕是跟他们闲聊,一定能发现一些之前想法不一样的结论。
(5) 将“创建正确产品”当作“正确地创造产品”
这就跟“正确的做事和做正确的事”是一个道理。很多人习惯于被安排,然后按照流程去做事,并不想这件事情到底为什么要做,是否真的要做。
产品经理也容易如此,到了一个岗位,接到任务要完成一个功能,然后就按照流程去做,最后这个产品是很完美的做完了,但基本上没有人用。在大公司、严谨的公司里更容易出这种问题。尤其是细分工作,平台化流水化运作的环境之中,产品经理容易成为一个规则下的执行人。
举个例子,如果产品经理接到任务是要设计一个网站来宣传公司的技术品牌。产品经理最常见的做法就是设计网站的各个模块,内容,甚至还设计了一个论坛,形成文档,然后交与开发。事情做完了,这个网站是做好了,但发现没有任何流量,完全起不到宣传公司技术品牌的作用。这个例子正确的做法应该是怎么样的?大家可以自己思考。
我们应该鼓励产品经理去实现自己的梦想,也可以考虑把团队垂直化,一方面可以提高效率,另一方面可以避免很多错误。
(6) 将“添加功能”当作“产品提高”
任何产品都需要不断的添加新功能,一方面要满足更多用户需求,另一方面需要适应环境的变化。产品经理经常把添加功能当成了产品提高,这种现象在一个在既有成熟产品的团队里会比较明显,已有的思路和评估指标常常造成的就是不断地同质化,不断地添加nice to have的功能。
但添加功能,不一定是产品提高。如何确定是否是”产品提高”?确定一个合理的产品的衡量指标非常重要。
一个不合理的产品衡量指标,很容易对产品带来负面效果。在淘宝就有不少这种例子,不停的推出扫货产品,以成交转换率和带来整体成交额来衡量新功能是否成功。新浪微博也有类似的功能,换背景图片和模版,送礼物和赛礼物,推荐活动关注等,内部应该都是以有多少用户参与为衡量指标。
如果淘宝搜索把搜索转化率作为衡量指标,最终的结果就很容易造成低价和爆款盛行;新浪微博把用户参与度作为衡量指标,就会出现到处都是推荐关注的功能模块,让用户容易反感;去年当当网就做了一件事情,鼓励用户去发书评,内部应该是衡量多少人参与了评价,最后导致的结果是,大量的垃圾评论产生,让原本特别好的书评也被淹没掉了。
如果希望解决解决这个问题,需要真正从用户的角度思考问题,制定合理的衡量指标。有些衡量指标是相互制约的,例如淘宝搜索的衡量指标中就有一个基尼系数,用来保证流量分布不能过于集中。如何制定合理的衡量指标,不同的业务会很不一样,需要综合性思考。
(7) 无法分清“激动人心”和“有也不错”的功能。
这个错误和第六点错误有些类似。
无线互联网的发展,让用户对产品越来越挑剔,如果没有一些“激动人心”的功能,很容易让用户忘记这个产品。但产品经理经常花了太多精力在打造一些“有也不错”的功能。
如果一个产品的用户达到几十万,任何一个功能,都能满足一部分用户的需求,也都有部分用户在使用。类似的功能需求会永远做不完,持续下去,一定会让产品越来越复杂。微信在这方面做了一个很好的榜样。微信最大的功能在于沟通,虽然微信可以做很多事情,包括媒体,朋友圈等,但微信产品的主线还是在沟通上,把沟通的功能做到非常方便,对讲功能的设计就是一个激动人心的功能。微信也做了一些有也不错的功能,例如:语音提醒。看上去不错,实际上用的人并不多。
资源总是有限的,产品经理应该把精力放在主路径上,不断地问问自己是产品的典型用户,用户是否真的喜欢真的急切需要这个功能吗?设计出一个激动人心的功能,远远比提供10个有也不错的功能更重要。
(8) 追求印象深刻的需求文档,而不是追求感人的产品
写出一份好的PRD(产品需求文档),确实重要,因为可以帮产品经理理清思路,同时又让技术人员知道产品的设计细节。但我以前一直是在做技术,对PRD看得不会太仔细,不清楚的地方才会去细看,就像咱们平时对待电器说明书一样。另外,PRD再深刻,目标用户也无法真正感知产品的设计。
因此对撰写PRD,应该是够用就好。最好的方式是和技术、设计人员一起有效沟通,正式启动产品实现之前,以全动态高保真原型来获取用户的认可,感知用户的心声。纯算法型产品或者数据挖掘类产品可能在这点上有难度,可以用真实的数据分析来表达这类产品设计。
(9) 将产品发布当作了成功
这个错误不只是产品经理容易犯,很多公司的老板也容易犯这个错误。在一些大公司,发布了一个小产品,甚至发布了一个小功能,都会有洋洋洒洒上千字的喜报邮件。这种邮件很鼓舞士气,只是不能把产品发布当成产品成功。
一个看似很简单的道理,但做起来不那么容易。很多产品经理急于发布自己的产品,导致产品体验非常不好,就算后续快速改进,也很难挽回用户的流失和口碑。现在有很多产品都开始实行邀请测试的模式。例如微信的5.0测试版,微信公众账号的菜单功能;微博的媒体账号测试;微淘的邀请测试参与;淘宝搜索上线很多功能,也是用5%的流量先做测试。这些做法都是为了避免冒然发布产品或功能。
产品发布,意味着用户才真正开始使用,成功与否不是看产品是否发布,而是看用户是否真正喜欢。要做到用户真正喜欢,产品发布才是刚刚开始。
(10) 进入“喂养野兽”的模式
什么叫野兽喂养?野兽永远吃不饱,需要拿东西不停的喂养。一个产品经理,有时没有想好到底应该做哪些功能,但需要给其相应的技术团队有足够的工作量,于是不得不找一堆小功能,让他们去开发。
很多公司都有类似情况,经常会听到技术人员或者设计人员说:你这里工作少,你这里的工作没有新鲜的可学的东西,我没有成就感,我的晋升会受影响,我要去做大项目…….这时候产品经理如果需要争取到这些资源,必须提供足够多、足够大的需求,让相应的团队来开发,不停地给出需求把开发和设计的肚子喂饱。需求是什么已经不重要,重要的是支持这个产品的资源不会被别的产品抢走。
这么做的坏处显而易见,不只是浪费公司的资源,更重要的是,会让整个产品没有逻辑,功能臃肿,最后要么成为一个平庸的产品,要么需要做大的减法手术。但一个产品做加法容易,做减法非常困难。任何减法都会损害一部分用户的使用习惯。
这个错误的产生,有时候是不自觉的,甚至发生了我们自己还没有意识到。要避免这个错误,一方面需要从公司组织上给与合理的时间培育产品,也给予产品经理足够信任,产品经理也应该有足够的自我反思;另一方面考虑团队的垂直化,让技术人员和产品人员都在一起,要么一起精彩,要么一起落寞。
以上10条顶级错误,是Marty Cagan根据他十几年的产品管理经验总结出来的,对互联网产品的开发很值得参考。特别是一些中大型的互联网公司,有多条产品线,技术分工越来越细,类似的错误就越来越多。Marty Cagan 原文写的是产品设计的十大顶级错误,本文这里改成了产品经理,会适合国情一些。
当然,不同的人总结出来的十大顶级错误可能不一样,如果让我来总结,可能还有其他的一些错误。本文中提到的这些错误不是适用所有的公司,如果你对产品设计感兴趣,或者你本来就是一名产品经理,你可以把这篇文章收藏起来,每过一段时间拿出来看看,对照一下自己是否犯了同样的错误。