什么时候才应该聘请产品经理？ | 荐文 2017 #51

《一周产品好文推荐》系列马上就更新到 52 期，也就是一年了。最后两期，将完全是产品经理的文章合集。

---

1

When should you a hire a Product Manager?

什么时候才应该聘请产品经理？这篇文章给出了几个实在的建议：

• 在产品出现痛点之前，不要聘请。怎样判断什么时候才出现痛点呢？当团队不知道为什么做产品时；当需求太多不知道什么更重要什么值得做时；当解决方案不奏效时……

• 当你能找到方法/人来解决痛点时，不要聘请。比如，客服同学能够兼职产品测试的话，那让帮忙有何不可？

当然，这不是让你别聘请产品经理。以下情况出现时，就可以考虑是否应该聘请一个产品经理：

• 当你不能全身心投身于产品时（无论是否有过产品经验）
• 当产品开始变得复杂时
• 当设计/开发团队开始扩大时

2

The Three Jobs of Product Management

一个优秀的产品经理，应该同时做好这三种角色：

• 团队协调人
• Vision Holder（不知道咋翻译较好）
• Business Owner（也不知道咋翻译较好）

但这并不意味着，你得把时间均分在三种角色上。反而是，随着自己能力和团队的发展，你所分配的时间应该从 1 到 3 递增。也就是说，你不能只顾着产品如何协作、项目进展如何等等，你还要让大家知道为什么做这个产品，以后的愿景是什么。最后，你还得为这个产品负责，去关心各种产品数据，关注竞品，关注新技术，关注用户客户需求，关注如何赚钱等等。 事实上，一个优秀的产品经理要做得比这三种角色还要多得多，反正，没人做的你来做就对了。

3

Behind Every Great Product

每一个优秀产品的背后，都有一个默默付出的产品经理。真的？这会不会扩大了产品经理的作用？这篇文章就举了 6 个例子来说明这个问题。当中一个观点深得我心：

The role I would argue that the product manager is most similar to is the role of the CEO. But with the obvious difference that unlike the CEO, nobody reports to the product manager.

4

Do I need to be technical to be a Product Manager?

这是个有争议性的问题。我不是技术出身，所以自然对这个话题比较在意。看过不少文章和观点，我比较倾向的结论是：不需要技术出身，但懂技术绝对是加分项。作者的观点很赞：

I don’t screen PMs based on if they’re “technical” or not. I screen PMs based on if they’re curious about how things work. They’ll be “technical” soon enough.

嗯，好奇心才是必需项。

5

Confessions of a Product Manager

产品经理最应该关注的事情是什么？让产品活下去。在用户体验、商业和技术（或设计）的三座大山面前，我们常常关注用户体验（噢增加一个动效能让用户更开心），但对商业部分——赚钱是否一样热心？产品经理 Paul J 就写了这篇忏悔文阐述自己当初做错的最大问题：没有早早意识到商业化的重要之处而错选了商业模型。

6

Want to be a Product Manager? Be One

在找产品经理的工作？看看这篇文章吧。其中一个观点说得绝妙，大致翻译是「不要只是通过发简历来传达你的激情。那不够。你的背景或经历也不是问题。唯一令人在意的是，你有多明白我们（公司）要解决的问题，以及你将如何解决。」

还有一个非常实用的建议：「别只知道发简历，花时间去了解人家的产品、用户和解决方案。自觉当一段时间的非官方产品经理，找到有用的想法来改进人家的产品吧。即便你的想法不够说服力，人家也会感受到你的用心付出。即便你没有被招进去，那段付出也会让你脱颖而出，有所回报。」

7

Learning in Product

似乎，人们常常以产品经理所在的公司作为优秀与否的评判标准。在 BAT 的肯定很厉害吧？也许吧，但别忘了也有不少烂人在。 有些产品经理金碧辉煌的，可能是因为她/他所在的团队厉害（而她/他本人不过尔尔）；有些产品经理个人能力很强，但却因为选错团队而声希味淡。 没有标准，也不必在意是否达到了优秀。重要的是，你知道自己不知道什么，知道自己还应该学习什么。