【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

Product Mastery 作者访谈

  • 2017-05-24
  • 本文字数:3452 字

    阅读完需:约 11 分钟

关键点

  • 理解杰出的产品负责人共有的特质与品质
  • 探究成功的产品负责人的思维过程
  • 有助于开发更好产品的一些实用工具与技巧
  • 产品负责人用来自我反省和进步的框架
  • 理解产品负责人角色的困难之处,以及怎样克服这些困难

“最优秀的产品负责人对他们的客户有着极致的好奇心。他们会实地观察客户、访谈客户,与客户合作并请客户参与开发流程。”这段话出自 Scrum 与领导力教练 Geoff Watts。在他的新书 _ Product Mastery _ 中,Geoff 探讨了“优秀的产品负责人与杰出的产品负责人之间的区别”。

InfoQ 读者可以下载 _Procudct Mastery_ 试读章节

InfoQ 采访了 Geoff Watts 并咨询了他在诸多问题上的看法:产品负责人怎样进行决策?产品负责人如何深入理解客户需求并挖掘团队成员与利益相关者的知识?怎样有效与团队和利益相关者协作?产品负责人如何增强自身技能?

InfoQ:是什么让你下决心撰写这本书?

Geoff Watts:写出 _Scrum Mastery_ 后我收获了大量正面反馈,有很多人请我为产品负责人写点类似的东西。我觉得虽然市面上有很多东西从实践角度来指导产品负责人,却几乎没有谁探讨这个角色的人际关系和心理层面的内容。比如说,安排优先权(prioritisation)是较难掌握的技能,有很多文章介绍了具体的操作技巧。但从另一个角度来说,为什么它让我们犯难?我们该怎样较为轻松地应对它?这是我想要探究的话题。

InfoQ:这本书仅仅是为产品负责人撰写的吗?

Watts:不是的。显然我主要针对的是从事这一职位并想要更好地完成工作的人群,抑或是刚入行想要了解些内幕的新手。不过我相信本书的内容与很多人相关,可以让 Scrum Master、开发者、客户了解一些事情,比如说他们的产品负责人在做些什么。由此以来,人们就可能体会到产品负责人从事的是多么困难的工作并体谅他们的难处。

我听过很多敏捷团队指责他们的产品负责人令团队工作举步维艰,一团乱麻或毫无建树。有人会说“我们的产品负责人不够称职”“我们的产品负责人优柔寡断”。但当我们设身处地体会产品负责人的处境时,就能明白为什么他们做事这么困难,以及我们怎样做能帮一些忙。

因此敏捷团队、Scrum Master、与敏捷团队互动的利益相关者都可以是本书服务的读者群体。我写这本书主要面向产品负责人,但很自然地,整个团队都能从书中收获益处。

InfoQ:产品负责人经常要根据质量不高、内容不完整的信息来做决策,他们是如何做到的?

Watts:这绝对是产品负责人的工作中最困难的部分之一,但杰出的产品负责人往往有很多应对策略。杰出的产品负责人会:

  • 简化问题。他们会试图减少可选方案的数量,尽可能降低错误决策的代价。
  • 寻找决策依据——决策是基于利润、学习还是交付速度等因素?如果他们明确了决策所要达成的目的,工作就会变得简单一些。
  • 避免独断专行。他们会请合适的人员参与制定决策的流程。
  • 勇敢面对,承认完美不可能实现,尽可能作出最佳决策,同时承担评估决策的责任。
  • 充满自信。

InfoQ:在团队内工作时,产品负责人怎样分辨哪些决策可以独立作出,哪些需要其他团队成员的帮助进行决策?

Watts:对团队来说,有一套制定决策的流程是非常重要的。由于产品负责人可能需要面对的决策场景太多了,让他独自决定所有事情是不现实的。就算时间足够也不该让一个人做出全部的决定,否则会降低决策的多样性、质量和参与度。所以最优秀的产品负责人倾向于建立一套制定决策的流程。

第一种策略是挑出简单的决策——就是那些风险低、不那么复杂,不需要太多外部支持的决策。杰出的产品负责人懂得怎样分辨出简单的决策。他们要么快速做出决定(当两边都提不出有力的方案时),要么将选择权交给其他人(当他们期望利益相关者的更高参与度和支持时)。

