微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

近期有不法分子打着爱盈利的旗号,制作“爱盈利”名称的App,并伪造爱盈利证件,骗取用户信任,以抖音点赞赚钱或其他方式赚钱为名义,过程中以升级会员获得高佣金为名让用户充值。
爱盈利公司郑重声明:我司没有研发或运营过任何名为“爱盈利”的APP,我司做任务赚钱类产品从没有让任何普通用户充值升级会员。我公司产品均在本网站可查询,请将网站拉至底部,点击“关于我们”可查看爱盈利相关产品与服务。
温馨提示:当遇到此类问题请拨打官方电话或添加官方微信,以免财产损失。爱盈利官网地址:www.aiyingli.com。
  • 推广与合作
X

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

来源: 253402

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、学会即时的决断

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

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

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

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

三、建立责任范围

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

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

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

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

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

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

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

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

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

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

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

评论

相关文章推荐

SELECT dw_posts.ID,dw_posts.post_title,dw_posts.post_content FROM dw_posts INNER JOIN dw_term_relationships ON (dw_posts.ID = dw_term_relationships.object_id) WHERE 1=1 AND(dw_term_relationships.term_taxonomy_id = 3083 ) AND dw_posts.post_type = 'post' AND (dw_posts.post_status = 'publish') GROUP BY dw_posts.ID ORDER BY RAND() LIMIT 0, 6

京ICP备15063977号-2 © 2012-2018 aiyingli.com. All Rights Reserved. 京公网安备 11010102003938号