【7哥导读】做好一个产品经理非常不容易，经常容易犯错误。本文详细描述了产品经理经常犯的十大顶级错误。对产品经理、技术负责人、创业者，都可以借鉴。
作者：无招、鬼脚七。无招是一淘网的资深产品专家，对电子商务、数据挖掘类、互联网产品有丰富经验；鬼脚七曾经负责过大淘宝搜索产品，对产品设计和产品管理有自己的思考。
说明：本文首发于天下网商，请所有转载注明来源于天下网商。
产品经理需要创造产品。上帝也是个产品经理，他创造了人这个产品。
做一个成功的产品非常难，除了有资源、时机等问题以外，更大因素在产品经理自己。好的产品经理能协调资源，能把握时机。但产品经理自己也经常犯错误。一直想写一篇文章，关于产品经理容易犯的错误，但担心自己在产品方面的经验不够多，迟迟没有动笔。
最近翻看了之前的记录，发现有个很资深的产品专家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 原文写的是产品设计的十大顶级错误，本文这里改成了产品经理，会适合国情一些。
当然，不同的人总结出来的十大顶级错误可能不一样，如果让我来总结，可能还有其他的一些错误。本文中提到的这些错误不是适用所有的公司，如果你对产品设计感兴趣，或者你本来就是一名产品经理，你可以把这篇文章收藏起来，每过一段时间拿出来看看，对照一下自己是否犯了同样的错误。
———————
【7哥闲谈】
1 还有很多微博的朋友不习惯收到我发的私信，我最后解释一下。这个是微博的媒体公众账号，可以给关注我这个账号的人粉丝每天推送一篇图文文章，类似大家用微信关注公众账号一样。这样的好处是，可以每天收到我整理的经典文章，不用担心漏掉，还方便在电脑上查看。
还有一些朋友关注了鬼脚七，但是没有收到私信文章，很着急。估计是微博的bug，大家也可以访问我微博的主页，里面有“文章”一栏，我所有的文章推送都会在那里。等微博的这个功能稳定了，应该就可以了。
2 昨天我没有给微博的朋友推送文章，只是给微信的朋友推送了【7哥闲谈】，导致一些微博的朋友说我厚此薄彼。其实对我来说，微博微信都是一样的，只不过微信的朋友已经关注过”鬼脚七”一段时间了，他们习惯了每天看一点我的文章，无论是什么内容。但微博上的朋友还不习惯，没有好的内容，我不敢随便推送给大家。以后我尽量保持一致。
3 最近一直在思考”产品”这个词，所有的事情都可以当成产品来做，包括做人。每个人都是产品经理，至少你在设计你自己。我希望我能写一篇文章，像做产品一样生活。主要的观点是，把自己当成一个大产品，有核心价值，有用户需求，有不断的升级和添加新功能，还能做产品转型….. 同时，生活中很多事情，也可以用产品的思路来做。哇，这篇文章会很好玩的。
4 今天闲谈少一点，因为今天要开一个新栏目，7哥推荐。一方面帮助解决公司招人难的问题，另一方面也可以帮助解决一些大学生就业问题。这种每周几个公司的推荐，虽然解决的量有限，但我能尽一点微薄之力也是在解决问题。相信以后有更多的人会参与进来一起来解决这个问题。
——————-
【7哥推荐】
从这周开始，【7哥推荐】栏目算是正式开张了，这个栏目用来帮助一些电商公司做招聘信息发布。每次推荐两个公司，不是每天都有，我也会做一些背景了解。
1 北京天驰网络。
公司拥有独家产品渠道，一线明星资源，深度行业背景的电商运营公司。7哥对他们公司还算了解，他们致力于打造专业化的明星电商平台。现在淘宝上一些”星店”(明星在淘宝上开店）是他们在负责运营。招聘岗位：资深运营、资深设计和文案策划。工作地点：北京。联系方式：i9tianhr@163.com
2 羚羊早安
这是淘宝围巾类目第一店，双金冠，主要产品是围巾丝巾，连续3年销售额蝉联淘宝服饰配件类目第一，2012年“十大网商”之一。他们公司有意思，被称为羊村，每个人也有花名：懒羊羊、喜羊羊……..招聘岗位：平面设计、美工和直通车专员。工作地点：安徽合肥市。联系方式：lingyang_hr@163.com
点击文章最后链接，可以查看两个公司的详细情况和职位要求。如果你也希望被推荐，请把公司招聘信息发到guijiaoqi-open@qq.com 。最近我推荐的公司，都是需要提供接收应届大学毕业生的就业或者实习岗位的电商公司。
这是我在「极客时间」专栏中的文章，关于 AI 时代产品经理的主题我写了两篇，这是其中第二篇，关于我自己半年多学习和实践的经验总结，发在这里主要是为了做个广告，欢迎大家订阅，识别文章底部的二维码或点击「阅读原文」皆可，特别声明，已经支持安卓版了。
上篇文章，我讲到了如何学习成为一个 AI 时代的产品经理，这篇文章，我想结合自己的工作，跟你分享一些我在做人工智能相关产品过程中的实践和思考。我进这一行的时间其实不长，而且目前的主要工作都集中在 NLP 领域，所以难免会有一些局限性，希望你批判地听。
产品与算法的结合粒度要小
产品经理应当把大颗粒的整体性领域算法拆成小颗粒的算法单元，并在此基础上寻找产品化可能。这句话的意思是说，我们不能给算法团队提出一个很大的领域型需求，然后就坐等算法的突破，产品经理应当更小粒度地看待每个具体算法过程和环节，并评估是否有能够被产品化的成果。
比如，我们不能要求算法团队交付一个「聊天机器人」，这个需求粒度太大了，彻底完成会受制于各种因素，更是一个长期的过程。产品经理应该深入到领域内，比如看到自然语言理解（NLU），甚至看到其中本体库搭建和句子的语法树等等，可能部分完成的本体库已经可以包装为一个初级的人机交互引导产品。
我们在无码科技做 Readhub.me 时，产品经理会尽量避免提出像实现命名实体识别（NER）或实现信息抽取（IE）这样大而化之的需求；而是尽量参与到算法过程中，分步去看过程产出。
比如命名实体识别过程中我们需要分词，分词作为一个中间算法，是否可以被直接产品化；再比如信息抽取需要先找到大信息量的文本片段，这个过程的产出，是否可以作为文章摘要或文本标签等等。
过去产品和技术泾渭分明，但在 AI 时代，我认为这个界限应该被打破，产品经理要融入到技术过程中去，不止关注需求，更要关注供给，这样才能做出真正的好产品。
重视工程的力量
当我们说人工智能的时候，总是希望算法可以解决所有问题，给出一个干净而准确的结果。吴恩达教授在去年神经信息处理系统大会（NIPS）上也提到深度学习会向端到端的方向发展。
什么意思呢？就是说，比如我做一个语音交互的机器人，过去的思路可能是人说话，先经过语音识别的算法变成文字，然后再用自然语言处理的过程去理解这些文字的意图，最后做出反应；而端到端的思路是直接把输入，也就是人的说话声音灌到算法盒子里，算法输出的直接就是最终的反应，不去编排中间过程。
但是，完全端到端在工业界有效程度没那么高，我们还是需要大量的工程工作去对算法模块做衔接，对算法的输入输出做清洗和筛选。我们不能在工业界套用学界的做事方式和标准，比如算法能做到 63 分，这时我们继续拼命优化算法，努力提升到 65 分，就不如找个皮实一点的 60 分的算法，加上工程手段，或许可以快速做到 70 分甚至更高。
工程至少可以在三个方面快速提高产品的价值分值，一是通过规则在算法的基础上对输入和输出数据做筛选和过滤（很多时候体现为大量的正则表达式和 if-else）；二是通过工程帮助算法做降维，比如做人脸识别，我们不用把摄像头拍下的整张图片送进神经网络，而是通过工程的方法把图片中的脸截出来并且特征化之后再往算法里送；三是协助算法的训练，比如做手写数字识别，样本量不够的情况下，可以用工程的方法添加旋转和噪点，生成一些新的训练数据。
利用产品最大化技术的产出
产品经理的职责是用产品为用户创造价值，至于这个价值有多少分来自算法，其实并不是成功的核心（除非你是做纯算法产品，比如一些对外提供算法接口的纯技术性公司）。刚才我们提到可能算法做到 60 分，加上工程可以做到 70 分，而一个常见的问题是，产品经理将一个 70 分的能力用到了 90 分或者 50 分的场景中，结果是造成用户的失落或技术能力的浪费。
比如，我们都知道自动驾驶有几个不同的级别，从完全不能自动化的 L0 到完全自动驾驶的 L5。如果现在我们的技术做到了 L4，非常牛了，这个级别下，大部分情况下都可以达到完全自动驾驶。
结果产品经理在此基础上，做了一个没有方向盘和窗户的产品，用户吃着火锅唱着歌把车开到村里，结果在田间地头，车翻了；又或者，产品经理做了一个传统的汽车模式，有方向盘有档把，还需要人来操作，完全没有把 L4 的技术能力用上，浪费了技术的输出。
所以说， AI 时代的产品经理应该非常了解算法的能力边界，并设计出恰如其分的产品，同时也要管理好用户的期望值，既不让用户觉得失落，也要发挥算法的最大价值。
做好数据规划
人工智能产品经理还有一个非常重要的职责，就是规划、收集以及组织算法所需要的数据。如何保证训练、测试集中的数据特性分布和最终场景中的数据一致；如何获取足量的数据，并对它们进行低成本高效率的标注；用什么样的方式清洗数据，甚至基于数据做出统计学分析，为算法提供参考，这一切内容都需要产品经理去完成。
业内有一种说法是：当前的人工智能效果，2 分靠算法，8 分靠数据（剩下的 90 分靠运气，开玩笑的）。尤其是大量的深度学习应用，对数据的质和量提出了很高的要求。
产品经理应该要理解算法的数据输入要求和未来的算法应用场景，找到合适的数据源，合理合法地把这些数据收集下来，清洗干净；并有规划地划分开发、训练和测试集，以保证数据价值的最大化。
当然这个过程不能单靠产品经理一个人，需要有配合的工程团队一起。在无码科技，我们有一个兄弟算是半个全栈工程师，专门跟产品经理配合做这个事情，他能写脚本、能做数据、还懂业务，但愿你也能遇到这样的特种部队型选手。
另外产品经理还应当想办法在业务中设计数据的闭环，通过产品的持续运转，不断生成更多数据提供给算法做训练。目前。大部分的训练过程还是离线的，但如果未来在线学习持续发展，通过这样的业务流程设计，就可以做到在线算法迭代更新。
最后还有一个经验是，盲目扩大数据量并不总是有用的，如果数据的多样性得不到保证，扩大数据规模对算法结果没有太大帮助，甚至如果数据特性分布出现问题导致训练数据有偏，还可能会造成算法的过度拟合和表现下降。
去完美主义，理解算法的不确定性
从某种意义上说，机器学习的不确定性是必然的，它跟传统的面向流程和规则的思路截然不同，在这样的框架下，就需要转变产品设计的思路，摒除完美主义，利用产品机制去消化算法带来的不确定性。
比如，机器学习用在反欺诈或垃圾邮件监测上，就是存在概率的。一封邮件是否是垃圾邮件，在算法完成推理前（尤其是深度学习），即便算法的作者恐怕也无法给出准确的预测。
算法有可能会错判和漏判，这都是产品经理需要理解和考虑的场景，并且要去通过产品设计去消化它。比如反欺诈要准备申诉的流程和入口，垃圾邮件可能需要提醒机制和独立的文件夹等等。
除此之外，我们评价一个算法有效性的方式，也要从局部转向宏观，不能通过一条数据的推理结果去评价一个算法。
有时算法迭代升级，可能整体效果更好了，但单看某一条具体的测试数据，却可能比原来糟糕。比如我们做命名实体识别，算法升级之后，在测试集中跑出来的 F 值更高了，但可能某一条升级之前能够正确识别的语料在升级之后却不能识别了。
这是很正常的现象，尽管有点反直觉，但我们必须要把思维模式转变过来。
总结
随着这个领域的实践和积累，我越来越相信人工智能的发展会给这个行业带来颠覆性的变化，就如同 08 年左右的移动，从最初的自成领域，到如今渗透至所有领域之中。我认为人工智能也是一样，现在我们看人工智能觉得它只代表智能音箱、智能助理、人脸识别、下棋之类相对独立的应用场景，但在不远的将来，它一定会被打散，渗透到各种各样的应用和场景中，成为新的基础设施，作为产品经理，不要错过这一波机会。