最近跟我一起合作了一段时间的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的消息、会议上的问题，她都会尽可能第一时间回复，哪怕她当时不能马上给出答复的，她都想办法去确认清楚，然后第一时间给出答复。

这点和她的前任PM形成了鲜明的反差，当初我炒掉她的前任PM，要求产品部门给我换新的PM的一个重要原因就是因为他不能对产品相关的问题给出及时有效的反馈，每次跟他确认什么事情，他都没下文，总要反复确认多次才有结果，久而久之，严重影响效率和团队氛围。

这种“件件有着落，事事有回音”本职是一种职业素质的体现，当我们和这样的同事合作，他们总能让你放心，问他们一件事情有答案，交代一件事情有结果和及时的反馈，所以我们都喜欢和这样的同事一起共事。

------
如果简要总结一下我的前任产品经理为什么受欢迎？

首先她作为一个产品经理，最基础的产品设计能力是不错的；在专业能力之上她有良好的项目管理能力，可以妥善处理好需求的优先级，可以有计划有步骤的推进项目，协调好资源；最上面是她的职业素质，“件件有着落，事事有回音”，让她成为团队中一个靠谱的不可或缺的存在，大家都乐于跟她一起共事！

而她的这些能力，最终让我们团队处于一种相对确定的状态：每个人都清楚的知道产品的需求和优先级是什么，每个产品的问题都能得到答案，不用担心临时加塞的任务，每个Sprint都能有序的完成项目任务！

在这个充满不确定性的年代，一个能让人工作更充满确定性的产品经理，谁会不喜欢呢？