离职倒数18天：重新开始思考一个科技业大家爱揶揄的话题「PM 到底在干嘛」

我最近在考虑要找人来帮忙管理我们的 App。请认识的人介绍时，我说工作内容包括：看用户的反馈然後分类、看付费用户的抱怨然後回应、处理 App 上架的一些规定、观察其他竞品状况等等。我一开始为了想要表示工作量不大，副业也可以，所以自以为幽默的说是打杂的秘书。说完後不久我突然领悟，我如果这样说会有人来吗？何不就说我要找「产品经理」？听起来酷多了！况且这些看起来这不就是真的是产品经理的工作之一吗？

这个瞬间让我想通，难道 PM 这工作就是这麽来的？我刚进公司时就是当 PM，回去看自己当时的日记，发现总是有很多烦恼。如果只是打杂，为什麽我会成天自问自答一些大哉问。於是又重新开始思考一个科技业大家爱揶揄的话题：「PM 到底在干嘛」

我发现这个问题问 PM 时，会偏向回答决策跟愿景之类的比较抽象的答案，至少我当初应该是说了类似的话。但如果问工程师怎样是好 PM，常听到类似「把写程序以外的事情做好，尤其是跟沟通相关的事」。因为跟工程师最常接触的通常是初阶 PM。而 PM 们回答这个问题时，很多人是在形容自己想成为的样子，也就是已经更接近决策端的高阶 PM 主管。实际上，大多数人的日常，应该是在从打杂到产品愿景这个光谱上，各种类型工作都要做，只是看产品跟位阶，比例会不一样。

说到 PM，一个常见的起手式是 P 到底指什麽？有 Program, Project, Product ，我觉得名字差异主要来自各个公司的习惯或偏好，不同 P 的比较只在公司内有效，公司间的比较意义不大。除了名字，PM 工作内容最重要的一个差异，是来自产品的决策是怎麽进行的。如果是瀑布式开发，开发时间较长，决定产品成功与否的指标比较主观，某些人说了就算，那 PM 需要做非常多决策或沟通。如果是资料驱动的敏捷式开发，Release 前一定要做 AB test 看到实际数字变化那种，那 PM 的主要工作就是搬开所有挡路的元素。因为测试越快进行，迭代越快，团队的决策效率越高，产出越快。

虽然已经落跑，但我还是常常在思考「怎样才是好 PM」，为什麽我会失败呢？可能以後想法又会变，但现在我的答案会是：「让所有人都对目前所有已经决定的事想法一致。」我现在遇过的人里面，我觉得可以做到的很稀有，我自己就觉得非常困难，需要花非常多精力，来观察所有人的状态、规划讯息怎麽有效传递。如果有人可以随时让工作小组维持这个状态，那真的是非常高超，我猜大家会抢着跟他工作吧。其实，Satya 的工作不就也是这样吗？

如果可以让我回到过去，送还在当产品经理的我几本书，我会推荐小时候的我看：《非虚构写作指南》跟《你都没在听》。第一本谈英文的实用写作技巧，第二本谈倾听。因为我觉得这个工作的核心就是听跟写。听客户需求，听对口人员的状态，听工作小组中的人的疑问。写下可以说服人的文件，或是所有人都需要知道的事，让大家愿意看且看懂，随时知道现在发生什麽事，让该知道的人都可以随时回来参考。

回顾工作时，我常常问自己，如果让我重来一次，我还是会选择转成工程师吗？我想我会，我很庆幸当初的选择。主要是因为工程师的工作，可以让我学到我当时最想学的东西；另一方面是後来发现，有两种背景让我的经历有特殊性。但矛盾的是，我在自己的 App 里却又做回类似 PM 工作，为什麽？因为这样，我还曾经怀疑过，难道我其实还是比较喜欢 PM 吗？那我不就白忙一场？後来仔细一想，其实跟喜好无关。到头来是因为自己的公司没人，所以我反而没的选，所有没人做的事都要做。反而就是因为在微软这种大公司，想干嘛就干嘛，反正缺人再招就行了。这样说来，真的很推荐想要试试不同种类工作的人，在公司内转好转满，不要客气，对我而言，这就是大公司最大的福利之一吧。

最新文章会分享在脸书：https://www.facebook.com/gigi.wuwu/
欢迎留言讨论