产品经理最容易犯的十大顶级错误

做好一个产品经理非常不容易 经常容易犯错误 本文详细描述了产品经理经常犯的十大 顶级错误 对产品经理 技术负责人 创业者 都可以借鉴 产品经理需要创造产品 上帝也是个产品经理 他创造了人这个产品 做一个成功的产品非常难 除了需要有资源 时机等问题以外 更大因素在产品经理 好的产品经理能协调资源 能把握时机 但产品经理自己也经常犯错误 最近翻看了之前的记录 发现资深产品专家 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 Cag