经验分享 | 关于产品经理的十个坑

编辑导语：产品经理是一个项目的主要推进者，在一个项目中起到很大的作用，也是团队的管理者以及推动者；产品经理需要有强大的专业素质，并且有着较准确的判断能力，以及不断积累的经验；本文作者分享了关于产品经理在日常工作中可能会遇到的坑，我们一起来了解一下。

不知不觉在产品这条职业道路上已经走了近三年，虽然常听说人人都是产品经理，似乎是个人都可以做产品设计，但从自身的工作实践来看，现实并非如此。

产品经理所需要具备的一些专业素质不可忽视，目前在正规高等教育体系中尚且没有相应的专业设置，大部分从业者都是在工作中慢慢积累和自我领悟。

一、缺乏业务建模能力

产品经理常常需要接受不同角色的人提出需求，但受限于专业和认知水平各有差异，他们也许不能对需求本质的表述一步到位。

面对这样的情况，就需要产品经理具备良好的业务建模能力，通过业务建模完成业务逻辑闭环，并思考和挖掘业务中潜在的需求风险和阻塞点，在思维上与业务方达成认知共识，确认需求方案。

在业务建模过程中，我常常借助的工具是流程图和思维导图，这两种工具并不需要每次都使用，要视具体情况而定。

若在构建全新的项目需求时，我会先使用流程图构建业务的主体流程和分支流程；然后使用思维导图构建整个项目的主体框架（一二或三级结构）。

若面对的是一个系统中的部分模块需求时，大概率只需使用思维导图或流程图二选一就足够，通常我会选择流程图更多一些。

当面对的是影响范围较小的小需求时，则不需要辅助工具，只需自己在大脑思考明白，可以给人表述清楚意思即可。

业务建模的过程其实就是产品经理深度思考和梳理需求的过程，这个过程尤其重要。理论上应该占据需求处理周期80%的时间，剩下20%的时间用于需求原型和文档的输出；流程图和思维导图是产品经理对业务建模的直接产物；文档和原型是产品经理处理需求的结果产物。

二、思维缺乏逻辑性

作为产品经理，在日常工作中一项重要内容是与人沟通，比如对外有老板、运营、销售、财务、采购、客服、人事、客户等，对内有后台开发、前端开发、测试、设计、运维同事等，他们都可能跟你所负责的产品有关联性。

不同角色岗位的人，对相同的一个问题的思考和认知可能都各不相同，存在主观片面性。只有产品经理最可能是对产品认知最完整，理解最透彻的人，产品经理通常被认为拥有产品的最专业解释权；产品经理如果做不到这一点，可以说是不合格的。

当其他人对产品有疑问时，会优先向产品经理寻求解答，这就要求产品经理在解读产品时，必须要做到思维有逻辑性，表达要清晰，让听者跟得上思维，理解产品经理所解释的每一个产品逻辑。

产品经理在处理每一个需求时，理应遵从哲学上的灵魂三问原则：从哪里来？要做什么？到哪里去？

这三个拷问其实代表着一个需求的完整逻辑链条，从业务上看，意思是一个需求要看它背景是什么，要完成哪些业务操作，最终实现什么业务目标；从产品上看，意思是一个功能要知道它每一个字段来源于哪一个数据表，要操作哪些系统功能，最终得到什么数据结果。

当产品经理基于灵魂三问原则处理需求时，便可以非常简洁明了地表述明白需求的来龙去脉，使听者快速理解相关产品逻辑。

三、原型、文档描述不全面

在处理需求的过程中，产品经理有两样最常见的工作产物-需求原型、需求文档。一些新入行的人，常常会错误地理解这些工作产物的本质意义。需求原型，是产品经理构建产品时的模型设计，是对需求理解的具体体现；需求文档，是产品经理构建产品时的逻辑解释，是对需求边界的具体界定。

需求原型，早些年只能在纸上画草图，之后逐渐在软件上用线框图+连接线示意，现在随着原型工具软件越来越智能，产品经理可以使用带有交互效果、更逼真的工具软件输出一定程度的保真效果原型。

需求文档，是产品经理因为不能通过原型完整地体现产品的边界逻辑时，需要用文字进一步详细描述；有些产品经理写的需求文档不仅要包含业务逻辑，异常情况界定，字段解释以外，还要写很多的交互逻辑，文档内容显得特别冗长，对阅读者来说会非常难受。

其实需求原型和需求文档是相辅相成的，当产品经理向业务方做产品演示或者和研发团队做需求评审时，通常只需演示需求原型即可；有时候也会用到流程图和思维导图，便于抽象的业务解释。