热门分类: app推广
欢迎加入: QQ群(爱盈利CLUB) ASO推广/App运营/发文/友链,
关注本站微信
联系我们: 点击这里给我发消息

联系电话:010-58484096

3个套路,教你学会做“高人一等”的产品经理

产品运营 单利强 1096浏览 来源:

做个老好人,那还是初级的产品经理。

3个套路,教你学会做“高人一等”的产品经理

端午三天,一直和好基友混在一起,没事唠唠嗑。

说着说着,就讲到了开会这件事情上,接着就说到为什么开会期间一定要有领导坐镇,最后就讨论为什么产品经理进行需求评审的时候,自己总是不能一次拍板……

首先,他给我举了个例子:

营销科和教训科因为该谁出题而不断撕逼。起因是应公司领导安排,需要一个科室牵头出一套方案,给员工进行营销培训,结束后需要答题留存,问题就出在该谁出题上。

  • 教训科认为:该培训是公司要求且有针对性的,而我们只管培训不管业务,营销科是市场一线,对每个理论了解十分清楚,熟知每条业务线,相对自己部门更加专业,因此,应该营销科出题。
  • 而营销科认为:如果我们出题,还要你教训科有什么用。本身教训科就是主管员工培训,连这点知识都不懂,还怎么培训。如果我们出题,是不是还得我们批卷,你们就是给我们找麻烦添负担,而且我们本身业务繁重,根本没有时间来给你们出题。

这下来了,公说公有理婆说婆有理,两个科长丝毫不让,怎么办?

如果你是产品经理,现在在现场,如何处理?

哥们和我说,最后是老大在现场,听明白前因后果后,当场决定让教训科牵头,出一个人到营销科一边看人出题,一边学习理论,然后将试题拿回来,给学员培训用。

他说,这就是领导的作用:

不管对错与否,按照指示办事,即使是错的,也能快速知道原因,相比扯皮拉筋也是一种更优解。如果你们产品经理能比别人高半级,很多事情都能解决了。

反过来想:作为产品经理,需求场景不够明确,在特殊的情况下,我们是做还是不做?

如果真的认真讨论起来,还不是领导一句话的问题。

但是产品经理又能做什么,如何提高领导倾向性的决策?

回到我们这个话题上,我们产品经理经常会遇到这种类似的问题。如果产品经理遇到这个可做可不做的,技术觉得没啥用,而且实现又麻烦,或者是因为某些原因被迫砍掉一部分需求,又因为这个原因,变相弱化了其他需求,你该怎么办。

每个产品经理都想做正确的事,可是我们90%都是试,而且大多数的结果都是不理想的,不可能每个功能做出来都是用户喜欢的,所以最终总是要有人来决断一下,但又不可能每个细节都要领导来拍板,那只会显得你无能,因此,你得学会决断。

产品经理是需求的定义方,无论是对内还是对外,都是关键的一步。需求来源于场景,有场景就有问题核心,抓住了这个核心,实现方式就顺利而出

一、高人一等来自于你对问题有更深刻的理解

只有你懂了,才能让别人闭嘴;只有你通了,才能指点江山。因此,每当你决定做什么前,提前问问自己,这个是不是符合真实场景,核心问题是什么,你的解决方案是什么。

repeat:真实场景、核心问题、解决方案

当我们做完一遍的时候,基本上表层的问题就能解决,但是更深层次的问题,这些还是不够。不少同学,可能连第一步都无法走完,甚至连真实的场景都没搞清楚就开始设计功能。原因就不去深追究了,根本还是欠缺一些思考。

补充一下:场景是越挖越深的,越深越宽,呈倒三角的模式。每个阶段解决当前场景下的问题,不断积累,才能把一个功能做大做全。不要总想着,一口吃个胖子或事一劳永逸这些,场景调研和功能设计,总是相辅相成的。

接着,要不断问自己为什么,让别人问为什么。一个人的理解是有局限的,完善的意义就在于知道了你之前不知道的事情,所以你就知道的更多。

repeat:自己问自己、别人问自己

二、学会即时的决断

这点主要针对设计中的变通。比方说你做了功能,在开发的过程中,技术提出了另一种类似的方案,甚至提出了你之前没想到的点,甚至有更好的方案。

这时,应该考虑这样做的结果会是什么。如果在同样的情况下,不会造成用户理解负担,用技术认同的方案也是可以的。在多数情况下,我们做的功能,需要得到市场的验证,一旦实现后,我们要考虑能不能获得自己想要的结果。

妥协、调整、合作都是可选的解决方式。关键在于你怎么决断,如果一味的认为自己是正确的,结果打脸,别人也不会认同你。小问题,轻风险,能在接受范围之内,学会一定的变通,可以更好的解决对立的冲突。

再延展一下,当你看见了问题,第一时间指出、延后的指出、不去指出是一门项目管理中的学问,取决于你想达成自己的利益还是想实现项目整体乃至公司的利益。(不多说了,嘿嘿)

三、建立责任范围

我想,做作为产品经理最大的悲哀莫过于:该是自己做的的事情做不了吧。

曾经在一个会议上,领导询问该功能的设计初衷,结果一个设计师抢先回答了这个问题。产品经理还没来得及解释实际的场景,便收回了话语。我想,如果当时是我的话,会在人家说完后,重新补充一下实际场景和对接设计的初衷,至于最终结设计结果如何,可以转给领导来进行批断。

该是你做的,你一个也不能落。涉及到需求、设计、实现,需要你确定的前提,你必须得让每个人清楚的了解。你得让他人清楚你在这项工作中,扮演什么样的角色。

举个例子,在需求定义的时候,你就是定义的核心,其他人想要改,必须要经过你,擅自改动,你一定不能同意,甚至是黑脸打回拒绝;尤其是在项目后期,未经决策和批准,实现结果与预期不符,直接将问题记录,陈清利害,找相关负责人予以解决。

如果事实证明了自己需求定义和功能设计不够完善,那也要重新走一遍变更流程,并在项目中记录实际清咖滚,因为对方在项目中应该提前表明,而不是到了后期,板上钉钉的时候,才知会出来。

学会维护产品经理的职责范围,有助于让你建立更多的自信。做或不做,不再仅仅是因为一句话,而是有产品经理这个角色的协调,有产品经理的推动。这样才能让别人理解你,让别人更加相信你。

做个老好人,那还是初级的产品经理。

我看过的总监,那“怼人”真不是盖的,哈哈!!!

今天和大家分享到此为止喽,thank you~

爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容;是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台;

想了解更多移动互联网干货知识,请关注微信公众号运营小咖秀(ID: yunyingshow)

转载请注明:爱盈利 » 3个套路,教你学会做“高人一等”的产品经理

展开全文
爱盈利
电话:010-58484096
寻求报道 |  广告合作
京ICP备15063977号-2
xml  网站地图
© 2012-2018 aiyingli.com. All Rights Reserved.
微信公众号
 

开发者服务

微信二维码
 

商务合作

微信二维码
 

运营小咖秀

微信二维码