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

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

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

一、缺乏业务建模能力

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

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

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

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

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

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

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

二、思维缺乏逻辑性

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

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

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

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

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

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

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

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

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

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

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

需求文档通常在具体的功能开发和测试阶段用到，便于研发人员和测试人员对功能的字段数据界定有清晰的结论参照，同时也为了对相关的功能逻辑和需求结论留档备份，以便日后有需要时可查找。

由上文的表述，可以认识到产品经理在输出产品的原型和文档时，一定要特别注重完整性和简洁性。

我个人认为产品经理在原型输出上应该尽量追求产品保真度，页面交互尽量做完整，一方面可以更直观地感受和体验产品模型，快速验证和评估产品功能的可行性，另一方面可以让对应的需求文档更精简，减少阅读者的阅读量。

四、对产品没有owner意识

前文已说到，产品经理要做到对产品认知最完整，理解最透彻，解释最专业。简单来说，产品经理要定义自己是产品的创造者，拥有对产品的最直接决策权，因而产品经理应当要具备有owner意识。

一个业务需求，当它转化成具体的产品功能，在需求评审时可能存在多种实现方案，这时作为产品经理，应当主动结合各方的建议和意见，最终给出一个确定的方案结论；比如从深圳到北京，可以选择做火车、动车、飞机或是自驾等，选择什么交通工具会对旅途时长有影响；产品经理可综合各方的意见和诉求，取最大公约数，选择大家都普遍都可接受的交通工具（比如高铁）。

也许有时候会觉得自己不具有话语权，常常被老板、业务方或者研发部门刁难；但我认为，产品经理要通过对产品的专业性去争取话语权，争取产品的决策权。

其实在实际中，我见识过一些产品经理，当别人希望他做决策时，总是缺少勇气，畏首畏尾，这是非常糟糕的表现，会严重影响自身作为产品经理在团队中的身份认同。

五、不懂决策权归属

前文说到，产品经理对产品要有owner意识，要努力争取产品的决策权，勇敢参与决策。

实际工作中难免还是会遇到一些自己不能轻易做决策的问题，但这时候产品经理不能让问题一直悬而未决，而要明确清楚谁可以做最终决定，谁对结果负责，找到对应的对接人，落实决策结论。

产品经理主要对产品负责，事关产品的任何事项，产品经理都应当积极推动执行，否则若是最后出了差错，产品经理是要负主要责任的。

所以产品经理在日常工作中， 涉及到产品需求的任何事，一定要认清自己是第一责任人，越是重大的需求，越是要积极主动推动它，不管需求最终是被研发部门拒绝，还是需求提出人放弃，产品经理都要落实到位，并将需求结论同步到各个相关方。

六、缺乏产品规划能力

每一个产品都有生命周期，分为出生、成长、成熟、衰落、死亡五个阶段。通常我们所参与的产品项目处于出生期和成长期居多，毕竟多数人不会愿意参与一个正在走下坡路的项目。当产品经理接手一个产品项目时，他便成了这个产品的主导者，要像一个匠人般慢慢去打磨它。

在宏观上，产品能体现一家企业的商业模式和企业文化；在微观上产品能体现缔造者的思想和意志。

作为产品经理，当我们接手一个项目时，在熟悉业务的同时，我们需要扪心自问一个问题：这个产品，你真的愿意投入时间和精力去做好吗？

人生短暂，只有内心认可了，才会舍得投入心力去做事情。

所谓的产品规划，其实是对产品的生命周期做计划，以目标为导向解决产品每一个阶段所面临的各种难题和困境。 在规划产品时，产品经理要考虑清楚产品的远景目标是什么？需要切分几个阶段完成？每个阶段要解决哪些问题？……

有时候在公司的战略层，也许老板会提出一个比较宏观的发展方向，比较抽象，作为产品经理需要在战略层的方向上去做更具体，更能落地的产品规划，层层拆分细化，把大目标拆成小目标，小目标转化成具体明确的产品需求，推动研发团队逐步去实现。

就好比说一个小孩子，父母在其成长过程中会有一些期待，希望小孩将来成为某些方面的优秀人才；然而要成为一个优秀的人不是一蹴而就的，需要慢慢培养，做人生规划；不同年龄阶段完成相应的训练和成长，每一步都做好做扎实，最终才能达到目标。

在我看来，一个好的产品经理，一定是能够做产品做规划的，不能做规划的要么是产品经理不认可该产品，要么是自身能力欠缺。

做产品的规划（以B端产品为例），我觉得可以根据从几个方面做思考：

• 考虑产品mvp版本的构造，即产品的主线业务流程要顺利走通；
• 考虑继续填补完善产品的次级业务流程；
• 考虑在产品的数据分析能力方面做更多的发力；
• 考虑产品在用户体验、优势服务上进一步增强；
• 考虑产品的跨平台连接能力，使产品在行业市场上更具柔性和生命力。

