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

不懂技术怎么做产品?15天在线学习,补齐产品经理必备技术知识,再也不被开发忽悠。了解一下>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、学会即时的决断

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

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

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

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

三、建立责任范围

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

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

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

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

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

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

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

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

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

#专栏作家#

朴老师,项目型产品经理,人人都是产品经理专栏作家。主做ToB移动办公软件,爱思考、爱学习,爱交流,欢迎各位留言建议。

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

题图来自 Unsplash ,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
5人打赏
评论
欢迎留言讨论~!
  1. 营销科和教训科,是哪儿的叫法?

    回复
  2. 朴老师又更新了,过来看看

    回复
  3. 学习了,感觉文章把产品上传下达的软技能诠释的很好。

    回复
    1. 兑了还有文章里的嘿嘿,太骚了太骚了哈哈哈

      回复
  4. 碰到一个自以为很牛逼的技术经理,总是私自改动我设计的规则,有点技术控制着产品了,很不爽,有时候技术上如何实现还让我来说,很无奈。故意找茬,我有事确实一些地方没有考虑到,想的不是很全。不知道怎么办,请指教一下

    回复
    1. 你只需要抓住用户的反馈和领导的意见就好。一个对外,一个对内
      1、用户反馈,每一个用户的实际反馈,内容,日期,建议,全部记录。没有的话自己去找,去对比。
      2、每个版本实际结果和用户反馈以正常的口吻陈述,在周会上做总结,如果是改需求,说明修改的原因,看BOSS反馈。如果他觉得没什么,就不必多说,毕竟领导意见为准;如果他问了理由,那可以继续说下去,解释原规则和现有规则的优劣势分析,以及对数据上的影响

      回复
  5. 产品经理的强势是必须的,要么我说了算,我说错没说全,我可以改,要么让我滚蛋。

    回复
    1. 碰到一个自以为很牛的,并且掌控欲望很强的技术经理怎么搞

      回复
    2. 我觉得你说的挺有道理

      回复
    3. 有道理!

      回复
    4. :lol:

      回复
    5. 赞呀

      回复