最近我写了一篇话题：如何去选择一个产品经理的好书。

(资料图片仅供参考)

如何选择一本产品经理的书？

得到了不少朋友的共鸣。

最近刚好我在看《微信背后的产品观》，这本书是一本非常小而美的书籍 。

阅读后你发现他实际上是龙哥公开微信发布会的历史演讲合集，也包含了现场的观点讲解和提问互动。

当我今天阅读这本书的结尾，其中一个现场朋友向张小龙提问道：

我感触特别深的是，张小龙的回答：“我更认为人人都是产品经理是一句口号，而不是真的人人都是可以做产品经理，这是不可能的。”

其实我们在真正的研发流程里，是非常鼓励这种方式的。比如产品团队有多个产品经理负责同一款产品，我们一定会有产品组的周会，用来评审需求去拦截所谓的垃圾需求。

我们在开发过程中，每个人都可以像用户一样对产品提出意见，这种口号方式是一件好事，可以避免闭门造车。

团队内部的成员至少相比用户更加清楚我们的短板和劣势，往往提的需求更容易被采纳，而用户提的就有可能是完全方便了个人，逃脱了群体来思考。

恰好我在“Kevin和他的产品朋友社群”里看到一张趣图，就贴切的形容了垃圾需求，是真的会存在。

这张图的设计方案，如果团队有多个同学参与去思考产品设计方案，那就不会有这样的地狱方案了。为了过滤这种垃圾设计方案，我们会有产品团队内部的需求评审和上线前的交叉测试。

字面意思就是把测试同学负责的测试模块进行 相互交换测试。比如原来A同学负责a模块，B同学负责b模块；那么在一轮测试之后，A同学负责b模块测试，B同学负责a模块测试。

我非常鼓励团队测试这样去轮训，毕竟现在的互联网产品研发不可能是一个功能模块就结束了项目，随着用户量新增和外部的环境变化，短期总是有新功能要增加，测试人员要不断熟悉新的业务，才能从整体去评判功能的操作使用情况，做出测试建议。

所以人人都做产品经理的口号，自然让产品得到了更多的关注度，使用的人多了才可以发现一些深藏不漏的BUG，就像我们捉迷藏一样，1个蒙着眼睛人去找大家和10个人蒙着眼睛去找，后面更容易找到。

尤其是产品在没有足够用户的时候，产品的设计人员、研发人员等内部员工就是早期用户。

我以前在大厂做产品工作的时候，发现很多产品经理都是需求来了就马上开始埋头做原型，周一刚给的需求任务，周三原型就出来了。

开发都特别讨厌这种产品经理，源源不断的开发任务，都没有考虑到底有没有效果就马上去做。没有考虑到产品现在到底做的好不好，有没有什么优化项，以及方向到底对不对。

我一直告诉自己带的产品经理会把产品的价值给团队输出，即使是负责开发的同学们，也能够产生共情。而不是冷冰的下发一个又一个需求，这种产品研发的方式没有人愿意去做产品的产品经理。

这特别像流水线那些工人，他们在做任务的时候，是一脸无表情的去完成自己当下任务，至于这个产品到底合不合格，其他人做得好不好他不关心。

每个人都是完成任务的做产品这样是只能做出一款产品，但是做不出优秀的产品，因为没有去产品的价值观，做产品的意义是什么，以及个人成就会带来什么，好的产品经理往往最直接的现象就是和团队打成一片。

有不少朋友特别讨厌“人人都是产品经理”这句话，他们会因为这句话让很多门外汉来做产品经理，玷污了这个职业。

实际上他们只是曲解了人人都做产品经理的本质意义并不是自己去做产品经理的工作，就像张小龙说的，这是一个团队口号，大家要有产品主人翁意识，能够勇于去对产品提出建议。

可是人人都是产品经理的口号，如果一旦发起，会马上给产品经理带来工作的多余挑战，比如这个需求为什么要做？为什么不用其他方案？就会陷入多次争论中，而产品经理要做的是一定要PK到最后，因为只有这样你的需求才是完整的，通过团队检验的。

我见过很多产品经理都和开发的关系处不好，甚至有的老板为了推动研发和团队氛围，会刻意找女性产品经理来做调节（女生好说话）。

所以面对开发，需求文档里的《需求背景》这一版块就特别重要了，讲清楚功能的目的和价值，那么相信任何产品的功能都是可以开发的，就是复杂度和实现成本的区别，和开发敌对的工作方式迟早最后要么就是研发离职要么就是产品换部门。

我的角度是支持的这句口号，因为人人都去做产品经理，至少你的产品关注度和使用人数提升了，你才知道是否有效。

尤其是对于判断自然增长曲线来说尤其重要。

今天的分享都在这。