七、无团队协作能力

产品经理与研发团队在日常协作是最紧密的，可以说是一个锅里吃饭的战友。产品经理名义上有“经理”的头衔，但是也仅仅是对产品负责，没有任何的行政管理职权，与研发团队共事十分考验产品经理的协作能力。

跟程序员接触多了就会发现，他们的世界观是非常清晰的，任何问题只要逻辑能够解释清楚，就可以通过技术实现。

他们对产品经理的反感之处主要在于两点，一是产品经理常常提出一些逻辑不能自洽的需求，叫做不合理的伪需求；二是产品经理经常对需求变更实现方案，导致开发需要返工，费时费力。

作为产品经理，一方面要针对上面两点常常自省和加强学习改进外，另一方面要多留心观察不同人的性格和表达方式，以对方易于接受的方式进行沟通，常怀同理心。

面对研发团队，妄图靠所谓的小恩小惠或者私交情去对接工作基本是没有希望的，唯一的好办法就是对每一个需求方案都做得足够细致，思考到位，在需求评审会中让人家看到自己的专业性，产品经理才能在团队协作中建立真正的影响力。

八、业务调研能力弱

产品经理在处理产品需求时，常常会无意识地犯一个错误，即做需求时思考过于主观，缺少必要的需求调研过程，或者说需求调研的深度还不够，没有探索到需求的本质。

对于业务方来说，通常他们在提出需求时，常常因为当下在使用产品功能时遇到了困难，然后给产品经理提过来一个具体的解决方案，即“能不能实现……”“能不能做到……”等等，如果不细究追问，就不会知道他为什么需要这个功能，即需求的产生的背景是什么，也不会知道做了这个功能后最终能满足对方什么期待。

我以为，当业务方提出需求时，不要轻易地答应对方且以对方提的方案作为产品需求方案，要多沟通尽量详尽地了解情况，也许最终只是他们的操作方法不对；也许还有其他更好的方案可解决问题；也许那本身就是一个不可实现的伪需求，等等。

九、不做会议纪要

产品经理与其他业务部门对接需求，或者是与研发团队开需求评审会时，一定不能忘记做好会议纪要。做会议纪要最重要的是记录下在会议沟通中大家共同认可的问题/需求结论，以及会后需要相关责任人进一步跟进的事项。

尤其是超过半个小时以上的会议，切记不要妄图靠脑子记忆；如果觉得当时记录来不及的话，可以考虑会议前打开手机的录音功能，会后再过录音回放提取要点记录下来，并公布给大家。

特别地，产品经理在跟研发团队开需求评审会时，研发人员（研发组长）常会对需求方案提出一些细节问题，需要产品经理会后做补充调整。

产品经理最好是先记录问题点，会后再做跟进处理，而不要把评审会变成头脑风暴会，占用其他同事的工作时间。

有效地把控好需求评审会的时间节奏，研发同学们会发自内心感谢你的，相信我！

十、产品需求不分级

在做产品的过程中，产品经理不可避免地会接到各种各样的需求，而且研发资源短期内也可能不会有更多投入。

面对日渐繁多的需求，产品经理需要对需求进行分级处理，通常按照重要且紧急、重要不紧急、紧急不重要、不重要不紧急四限象进行划分；即使是重要且紧急的需求居多，也要做好区分，根据研发资源酌情处理，否则产品的迭代计划就是一团乱麻。

需求分级，一是为了对了解业务方对需求满足的渴望度以及产品的迭代预期；二是根据实际情况合理分配研发资源，重视ROI。

对需求合理分级也是产品经理综合能力的一种体现，需要对需求有足够的理解、对产品迭代有清晰的规划、对研发资源有合理的判断预期。

十一、总结

产品经理这个职业，表面上没有什么突出的硬件要求，却在软实力方面有较高的无形门槛。绝大多数人即使入了行，也总是停留低水平领域止步不前，究其原因，可能连上文提到的十项能力还远远不足。

其实仔细想想，产品经理这个职业，很像是工匠传承的师徒制；很多时候没有办法通过统一的教科书进行规范式教学，更多只能在产品实践中，前辈以传帮带的形式带领着后辈成长，在一个个具体的产品项目中摔打磨练，总结经验教训，慢慢成为相关领域的行业专家。

能够走上产品经理职业道路的人，多数都是倍感幸运的！因为除了能在工作中获得诸多成就感以外，更多在于产品思维和习惯的养成，对个人生活上也有诸多正向激励，受益良多。

愿常怀感恩心，用心做好产品！

本文由@稻田 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议。