十年前，一些朋友和我以 七印部落 的名义引进了《启示录：打造用户喜爱的产品》，当初的很多读者现在已经走上产品领导者的岗位，作者Marty·Cagan又适时送上《启示录2：打造优秀的产品团队》。产品领域的书看过很多，但从产品负责人视角来聊团队、管理、组织等话题的，这还是第一本。书里的很多内容都很有启发，比如“如何把一个产品划分给多个产品经理去负责”，推荐大家都收藏一本。
只不过，还没上市，我看的是 预览版。
2011年，《启示录》由我组织的七印部落引进并翻译，成为我们那一代产品经理的经典。
2019年，《启示录（第二版）》由中国人民大学出版社发行，但市场反馈不如第一版好，和翻译质量有关，也和时代有关。毕竟相较于2011年，国内产品经理的平均水平已经上升了一大截，可以参考的图书也多了很多。
2021年，Marty携SVPG（硅谷产品集团）团队推出《启示录2：打造优秀的产品团队》，自然要看看是否能再次引领？正巧人民邮电出版社引进了这本书，给我寄来了还未上市的预览版。
快速翻完，结合我的理解分享几点零零碎碎的笔记，大家看了感兴趣就等书上市吧。
__________产品的事，可以简化为两件，一是“build the right product”，二是“build the product right”。前者是方向问题，属于产品探索的范畴；后者是方法问题，属于产品交付的范畴。按我的理解，前者重“问题域”，要“用心听”；后者重“方法域”，重“不照做”。真正的产品团队要做的事，缺一不可。
产品创新要面对两大风险：市场风险与技术风险，Marty把他们又细分为四个：价值：客户是否会购买或选择使用产品（市场侧）；可用性：用户是否了解如何使用产品（市场与技术都有）；技术可行性：团队是否有能力开发产品（技术侧）；商业可行性：利益相关者是否支持团队提出的解决方案（市场与技术都有，这里的技术更广义）。甚至，还要再加一个“道德风险（是否应该开发某种产品）”，是对社会责任的考虑。结合到我的5MVVP里Prototype阶段，很可能要做多个原型来验证不同方面的风险，“Fake it till you make it”，每一个产出的假产品都是“借假修真”。
产品团队有两种，功能型团队与自主型团队。功能型团队被动做功能，有个内部的“需求方”，无权决定解决方案，也不用对业务结果负责。而自主型团队收到的输入是“有待解决的问题”，可以自行探索解决方案，并对结果负责。Scrum团队更接近功能型团队，重交付，虽然有PO。
在功能型团队中，产品负责人的天花板是明显的，大约相当于大厂总监级别，而自主型团队的产品负责人可以无缝切换为业务负责人，至于Scrum团队中的PO，似乎更接近于基层骨干或主管级别。以上几种身份，并无好坏之分，只是要结合自己的职业生涯的阶段，判断当前是否匹配。
这段扎心：在推行功能型团队模型的公司里，产品功能通常由利益相关者提出。正因为如此，利益相关者视自己为“客户”，视产品团队为“受雇的IT资源”（类似于外包）。换言之，功能型团队的宗旨是“为业务服务”。
这背后，体现出大老板对公司业务、产品、技术，以及现有团队能力的理解，亦有其适用场景。
功能型团队更适合KPI，自主型团队才可以考虑OKR。设置OKR时，可以考虑给多个风险偏好的目标，一个跳一跳够得着的，一个激进的。
功能型团队是雇佣兵，自主型团队是传教士，通常前者的单兵战斗力远远低于后者，至于综合成本孰高孰低，值得很多企业，结合新常态重新思考。
Marty认为产品领导者需要教练技术、布道、团队激励，这点我非常认同，并且在几年前专门去学了一些教练、引导、触动的技术，并用于一些咨询场景下。当然，这些也是各类领导者通用的技术，不再展开。
如何评估产品经理？这个框架有参考意义。首先是三大方面：产品知识；流程方法；人际交往能力与责任。
- 产品知识：用户和客户知识；数据知识；行业和领域知识；业务和公司知识；产品运营知识。
- 流程方法：产品探索方法；产品优化方法；产品交付方法；产品开发流程。
- 人际交往能力与责任：团队协作能力；利益相关者协作能力；布道能力；领导能力。
如何考察面试者的不足之处？直接问可能难以得到答案，可以考虑把几个重要能力让面试者排序，然后多问问排在后面的选项。
对产品负责人来说，似乎有个不可能三角：解决眼前问题，不妨碍产品长期发展，保持自己的诚信。
管理产品团队时，如何给多个产品经理分工？更推荐与客户（问题域）一致的方式来划分，比如：
- 用户类型/画像：乘客端、司机端；
- 细分市场：3C数码、服饰；
- 用户旅程的不同：用户引导团队、用户留存团队；
- 销售渠道：自助服务团队、直销团队；
- 业务KPI：新用户增长团队、用户转化团队；
- 地理位置：北美团队、亚太团队；
而不是很推荐按照解决方案域内给团队分工，比如：Web端、iOS端、安卓端、后台……
其背后的原因，可以参考康威定律：一个组织设计的系统反映出该组织的沟通结构。换言之，产品是沟通方式的缩影，跨部门沟通绝非易事。
产品探索阶段，应该如何借助外力，Marty的建议可以参考：不要找大型咨询公司，主要有两个问题，一是他们更偏重（价格更高的）商业策略层面，很少能落地到产品，二是通常为短期合作，行业深度不够，毕竟长期……预算不够啊。所以，可以找有志于长期合作的小型咨询公司。当然，这段话背景，要考虑到Marty自己就在做小型咨询公司这个事实，以及我也在做小型咨询公司这个事实。
最后，收一下，在看这本书的时候，我有一种明显的感觉，就是在部分领域，国内同行的研究深度可能已经超越硅谷了。举个例子，书里提到的不同产品团队，比如在多业务下自然分化出的前端用户产品和后端平台产品，在国内稍大一点的公司里已经是常识。甚至，国内在2017年左右就提出了中台的概念，继而分化出数据中台、业务中台、技术中台……等等概念。
这种超前的感觉，是在10年前看《启示录》之时没有的，但，我们还需要更多的布道者，把内容整理出来，宣传出去，这个希望广大同行能在做好自己的一亩三分地之外，一起帮助整个行业的成长，甚至对海外输出，成为标准，而我们已经有这样的基础了。
就这样吧。
文：苏杰（iamsujie），前阿里产品经理，写过《人人都是产品经理》系列共4本书，现在做创业者服务，良仓孵化器创始合伙人，也是产品创新独立顾问。
—— 如果觉得文章还OK，请转发 ——
特别提示：关注本专栏，别错过行业干货！
PS：本司承接 小红书 / 淘宝逛逛 / 抖音 / 百度系 / 知乎 / 微博/大众点评 等 全网各平台推广；
咨询微信：139 1053 2512 (同电话)
首席增长官CGO荐读：
更多精彩，关注：增长黑客（GrowthHK.cn）
增长黑客（Growth Hacker）是依靠技术和数据来达成各种营销目标的新型团队角色。从单线思维者时常忽略的角度和高度，梳理整合产品发展的因素，实现低成本甚至零成本带来的有效增长…
本文经授权发布，不代表增长黑客立场，如若转载，请注明出处：https://www.growthhk.cn/cgo/product/44241.html
微信扫一扫 
支付宝扫一扫 