例如,产品负责人可以较快速地决定产品包装的体积和形状。然而如果产品负责人要把这一问题的决策权交给其他某人,这个人在产品开发中的重要性就会明显提升——于是他就更有动力促成产品成功。一般来说,人们越是深度参与到制定决策的流程中,他们对决策的参与度和支持就会越多。

当产品负责人必须依赖自己管辖范围之外的资源来促成某项行动时,获得支持也是同样重要的事情。例如,产品的发布日期可能会关系到很多人。当这些关联方深度参与到决定发布日期的过程中时,他们就会更有动力去保证产品按时发布。

因为发布日期关系到如此多的员工,直接影响到项目的底线,决定发布日期的过程无疑远比决定包装的大小和外形更为关键和复杂。由此,多数杰出的产品负责人通常会建立一种协作机制来决定最佳发布日期,而不是将选择权委托出去。相比独立决策,协作决定需要更多的时间、精力、沟通和耐心。因此产品负责人不能事事寻求协作决策——这种策略仅限于复杂的、需要很多支持的决策。

矩阵的最后一个象限表示那些复杂但是不需要太多参与度的决策。一个例子是选择用来集成的第三方产品或者基于何种技术开发产品。在这些场景中,杰出的产品负责人倾向于建立“咨询而非决策”的策略。这些决策托付于他人的风险太高,争议性又没有大到需要多方参与的程度,却依旧需要专家的建议。对于此类决策,杰出的产品负责人会收集足够多的信息和建议才会做决定。

InfoQ:请问你对理解客户需求方面有什么建议?

Watts:从我的经验来看,杰出的产品负责人对顾客有着极致的好奇心,并会实地观察顾客,访谈顾客,与顾客合作并请他们参与开发流程。

我常听到的一个说法是“顾客不知道他们想要什么,除非他们见到不想要的东西”。我发现杰出的产品负责人会快速向用户展示内容,从而判断哪些是顾客想要的,哪些不是。一般人会不断改进产品直到觉得顾客会满意为止,但杰出的产品负责人不会受这种本能的干扰。

InfoQ:产品负责人怎样利用团队成员与利益相关者的知识?

Watts:如果我请别人给我倒一杯茶,那么我能期望的东西顶多也就是一杯茶。也许我会让别人特别留意我所喜欢的茶以及我喜欢它的原因,但我能得到的还是一杯茶。但如果我不是简单地请人倒一杯茶,而是解释我真实的需求是什么,那么我就可能收获自己意想不到的解决方案。

一个开发团队的知识与技能的集合是非常庞大的。如果我要求的是一个具体的解决方案,那么一方面我没法从这个集合中得到更多的创造力,另一方面团队成员对方案的参与度和支持度也会减少。“我”的解决方案是一杯茶,但如果我的目标定为解渴,那么不管团队提出了怎样的解决方案,这个方案都是“我们”的成果。

InfoQ:产品负责人怎样才能一边鼓励团队自治,一边掌控产品的开发?

Watts:这就是整个敏捷产品开发方法的关键所在。产品负责人关注于“What”——目标是什么,期望是什么,需要解决的问题是什么,市场机会在哪里,等等——还有“Why”,为什么它们重要或有价值。杰出的产品负责人接下来会请团队来研究这一目标“How”,怎样去实现。产品负责人可以说“我已经确定这个产品或服务是有价值的。这些人需要这种产品,原因是如此这般。你们大伙儿能同我一起设法把这个设想变成现实吗?”这会是很有用的做法。

InfoQ:产品负责人怎样同团队和利益相关者有效协作?

Watts: 这个问题上最重要的是空出时间来讨论。我知道这对产品负责人来说很困难,因为这个角色注定会忙得不可开交。但杰出的产品负责人会坚决优先处理需要协作的重要内容,腾出时间讨论协作相关事宜,尽一切可能确保这些讨论的时间不被占用。

InfoQ:关于产品负责人增强技能的方法,您还有什么建议吗?

