旧文整理一下重发:
最近跟我一起合作了一段时间的PM(产品经理)离职了,她的工作能力有口皆碑,大家都很喜欢和她一起合作,今天在和接任她的PM的一对一会议上,新PM问我:“你觉得她哪些方面做的好?这样我能向她学习,争取也能像她一样优秀!”
这其实也是我一直在思考的问题:怎么从优秀的PM身上找出他们的闪光点,如何向他们学习。 我尝试着给新PM总结了一下:
首先是她的产品设计基本功不错,能在短时间内熟悉我们的产品功能,并对我们的产品功能做出了不少优秀的改良,对于产品相关的问题,能做出专业的解答。
产品设计是对一个PM最基本的要求。以前有同事问过前PM她都是怎么学习的这些产品知识,她说是通过看Youtube视频学习的。也是,现在想学东西资源有很多,想学总能找到这些资源。
然后她对于需求的优先级处理的挺好。我们团队经常会收到很多其他部门发来的需求,尤其是法务部门,总是催的急,很难拒绝,而她总是处理的不错,一般不会在当前Sprint给我们临时加需求,总能想办法给我们排到后续的Sprint,所以团队总是在按计划有序的在工作,不需要临时处理各种加塞。
在处理需求优先级上其实我做的不够好,所以我曾专门请教过她如何排好需求的优先级,她告诉我她通常需求分成三个级别:
1. 最高优先级是严重影响用户使用的问题,以及对时间要求紧急的法务上的需求。这类需求会尽量在第一时间处理,哪怕有时候需要打补丁。
2. 普通的功能性需求,比如产品新需求,对现有产品的修改等等,默认放在后续的Sprint,这类需求通常占大多数。但是和提需求的人做好沟通很重要,比如要让他们清楚我们日常版本发布的流程,以及可能造成的影响。由于我们每两周发布一次版本,所以最多也就等两周左右,基本上都还能接受。
3. 技术相关的,例如技术债务、性能优化这些,优先级通常要低一些。这种技术相关的虽然优先级相对低一些,但是我们每个Sprint在做计划时,通常会安排20%~40%比例的技术任务,所以总体来说并没有欠什么技术债务。 按照这样三个优先级别来排任务,大部分任务都可以按照优先级排到对应的Sprint中。
但是也有例外情况,就是大领导(CXO/VP)直接要求的紧急任务会相对比较麻烦,她的建议是:
- 要先搞清楚他们紧急加需求的原因是什么? 然后要让领导们清楚这样临时加塞所造成的影响是什么,比如会让系统不稳定,会影响其他正在进行中的计划,或者其他影响。
- 最后如果领导坚持要加塞,没必要正面对抗,可以找PM或者其他领导一起协商,实在不行就给加塞上。
再有就是这个PM对于新产品功能,有很好的计划性,能提前协调好资源,在将需求交给开发时,UI/UX设计、后端API这些都已经准备好了,各种细节也通过文档和多次会议反复确认完成,开发人员只要按照产品设计文档、UI设计文档、API文档去开发就可以,不需要开发自己去反复确认。
这种项目的计划和资源的协调通常是项目经理来做的事情,但是她作为产品经理,自然而然将项目管理的工作也一起做了,最终团队也受益。 所以我经常建议大家学习软件工程和项目管理,不管是你做开发还是做产品设计还是其他工作,工作中融入这些项目管理技能会让你事半功倍!
最后还有一点就是她对日常工作中的问题能做到及时有效的反馈,真正做到了“件件有着落,事事有回音”!
作为产品经理,日常除了要做产品设计,还有就是要经常和开发确认各种产品细节、任务优先级。无论团队中谁通过何种方式问她问题,比如ticket的评论、Slack的消息、会议上的问题,她都会尽可能第一时间回复,哪怕她当时不能马上给出答复的,她都想办法去确认清楚,然后第一时间给出答复。
这种“件件有着落,事事有回音”本职是一种职业素质的体现,当我们和这样的同事合作,他们总能让你放心,问他们一件事情有答案,交代一件事情有结果和及时的反馈,所以我们都喜欢和这样的同事一起共事。
如果简要总结一下我的前任产品经理为什么受欢迎?
首先她作为一个产品经理,最基础的产品设计能力是不错的;在专业能力之上她有良好的项目管理能力,可以妥善处理好需求的优先级,可以有计划有步骤的推进项目,协调好资源;最上面是她的职业素质,“件件有着落,事事有回音”,让她成为团队中一个靠谱的不可或缺的存在,大家都乐于跟她一起共事!
《纳瓦尔宝典》读书笔记 - 第二弹 (原创,全网最全!!)全书 65 条精华1. 追求财富,而不是金钱或地位。
留言
發佈留言