启示录2:打造优秀的产品团队

iamsujie

共 2772字,需浏览 6分钟

 ·

2021-07-21 03:53

十年前,一些朋友和我以 七印部落 的名义引进了《启示录:打造用户喜爱的产品》,当初的很多读者现在已经走上产品领导者的岗位,作者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本书,现在做创业者服务,良仓孵化器创始合伙人,也是产品创新独立顾问。

如需产品经理/产品思维/产品创新相关领域的培训咨询服务,欢迎联系下面这个微信(i13758212411)。
浏览 21
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报