Watts:我发现杰出的产品负责人共有的另一项关键模式是定期反省。我一对一指导的产品负责人都受益于腾出时间分析不同的场景,从而搞清正在发生的事情是什么,事情为什么会出现,当时大家都在做什么。这些产品负责人将产品开发中的敏捷观念应用到了自身的发展上面。他们给自己定下目标,立志成为杰出的产品负责人。他们会研究自己怎样才能变得出色,然后花时间有意识地练习以增强那些会让自己脱颖而出的领域,然后停下来反省并再次出发。

作者介绍

Geoff Watts在敏捷开发领域是一位有多年经验的思想领袖。他的著作、培训和指导帮助了全球数以千计的团队更加高效地交付更好的产品。Geoff 是 _Scrum Mastery: From Good to Great Servant-Leadership_ 和 _The Coach’s Casebook: Mastering the Twelve Traits That Trap Us_ 的作者,后者获得了 2016 年国际图书奖。他培训和指导产品负责人、Scrum Master 和领导成员。了解他的详细资料请访问 www.inspectandadapt.com。

查看英文原文: Book Q&A on Product Mastery


感谢张卫滨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2017-05-24 17:22948

评论

发布
暂无评论
发现更多内容

我是如何读完技术书,然后忘得一干二净的

ayesd

读书 读书方式

流量的战场,如何做裂变?

Yanel 说敏捷产品

产品 产品经理 产品设计 产品开发 产品推荐

粗糙的草稿编辑成文章的五个步骤

董一凡

写作

如何度量敏捷开发团队

Yanel 说敏捷产品

敏捷 敏捷开发

扎心!天天写代码,方向真的对吗?

Apache Flink

大数据 flink 流计算 实时计算

我的理财小心得

史前靓仔

游戏夜读 | 游戏数据分析师

game1night

DIY 可用性测试

Yanel 说敏捷产品

产品 产品经理 产品设计 测试 产品推荐

变化在加速,你的机会和挑战在哪里?

Yanel 说敏捷产品

产品 产品经理 产品设计 产品开发 产品推荐

Mac效率配置指南

Winann

macos 效率 效率工具 Mac

职场寒冬,给你讲四个小故事

池建强

人生 职场

python 文章中图片下载

Flychen

从"远程工作"到"分布式团队"

Yanel 说敏捷产品

项目管理 敏捷 敏捷开发

人是一切

Neco.W

个人感想 感悟

2020版Kubernetes快速上手指南,让你所见即所得

ABC实验室

Kubernetes 容器 云原生 群集安装 新手指南

聊聊“坚持”这件事

小天同学

个人成长 写作 坚持 自控力

为什么公众号订阅没有「分组」的功能?

Fenng

微信公众平台 产品设计

自动化测试框架知识,读这一篇就够了!

禅道项目管理

程序员 DevOps 自动化 测试

你必须了解的产品经济学

Yanel 说敏捷产品

产品 产品经理 产品设计 产品开发 产品推荐

Netty 源码解析(七): NioEventLoop 工作流程

猿灯塔

你懂什么是"结对测试"么?

Yanel 说敏捷产品

产品 产品经理 产品设计 产品开发 产品推荐

常用电脑软件清单

彭宏豪95

软件 工具 windows 生产力

PyTorch 1.5 发布,与 AWS 合作 TorchServe

神经星星

人工智能 facebook 微软 亚马逊云 AWS Lightsail 工具

Linux-常用命令

Flychen

Linux

"深刻创新"八步法

Yanel 说敏捷产品

产品 产品经理 产品设计 产品开发 产品推荐

学会用"云—雨—伞"引导敏捷实践

Yanel 说敏捷产品

敏捷 敏捷开发

企业经营 "造物" "造人" "造钱"三阶段

Yanel 说敏捷产品

敏捷 敏捷开发

Oracle 将为职场歧视买单,4100 位女员工集体诉讼

神经星星

oracle 互联网巨头 互联网 职场

tcp_tw_recycle 【坑】

孤星可

TCP 服务端

做一个"靠谱"的敏捷教练

Yanel 说敏捷产品

敏捷 敏捷开发

使用JUnit、AssertJ和Mockito编写单元测试和实践TDD (二)为什么要写单元测试

编程道与术

编程 编程语言 TDD 代码审查 单元测试

Product Mastery 作者访谈_Book Review_Ben Linders_InfoQ精选文章