程序员

注册

 

发新话题 回复该主题

关于产品经理的十个坑人人都是产品经理 [复制链接]

1#

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

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

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

一、缺乏业务建模能力

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

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

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

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

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

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

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

二、思维缺乏逻辑性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、对产品没有owner意识

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

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

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

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

五、不懂决策权归属

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

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

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

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

六、缺乏产品规划能力

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

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

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

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

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

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

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

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

做产品的规划(以B端产品为例),我觉得可以根据从几个方面做思考:

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

七、无团队协作能力

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

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

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

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

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

八、业务调研能力弱

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

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

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

九、不做会议纪要

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

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

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

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

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

十、产品需求不分级

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

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

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

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

十一、总结

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

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

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

愿常怀感恩心,用心做好产品!

本文由

稻田原创发布于人人都是产品经理。未经许可,禁止转载

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

分享 转发
TOP
发新话题 回复该主题