本文来自Marty Cagan去年11月在台湾的演讲视频,视频来源Youtube视频,已被逐字翻译成了繁体。但仍存在差别,针对一些难以理解的语句,我再次进行了翻译,原文由3PM LAB出品。
因为演讲内容与我产品的引路人对做产品的理念也十分相似,非常推崇,所以细心整理分享,希望对大家也有帮助,开始吧!
全文共19500字,阅读时间50分钟建议先收藏
做产品真的难于上天! — Marty Cagan 70 分钟演讲2万字中文翻译(建议收藏) - 图1
Marty Cagan是享誉全球的产品大师,【INSPIRED:产品项目管理全书】的作者,担任许多知名公司的产品教练与顾问,也是全球的产品社群中的思想领先者。曾和许多资深的产品经理一起工作(或有私交) ,包含任职于Netflix、Google、Apple、Adobe、BBC的产品经理。他参与了第一家网路产品公司Netscape的创业历程,然后再到eBay担任产品与设计副总(VP of Product and Design) ,之后创办了Silicon Valley Product Group,网罗众多资深产品人,专门为科技公司做产品顾问。
做产品真的难于上天! — Marty Cagan 70 分钟演讲2万字中文翻译(建议收藏) - 图2Marty Cagan 在台北演讲
透过ProductTank Taipei社群的筹备,Marty Cagan去年11月难得第一次来台湾演讲。为了向更多朋友分享Marty Cagan的产品心得,社群伙伴们张罗了当天录影录音的支援设备,并释出影片。为了加速内容的传播与扩散,我重看了录影,将演讲内容翻译成中文,并自行编修为每一段加上标题、删除了部分的聊天内容、加上段落补充说明,希望能帮助大家吸收演讲内容。
做产品真的难于上天! — Marty Cagan 70 分钟演讲2万字中文翻译(建议收藏) - 图3做产品真的难于上天! — Marty Cagan 70 分钟演讲2万字中文翻译(建议收藏) - 图4Marty Cagan 在台北演讲,现场坐满200 位观众
Marty Cagan 长达70 分钟的演讲,有以下内容:(百分比为大概位置便于直接查看)

  • 1/前言(10%)
  • 2/突破敏捷的挫败感?(20%)
  • 3/你想要真正的Product Team?(45%)
  • 4/怎样让老板们信任Product Team?(55%)
  • 5/要花多少时间在Prototyping?(60%)
  • 6/满脑子只有单一方案?(65%)
  • 7/道德上该推出产品吗?(68%)
  • 8/只有无尽的产品优化?(70%)
  • 9/势不两立的量化与质化?(72%)
  • 10/产品管理的核心能力?(75%)
  • 11/辅导产品经理(85%)
  • 12/赢得信任的被授权团队(88%)

此外,还有另外一小时的Q&A 问答互动时间,但碍于本文篇幅已经太长,希望下次再写成另一篇文章。如果你也想看Q&A,别忘了拍手鼓励喔!
估计本文阅读时间44分钟,而原本的英文演讲录影长达70分钟。如果你有70分钟的话,去看影片还是非常值得的喔!😆
好,让我们开始吧。

1/ 前言

做产品真的难于上天! — Marty Cagan 70 分钟演讲2万字中文翻译(建议收藏) - 图5
PRODUCT IS HARD — An Open Discussion on Product Management
(影片秒数: 6:29 )
如果你已经做产品一段时间,就会遇到很多困难与挑战;如果没遇到什么困难,那表示你还做得不够久。所以说,做产品遇到困难是很正常的事情,这也让我想跟大家谈谈这些困难。这些跟我一直以来的写作内容有关,跟我每一个合作的团队也都有关,都是很真实很生动的主题,也令我发现「把这些问题摊开来」大家一起聊,会很有帮助。但我也要说,如果你是做产品的新手,这个分享会听起来很有难度,因为我们会谈论比较深的主题。我反而担心你听完以后,你可能会被吓跑而不想做产品了!
做产品真的难于上天! — Marty Cagan 70 分钟演讲2万字中文翻译(建议收藏) - 图6
About Marty Cagan
(影片秒数: 8:56 )
我对「产品团队」(Product Team) 总是非常感兴趣,因为每一个伟大的产品总有一个伟大的团队,没有厉害的各种角色组合在一起,就没有伟大的产品。但我花特别多时间跟大家谈谈产品管理、产品经理,因为已经有很多人在谈论设计、技术,但几乎没什么人谈产品,我觉得这是一个很大的空缺。
我也不讳言地说,我们产业最大的问题就是「有足够的设计和工程,但常常没有足够的产品经理」。也不是说谁比较聪明,就是没有人好好地训练这些人,没人教他们如何做产品。我非常幸运,可从很多厉害的人身上学习产品,这些人知道怎么学习做产品。这些主管们真的知道自己在谈论什么,也会花心思引导你。我生涯的第一个10 年在HP 担任工程师,在这10 年的职涯中,至少都有一个人明确告诉我如何做得更好,让我以为大家都这么幸运。但真实世界并不是这样,特别对产品经理来说,没什么人告诉他们如何做得更好。
这对「敏捷开发」 (Agile Movement) 来说也是很不幸的事情,特别在我们的同行中,当几乎每个人都在呼吁要变得更敏捷的时候。有些人参加完Certified Scrum Product Owner (CSPO) 训练课程,就觉得自己是产品经理了,但其实这课程并不能教你如何当好产品经理,所以上完课的人还不足以胜任。「产品负责人」 (Product Owner) 的职责只占了「产品经理」 (Product Manager) 约5% 的工作内容。所以说,虽然CSPO 是重要的训练,但这不会教你如何当好PM,这是整个产业的重要问题。
要学好做产品,目前多数人都仰赖一个「会做好产品的人」,跟他一起工作,且这人会花心力引导、训练新人。理论上,只要能跟到这样的人,任何背景的人都可以做好产品经理,不管你是技术、营销、业务、客服。
稍微介绍我自己,我在HP 从做工程师开始,然后加入了Netscape。Netscape 是第一家互联网的公司,也是现在Mozilla 的原生地,有很多厉害的人,也是现代产品经理的原生地。在Netscape 之前,在互联网时代之前,做产品的方式被称为Microsoft Style,当然Microsoft 现在追上网络时代了。Netscape 是第一个要考虑网络使用环境来做产品的公司,所以Microsoft Style 做产品的方式对网络公司并不管用。
所以Netscape是第一个遇到这些问题的公司,因此在Netscape的人开始寻找做现代网络产品的方法,其中包含Ben Horowitz。他写了一本书是【什么才是经营最难的事?】 (The Hard Thing About Hard Things),可说是一本为新创业公司创始人和产品经理所写的书。他最近写了一本新书是What You Do Is Who You Are,其实也是一本关于Product Culture的书,建议大家阅读。
Netscape 所找到的产品方法,很快地随着Netscape 人才换工作的过程,而扩散到其他公司,包含Google、Amazon、Facebook、LinkedIn、Twitter,等等等。
因为Netscape在浏览器的战争中输给了Microsoft,所以很多人才离开并加入了其他公司,而我就加入了eBay担任Head of Product and Design,这是一段很棒的经历。再后来我很希望多跟新创业公司一起工作,所以当时就和5个人一起,针对创业阶段和成长阶段的公司,给予咨询与投资。过程中我也写了一本关于产品的书INSPIRED,去年出了第二版,被翻译成数十种语言,这也是我今天在这里的原因,为了新书出版。
接下来要分享的议题,都是做产品的常见问题,但他们彼此之间没有先后顺序,不过我敢说这是全世界都常见的问题。

2/ 突破敏捷的挫败感?

做产品真的难于上天! — Marty Cagan 70 分钟演讲2万字中文翻译(建议收藏) - 图7Frustration with Lean and Agile
(影片秒数: 16:44 )
其中一个很常见的问题,是最近对于「精益」 (Lean) 和「敏捷」 (Agile) 方法的挫败感。这和先前的炒作宣传有关,让很多人不了解精益和敏捷的核心原则。为了避免这个情况,我们先来回顾精益和敏捷的核心原则。
做产品真的难于上天! — Marty Cagan 70 分钟演讲2万字中文翻译(建议收藏) - 图8The Core Principles of Agile and Lean
(影片秒数: 18:23 )

敏捷的核心原则

当我们来看看敏捷和精益,其实就是几个核心原则。
就敏捷来说,去除所有外围的东西,只剩两个核心原则:
第一是「要频繁的发布」,频繁的意思是「至少每两周发布一次」。如果你每月或每季才发布一次,就算你自称敏捷,你其实没有获得任何敏捷的好处。好的产品团队甚至每天发布好几次,就是所谓的「持续交付」 (Continuous Delivery)。也不是说大家都要做持续交付,但若你不是每两周发布一次,这会是很大的问题。
第二是「团队要被赋权且被问责」,被赋权的意思是「交由团队来找解决问题的最佳方法」。举例来说,不是由管理层告知团队「请串接日本当地LN 公司的行动支付」,而是告诉团队「我们眼前看到的问题,是太少日本当地人购买我们的产品,海外转换率实在太低了,请你们解决这个问题」。如果串接了日本当地LN 公司的行动支付,没有解决这个问题,团队就要继续探索其他方案。
很多团队被告知要更加敏捷,但其实管理层一直给团队「待完成的功能清单」(传统意义上的产品路线图Product Roadmap),每月或每季都跟团队说「请做这些功能」,这在任何意义上来说都不是敏捷。
这是敏捷遇到的很大问题,很多团队没被问责或没被赋权。
就精益来说,背后也是只有两个核心原则:
第一是「我们要快速学习才能创新」,创新源自于我们能够尝试多少点子,因为我们知道大部分的点子都行不通。
第二是「我们得要消除浪费」,所谓的浪费就是花了4 个月才发现「这不是解决问题的好方法」,这就是浪费。在创业阶段我常看见的浪费就是「我们正在做一个MVP 」(Minimum Viable Product 最小可行性产品)。然后我就会问「太好了,那可以让我看看MVP 吗?」结果他们就说「正在做了,还要4 个月」。坦白说,这根本不是MVP,只是个半成品、是不成熟的产品。真正的MVP 只需要4 小时或4 天,不是4 个月。
这些是精益和敏捷的核心原则,千万不能放弃。那么,到底是什么原因,造成精益与敏捷的实施失败呢?
补充:因为Marty Cagan 指的是原型(prototypes),他认为所有的MVP 都应该改成prototypes,如此就只需要4 小时或4 天,后面会说明更多。
Conventional Lean and Agile
(影片秒数: 22:20 )

为何「敏捷」还不足够?

可能很多人看过这张图,来自一个很有名的敏捷教练Henrik Kniberg,他长时间在Spotify 担任教练。不过上次我跟他吃晚餐的时候,他说现在到Minecraft 当工程师了,因为太想念当工程师的感觉了!
他想传达的是「瀑布式」和「敏捷」的差异,以做一台车子来比喻。瀑布式流程会花好几个月来确认每一个汽车零件,但敏捷会先做一个「可被测试」的东西。如果这个东西不管用,那就再做一个,看看我们做出来的东西是不是越来越靠近一台真正的车子。
但如果你是一个产品公司,这其实是一个真的很慢也很浪费的过程。
Problem of Conventional Lean and Agile
(影片秒数: 23:43 )
在一个产品公司里面,我们发现做产品有两个非常不一样的目标与阶段。任何一个科技产品公司,都会遇到这两种挑战。
第一,我们要搞清楚「探索该打造的产品」,我称之为「产品探索」(Product Discovery)。这个意思是要找到一个产品方案,符合以下四个条件:

  • 对用户有价值(valuable):就是顾客会买单
  • 易于使用(usable):意思就是顾客能自己搞懂如何使用
  • 可被打造(feasible):是我们知道如何打造
  • 商业上可行(viable):有市场可行性,包括这个产品,包含宣传、销售、客服,也有收益

第二,我们要「交付完整的产品」,也就是「产品交付」(Product Delivery),是交付工程师有自信的产品,让我们可以真正开始运营这个产品。这个最终产品要符合的条件是:

  • 稳定(reliable)
  • 可扩展(scalable)
  • 高效能(performant)
  • 可维护(maintainable)
  • 支援多国语言且本地化(internationalized and localized)

这些都是完整产品应具备的特性。有些人会说第一个是“build the right product”,第二个是“build the product right”。
「探索」和「交付」是非常不一样的目标与挑战,而令很多团队遇到问题的情况,就是公司「要同一群人,在同一时间,处理这两个挑战」。例如,有些公司会叫团队「交付产品时,也要确保这是正确的产品」,但这并不合理,会造成很多浪费。
补充:就我的亲身经验来说,叫团队「交付产品时,也要确保这是正确的产品」,可能造成两种浪费。第一种是团队小心谨慎的闭门工作了4 个月,发布产品后发现这是错误的产品。第二种是团队超级迅速的发布了好几次产品,其中有些成功了,但也创造了极大的技术成本,打造了难以维护、难以扩张、很低效能的产品,得再花4 个月重构,令团队无法继续迅速发布。
Discovery and Delivery
(影片秒数: 25:50 )

「探索与交付」的循环迭代

所以,在产品开发团队中,我们会分离这两种行为、这两种风险。
第一种,在探索阶段,我们尝试想出一个valuable, usable, feasible, viable 的产品。
第二种,在交付阶段,我们现在知道要打造什么产品,我们有合理的信心去卖出这个产品、支持我们的市场行为,所以现在可以请工程团队用可靠的方式打造这个产品。
我想要特别说明,这只是一个简单的描述,不是完整的流程。举例来说,现在已有很多交付阶段的工作流程,其中2个最有名的流程是Scrum 和Kanban,除了这2个最受欢迎,还有很多其他的交付流程。同样的,现在也有很多探索阶段的工作流程,例如有多达50 种探索阶段的工作流程。
所以说,这只是个概念上的工作模式,想跟大家传达的是:我们要去解决问题,而不只是打造路线图上的功能,我们被赋予的是解决问题的目标(而不是打造功能的目标)。
你可能听过OKR (Objective and Key Results 目标和关键成果) 的管理方法,这个管理方法正是发明于采用这种工作模式的公司,因为这种方法才能建立被授权的工作团队,被赋予达成目标而不是打造功能。当团队被赋予解决问题的目标,团队才能找到解决问题的最佳路径,然后再交付可靠的产品。而产品待办事项清单(Product Backlog),就是探索阶段中产出的有信心的待办事项,等待在交付阶段中被实现。
正如先前描述这个工作模式的一些方法,有人说探索阶段就是build the right thing,然后交付阶段是build the thing right。这里再举更多例子,一个是在Google 的例子,Google 他们会说探索是fake it,而交付是make it,串起来就是“fake it before you make it”。在Facebook 的例子,他们会说“move fast, don’t break things” (在探索阶段要move fast,在交付阶段要don’t break things)。我最喜欢的例子则是AirBnB,他们的工作模式描述非常有意思,但他们刻意如此。他们描述探索阶段是build things that don’t scale,然后他们描述交付阶段是build things that do scale。
这就是大体上的工作模式,不管他们怎么描述、不管有没有精确的文字,我遇到的优良团队都是这么做产品。他们确保在最开始就面对产品失败的4 大风险,在探索阶段知道应该打造什么产品,然后才去交付产品。
补充:Marty Cagan在INSPIRED书中,介绍了产品失败的4大风险,分别是

  • 1/实行性风险(Feasibility Risk):团队明确需求,但手边并没有解决问题的技术,或技术尚未成熟,就是「我们知道要做什么产品,但是做不出来」的状况
  • 2/易用性风险(Usability Risk):顾客想用这个产品,但不知如何使用,或太少人克服使用门槛,就是「产品做出来了,但是好多顾客看不懂、不会用」的状况
  • 3/价值风险(Value Risk):这个产品并没有解决顾客需求,为顾客带来价值,就是「产品做出来了,某些顾客也会用了,但后来都不继续用,因为没有满足需求」的状况
  • 4/商业可行性风险(Business Viability Risk):这个产品对公司没有商业价值,或无法在市场竞争中存活,就是「产品做出来了,顾客也爱用,但是无法赚钱,或拿不到更多预算与资金,或无法赢过竞争者」的状况。

    在探索中用Prototypes,不是MVP!

    在交付阶段,工程师最重要的工作就是写程序、打造真正的产品。在探索阶段,我们只需要「原型」 (prototypes),而不是「产品」 (products)。
    Prototypes in Discovery, Products in Delivery
    (影片秒数: 29:23 )
    在探索阶段只需要原型(prototypes),MVP 其实应该要是原型才对。MVP 这个名称造成很多误会,因为MVP (Minimum Viable Product) 中的P,把应该要是prototypes 的东西误称为products。所以,我总是在探索阶段运用prototypes,以免他人误会。
    (除了名称上的误会,) 如果你花4 个月打造一个MVP,这会是一个很大的问题。花4 个月才打造一个MVP,在探索阶段来说实在是超级慢,但在交付阶段可能又太快速了,所以没有人会对此满意。请记得,在探索阶段打造prototypes,在交付阶段打造products。
    补充:关于Marty Cagan提到的产品探索技巧,可以参考INSPIRED的第4篇,第33到56章,里面介绍了产品探索的原则、产品探索的技术概观、用于探索阶段的4大类产品原型、以及测试4大风险的主要技术。在本次演讲的其他段落,将会多次提到产品原型(Prototypes)和MVP的混淆问题,并解说使用产品原型的重要性。
    请记得,在探索阶段打造prototypes,在交付阶段打造products

    3/ 你想要真正的Product Team?

    当我认识一个产品团队的时候,我会观察3件事,来判断他们做产品的能力怎么样。
    第一件事,就是他们是否在进入交付阶段前,就着手避免让产品失败的4 大风险,这时候通常不需要写任何一行程式码。
    第二件事,就是他们实际上用什么方式解决问题。我期待他们结合了产品经理、设计师、工程师,让彼此交互切磋,然后产生一个最好的方法。他们是用共同协作的模式来解决问题,还是用依序接力的方式来解决问题?在过去瀑布式(Waterfall) 的模式下,产品经理会定义产品需求规格,然后丢给设计师来负责把画面弄好看,然后再把一整包烂摊子丢给工程师。若是在冲刺规划会议(Sprint Planning) 上才第一次跟大家说「开始打造这一切」,虽然有Scrum 里面的冲刺规划会议,且这些人说他们很敏捷(agile),但这根本不是敏捷,这只是瀑布式,因为人们就是在彼此接手各种工作而已。
    第三件事,就是他们被赋予的目标。如果他们被赋予的是发布功能,那只是个「产出」 (output)。如果他们被赋予的是解决问题,那就是个「成果」 (outcome)。我期待看到的是专注在成果(outcome),并以成果来衡量自己的团队。如果有发生这三件事,其他的议题也就不太重要,为此我就能判断这是一个良好的团队。
    Feature Teams vs. Product Teams
    (影片秒数: 32:20 )
    很多公司,也可以说是大多数我在世界各地遇到的公司,大体上都知道做产品的基本知识。他们知道不只需要工程师,还需要产品经理、设计师,大多数都建立了跨专业跨领域的团队。有些公司称这样的编制为「产品团队」,这也是我常用的称呼,而有些则喜欢用Spotify 的方式称呼为Squad。这些都很好,但问题是要建立这样的团队编制并不难,困难的是要能在前面那3 件事上面,落实的够彻底、够深远。很多公司仍然只是制定产品路线图,赋予给团队的任务不是探索与交付,只是设计与开发。
    有些公司甚至还声称有「探索阶段」,但实质上我知道他们并没有这么做,因为我会用这个问题来探测:「你们在探索阶段会测试多少原型?你们在交付阶段又会打造多少?」如果他们说:「喔,上个月我们在探索阶段测试了10 个项目,然后这个月我们打造了10 个项目。」这样我就知道这不是探索,这只是设计,也许附带一点点易用性测试,并不是真的在测试点子。如果他们很认真实施探索阶段,很认真的测试4 大风险,他们必然要抛弃非常多当初的点子,至少要抛弃一半。附带一提,真正优良的产品公司甚至会抛弃80% 到90% 的原始点子。微软最近在哈佛商业评论(Harvard Business Review) 上公开地说,他们大概只有10% 的点子真的可行。
    如果他们没有真正落实探索阶段,尽管这些公司团队称之为「产品团队」 (Product Team) 或Squad,他们实际上仍然只是个「功能团队」 (Feature Team),而且世界上大多数的公司都是这个样子。他们有产品经理(Product Manager)、有设计师和工程师,但他们的产品经理实际上只是个项目经理(Project Manager),这真的很常见。
    我们回顾一下打造产品的4 大风险:价值(Value)、易用性(Usability) 、实行性(Feasibility)、商业可行性(Viability)。你可能知道设计师要负责易用性,当然他们大可以贡献更多。你也知道工程师要负责开发,当然他们也是大可以贡献更多。
    如果你只是一个被交付「路线图」 (Roadmap) 的功能团队(Feature Team),实际上有一个不那么明显的状况正在发生:若某个公司内的高管(executives) 或利益相关人(stakeholders ),只要他们要求把某个项目加到产品路线图中,这个人其实就负责了该项目的价值风险(value risk)。举例来说,如果某个人说「我们必须加上PayPal 这个支付方式」,不管是谁说的,这个人肯定是相信这件事有价值,他才这么说,否则他就不会这样说。同时间,这人其实也负责了这个项目的「商业可行性」 (business viability)。这时候,产品经理实际上要负责的只是项目管理。
    如果这是一个被授权的产品团队(Empowered Product Team),他们被交付的是问题与目标,而不是产品路线图。在真正的产品团队中,产品经理则要负责的是这个解法能够(为用户) 带来价值,在商业上也可行。所以说,当我们要谈论现代的产品经理,我们要在真正的产品团队中谈论,而不是在功能团队中谈论,这才是我们应该谈论的事情。
    我也必须要诚实的说,功能团队中产品经理的工作,远远比产品团队中产品经理的工作简单许多。在产品团队中工作的产品经理,要承受更大的压力、需要具备更多的技能、每天可能要睡得更少。这不是说项目管理不重要,这很重要,但这不是产品经理工作中的核心。
    我也想跟你说,这个问题在很多地方都有出现。譬如说,有很多网络时代前就存在的公司,他们常常说自己需要做互联网转型(Digital Transformation),但他们就只是设置了一个功能团队,然后他们还没搞清楚,为什么这没有带来什么改变。互联网转型需要的是产品团队,但他们还没搞懂。为什么这么说呢?因为这些要做转型的公司,其实就是想和Amazon 这种公司竞争,但产品团队正是Amazon 和Google 采用的模式。很不幸的是,就算功能团队看起来和产品团队很像,他们终究不是(因为没有实质内涵)。
    坦白说我不知道在台湾的情况,就算是在旧金山、纽约、西雅图,也只有10% 到20% 的公司有真正的产品团队,剩下的都是功能团队,这真的是全世界都很常见的问题。很多人常常以为这些卓越的产品团队都在旧金山,到了南韩或新加坡就很难看到这种团队,事实上不是这样。首先,在旧金山,也有很多糟糕的团队,我看过很多。这对我来说当然很惊讶,因为过个马路就有另一个卓越的团队、来自卓越的公司。其次,在全世界各个角落都有卓越的产品团队,我遇过的一些顶尖团队其实在北京、班加洛、斯德哥尔摩、柏林,到处都有。

    4/ 怎样让老板们信任Product Team?

    Validating Ideas vs. Discovery Solutions
    (影片秒数: 40:15 )
    好,来谈下一个问题。虽然这些问题没有按照顺序,但如同我说的,这些是一旦你开始做产品,就开始体会的问题。
    现在,其实很容易让产品团队学到各种探索的技巧,快速测试的方法,然后判断一个产品概念是否可行。今天如果一个高管说「我们需要串接PayPal 这个支付方法」,如果你学会了现代产品方法的探索技巧,只要几天的时间,你就可以搞清楚它能否带来效果,而且是在动工以前就搞清楚。
    很多团队擅长这些探索与测试的技巧,但仍然发生很不幸的情况。当高管或利益相关人说「我们需要做这个、做那个」,而产品团队几天后回头说「我们不打算做这些,因为测试后发现这些构想不可行,原因如下…」。问题是,经过几次这样的情况,高管们开始觉得很挫败,因为他们只听到「这些不可行」,他们肯定会纳闷「那你们到底要做什么?」
    我试着跟产品团队说,你们的工作不只是告诉大家「为何这些不可行」,你们的工作还必须告诉大家「这些构想更能解决问题、更有机会成功」。如果今天的课题是「国际交易支付量过低」,产品团队除了告诉大家「串接PayPal 不是个好方法」,还必须告诉大家「PayPal 以外还有哪些方法」可以解决问题,这才是优良产品团队和新手产品团队的差别。优良的产品团队知道,自己还必须提出可行的方案,而且这些方案要更有机会成功。
    我们可以在很多公司,见证这种做法的影响力。因为,只要产品团队开始展现这些能力,高管们开始认定这些团队是「问题排除者」 (Problem Solver),而不是「阻碍者」 (Blocker)。只会验证点子(validating ideas) 的团队是阻碍者,你可以在很多公司看到这样的症状。

    5/ 要花多少时间在Prototyping?

    Planning vs. Prototyping
    (影片秒数: 42:40 )
    这是一个棘手的问题,让我来告诉你为什么。
    大家都知道,在开工前,花点时间想一想手上的问题,是个不错的做事方法。但问题是这样的,的确我们有很多思考问题、架构问题、规划工作的技巧,但你必须非常注意时间,因为从你接下问题的那一刻,有个码表就被启动了,公司的执行长和高管们心里就开始算时间,他们心里会算「好,又过了一天…又过了一个月…」,就是这个码表在计时。如果你花了大部分的时间做规划,你就没剩多少时间去提出一个可能成功的方案。然后,很快地你的老板们就失去耐性。
    因此,我时常试着告诉团队,你必须控制你的步调,不能做一大堆分析而已。做产品最困难的部分不是规划,最困难的是「提出可能成功的方案」。当我说「可能成功的方案」,意思要能「促使顾客转换」到你的产品,不管先前他们用谁的产品。这听起来简单,做起来非常难。
    很多新手产品人会用「借鉴功能」 (Feature Parity) 的策略,以为只要具备「头号竞争对手提供的所有功能或服务」,就可以拥有很多客户,但经验上这几乎不可能成功。事实上,前面提到的Ben Horowitz 曾这样跟产品团队说:「借鉴功能」不会成功,因为要让顾客愿意转换到我们的新产品,顾客得相信新产品能提供比过去好上10 倍的成果,顾客才会愿意忍受所有转换过程的痛苦与风险。要量化「好上10 倍」,其实也很困难。好奇问一下,现场有多少人用Slack?噢!真惊人,几乎是所有人。你的公司可能从HipChat 转换到Slack,这个过程并不简单。你们愿意转换,因为你们团队认为Slack 是企业通讯软体最好的选项。
    这就是为什么做产品很困难,你的产品必须被认为「有非常明显的优势」,而这不会从「产品规划」 (Product Planning) 中达成。你可以做一堆规划但产品也不怎么样,因为这要从「制作原型」 (prototyping) 来达成。这就是产品探索(Product Discovery),尝试各种点子、验证哪些概念可行,持续在探索中迭代,直到找到有可能成功的方案。
    所以我想强调的是,如果你要解决一个困难的问题,你的确需要花一点时间做规划、做分析,我们有很棒的方法,只要花你几个小时,但你应该要花大部分的时间来做探索(Discovery)、提出一个有可能成功的方案。如果你不这么做,你不会有更多时间。
    有点抱歉的是,我接下来举的例子会用到刻板印象。有很多产品经理来自管理学院、MBAs,有很多因素让MBA 毕业生们喜爱做规划,他们很爱手上的各种表,他们就从中获得很多乐趣。遇到这样的人,恩,我会说「ok 很好,但这不是你的工作!」这也只是简单的部分,困难的部分是当你把手弄脏的时候,你必须坐下来、找设计师和工程师,一起提出可行的方案,任何世界上的规划技巧都不会带你找到可行的方案。
    当然我说的并不完全正确,开个玩笑,我认识很多卓越的产品经理来自MBAs。但因为MBAs 有这样的思维习惯,每当我雇用MBA 背景的产品经理,我必须打破这样的习惯。举例来说,MBA 有些受欢迎的产品技巧,像是用途理论(Jobs To-Be-Done)。别误会我,这是个不错的技巧,但我很少推荐它,因为做完全套流程实在太花时间。如果你真的走完全部流程,你几乎没剩多少时间来提出可行的方案,时间成本昂贵到你无法负担。如果你是三星要推出新手机,如果这是个长期的计划,你可以负担这样昂贵的成本,也许合理。但对在座的所有人,这不合理,因为我们有更轻量、更快、更低成本的规划技巧,只花几个小时,然后立刻开始做探索等实际的工作。
    我想更清楚的指出,如果你是产品经理或产品设计师,你大部分的工作时间都应该花在制作原型(prototyping)。当然,是由产品设计师制作这些原型,然后由产品经理来亲自试用、测试、从中学习,但你们也是一起透过制作原型(prototyping) 来迭代(iterate)。产品经理与设计师运用原型,工程师运用程序代码,这就是我说的如何一起工作。基本上这就是你大部分的工作,你将展示原型给不同类型的用户、顾客、利益关系人,你将会在团队中测试它们,这才是产品经理与设计师的真正工作。这也是为什么我们需要真正的「产品设计师」(Product Designer),今日设计师受训练的方式也正是透过制作原型(prototyping),这对我们很关键。
    再强调一次,所有的prototypes 都是MVP,但我更喜欢用prototypes 来称呼,因为我想强调这不是真正的、完整的产品。除此之外,有4 种不同类型的prototypes,所有优良的产品团队都要善用4 种prototypes,我们实际上也需要4 种prototypes 来面对不同的工作、处理不同的风险。有些专门用来量化测试,有些则用来质化测试,所以优良团队都需要做这些。
    以上,就是为什么我们要平衡planning 与prototyping。
    补充:关于Marty Cagan提到的4种原型,在INSPIRED的第45到49章,分别介绍了原型的原则,以及4种原型

  • 实行性原型(Feasibility Prototypes)

  • 用户原型(User Prototypes, Low-Fidelity or High-Fidelity)
  • 即时资料原型(Live-Data Prototypes)
  • 混合原型(Hybrids) 也可在这篇文章,找到简短介绍。

    6/ 满脑子只有单一方案?

    Not Considering Alternative Solutions or Approaches
    (影片秒数: 50:40 )
    这个问题,和前一个很相关,也是人类的天性,很常见。当我们被赋予一个问题,例如要改善国际的购买比例,或要降低流失率,或要增加营收,或要找到新市场的第一个参考客户,不管是什么目标、要解决什么问题,我们很自然的会立刻获得一些点子,不管是自己想的或他人提供的。然后,我们就决定尝试这个点子,立刻开始制作原型。这很好,但问题是,如果这是我们唯一认真考虑的点子,而且这个原型其实最后不成功,那然后呢?该怎么办?
    很多团队接着采取的行动,就是继续制作原型(prototyping)、继续20、30、50 次迭代,直到他们用完所有的时间,或直到放弃。其实,你真正想要理解的是「总是有很多种解决问题的方法」,所以当你在做少量规划的时候,你要确保自己记得「这里有5 种解决问题的方法」,至少要把这件事记在心上。我们认为其中一个方法最好,所以从这里开始,但如果我们没获得成果,我们就要尝试下一个。
    举例来说,有个Teresa Torres和我都呼吁的方法,叫做「机会与方案树状图」 (Opportunity Solution Tree)。如果你没听过Teresa,她是个很棒的产品探索教练,是她让这个方法流行起来。这是个快速、轻量的规划技巧,让我们架构自己的工作。

    7/ 道德上应该推出产品吗?

    做产品真的难于上天! — Marty Cagan 70 分钟演讲2万字中文翻译(建议收藏) - 图9Not Thinking Enough About Ethical Risks
    (影片秒数: 52:57 )
    这是一个完全不同的主题,但这在我们产业中也不是个秘密,就是说我们不够用心思考道德上的风险。
    前面我提到产品失败的4 大风险:价值(Value)、易用性(Usability) 、实行性(Feasibility)、商业可行性(Viability)。除此之外,我常鼓励团队多考虑第5 个风险,也就是道德风险(Ethical Risk),就是问自己:我们应该打造这个产品吗?
    换句话说,就算用户喜欢我们的产品,这对用户来说真的是件好事吗?举例来说,用户是个14 岁的青少年,你成功的让他一天花4 小时在手机上,这是件好事吗?如果这是个教育类的科技产品,可能是件好事,但如果这是个游戏,也许不是件好事。这是我们要留意的事情,而且不只是对用户,也要想这对社会是好的吗?对我们事业是好的吗?这合法吗?有些公司正在尝试的事情,可能在法律的边缘上,这显然不是件好事。
    同时,你也要了解,公司在大多数时候都不刻意造成问题,大部分都是无意的。但我想强调的是,产品经理通常是第一群看到潜在问题的人,因为他们就在第一线,观察对顾客与用户的影响。所以,如果你看到打造中的产品有什么问题,你真的会提出这个议题,向你的主管提出讨论,甚至向你的CEO提出。当然,这是个很敏感的问题,你需要委婉一些的提出,你要确保自己做足功课,真正了解事业如何运作。总之,很显然,我们这个产业,应该在这方面做得更多。

    8/ 只有无尽的产品优化?

    Confusing Optimization with Discovery
    (影片秒数: 55:09 )
    这也是个完全不相关的问题,但也真的很常见。
    今日,有非常多做产品优化上很棒的工具,例如Optimizely、Google Optimize。说清楚一点,这里讲的「产品优化」 (optimization),指的是低风险、线上流量、即时资料的AB Testing。我们基本上是微调各模块,看哪一个成效更好,最常见的就是做在转换漏斗(funnel) 上。我强烈建议每个团队,只要你有正在线上的产品,你获得了真实的流量,你就应该执行这些测试,没有任何不这么做的理由。
    但问题是,我看到很多公司,他们只在做这件事情。我可以告诉你,如果这是你唯一做的事情,你正在一个缓慢死亡的道路上,因为这只是「捕捉价值」 (value capture) 的行为,就像提高价格一样。这是件好事,没什么不对,但如果你只做这件事,你只是逐渐消耗价值而已。我们身为产品人的工作,是要创造更多价值,大余我们捕捉到的价值。产品探索(Product Discovery) 就为了「创造价值」 (value creation),产品优化(Product Optimization) 只为了放大价值。
    所以,不要只做产品优化,要确保你创造更多价值。

    9/ 势不两立的量化与质化?

    Qualitative vs. Quantitative Learning
    (影片秒数: 56:47 )
    再来一个问题,这个问题某种程度上碰触到了公司文化。当你刚认识一间公司,很快的你可以稍微看出他们的文化。有些是极度偏重量化驱动的文化,他们的CEO非常相信量化驱动的决策,又有另一些公司的CEO极度相信她或他的直觉,这则是非常质化导向的文化,这些都是很有公司文化的表现。
    我总会试着跟两类型的老板们解释,每一个优秀的产品公司,没有例外,都必须擅长两种方法,因为它们回答很不一样的问题。
    量化测试告诉我们「实际上发生哪些现象」,但它的限制和主要的问题,就是无法告诉我们为什么。量化分析能告诉我们「App 中3% 的用户使用此功能」,但它没办法告诉我们「为何另外97% 的用户不使用」,质化测试就在此时派上用场。所以,好的公司都必须擅长两种技巧。
    就以Google 来说,这家以数据为典范的公司,拥有如此巨大流量的公司,其实长期以来都在做质化测试。又以Apple 来说,这家以质化洞见为典范的公司,他们的量化分析也做得一样好。我会这么说:在Google 的标准测试要基于量化方法,但当他们要获得解释时,就会运用质化方法;在Apple 每天都做质化的测试,但当他们要获得数据时,就会运用量化方法。他们两种都用,因为只有单一一种都会造成偏差,很不一样但都有用。

    10/ 产品管理的核心能力?

    Product Management Competence
    (影片秒数: 59:22 )
    基本上,几乎所有之前提到的议题,都有赖于具备核心能力的产品经理。在今天的开头,我提到我们产业的一个大问题,就是大部分的产品人— 不管职称是产品负责人(Product Owner) 还是产品经理(Product Manager) — 都欠缺足够的训练,他们还没真正学会如何做好自己的工作。也就是说,他们还不具备足够的核心能力。
    这里要清楚解释一下,产品经理(Product Manager) 是工作上的职称,而产品负责人(Product Owner) 是这些人在敏捷团队中扮演的角色。正如同交付经理(Deliver Manager) 是工作上的职称,而敏捷专家(Scrum Master) 是这些人在敏捷团队中扮演的角色。如果你有一个产品负责人,其本身的工作职称不是产品经理,那是另一个问题,通常你要确保产品经理就是产品负责人。
    回到产品经理的核心能力,到底是什么呢?

    产品经理的4 大核心能力

    Product Manager Competence
    (影片秒数: 60:30 )
    我认为有4 个核心能力:

  • 对用户和顾客的深入研究

  • 对用户操作的深入研究
  • 对生意/商业模式的深入研究
  • 对产业的深入研究

作为一个产品经理,你的产品团队有赖你提供以上知识。不过我也要说,如果你是功能团队(Feature Team) 的产品经理,那么你并不需要这些,你最需要的是足够的项目管理能力。如果希望在被授权的产品团队担任产品经理,那这些也就是你给自己的约定。和你一起工作的设计师和工程师也都希望你为团队提供这些知识,因为要是你没有,那每一个决策都要提报给CEO或某个高管(executive),或者你要召集很多利益相关人会议(stakeholder meeting)时,在会议中要大家对每一个决定投票,这些就会是恶梦。

(1) 对用户和顾客的深入研究

第一个,对用户和顾客的深入研究,这通常要产品经理花上3 到4 个月来养成。我时常收到产品经理的抱怨,多到我无法告诉你有多频繁,这些人会抱怨CEO 持续地推翻自己的决定。遇到这种状况,我会问这些产品经理:「好,那请告诉我,上次你遇到客户是什么时候?」通常答案是上个月或上一季,然后我接着问:「好,那上次你的CEO遇到客户是什么时候?」通常答案是「几乎每一天」,因为CEO会频繁地拜访客户、或客户会自己找上门。如果是这样,那我就会说:「听着,如果我是你的CEO ,我也不会信任你的决定。为何世上会有CEO,让不了解客户的产品经理(Product Manager) 做决定呢?」期待发生这种事,并不实际。
产品经理最基本的知识,就是要真的非常了解用户或客户。我到现在都还记得,第一个辅导我担任产品经理的人告诉我的事情,那是我刚从工程师转任产品经理的时候。这里补充一下,在我当产品经理的生涯中,除了在eBay,我都负责为工程师制作产品,我很爱打造开发者工具与产品,这很好玩。我自己当过工程师,要为工程师打造产品,我心想「我没问题的,我很了解顾客,他们就和我一样!」那个辅导我的人,他的名字是Mike Bako,他知道我其实根本不了解我们的客户。他跟我说:「听者,在你被允许做任何决定以前,你必须先去拜访30 个客户。」这里指的是HP 的客户,所以他给销售团队打了几通电话,然后跟我说:「你要开始一个3 周的出差,然后拜访15 个美国公司,以及15 个欧洲公司,等你拜访完我们再来聊。」
这在HP 是很常见很正常的出差,但在这3 周的旅行之后,我成为了一个完全不同的人。首先,我发现有上百种「顾客跟我们不一样」的方式,特别是很多HP 客户公司内的工程师,跟我们非常不一样。这些客户可能是银行、保险公司,他们的工程师所受的训练和我们很不一样,有些人甚至不把自己称作工程师,可能只叫自己是分析师或程序员。
当然,Mike 早就知道我和顾客不一样,所以我必须去见见这些人。对我来说,这3周好比上了个了解顾客的速成班,让我真正理解顾客需要什么、遇到什么困难,我们当然有很多产品可以满足他们,但这些需求就是跟我们内部的需求很不一样。除此之外,我也和很多顾客建立的关系,直到今天我们会在LinkedIn 上联系,甚至我到法国时也会碰面。同时,我也和销售团队建立了关系,所以我有了一整个网络,帮助我了解顾客、了解我们销售和行销产品的过程,这里有太多我不知道的事情。
这就是产品经理要具备的第一个能力,你必须被认为是最了解用户或顾客的一位专家。对大部分2C产品来说这可能不会太难,但对企业2B软体来说这需要很多工作,因为B2B产品可以很复杂,要各种不同的用户,包含负责评估采购、负责批审预算的人,产品经理要了解这里面的动态关系。

(2) 对用户操作的深入研究

第二个,要对顾客使用产品所产生的实际操作,有深入的研究。这是今天对比我当年初次做产品时的最大差异,那时候是互联网之前的时代,我们不像今天有这么多的数据。今天的产品经理,每天早上刚开始时,应该要花1 到1.5 小时在数据工具上。至少有3 种看数据的角度与工具,第一种是看用户如何在各种设备上使用产品,第二种是看长期的数据变化,第三种是看销售数据和销售营销活动的表现。
团队有赖产品经理具备这些知识,所以当我们每周做即时数据测试的时候,团队希望知道我们的产品表现如何。这是另一种了解用户的方式,产品经理必须带给团队。

(3) 对生意/商业模式的深入研究

第三个,必须非常了解你产品的商业模式。我必须诚实的说,很多产品经理最不喜欢的工作就是第三个,但这也是4 个核心能力中第二重要的部分,最重要的是了解用户。如果你听过这句话「在被授权的产品团队,一位厉害的产品经理就如同这个产品的CEO 」,这就是在讲第三个核心能力,因为另一个必须如此了解这个模式的工作,就是担任CEO 。
所谓的了解商业模式,就是说你要很了解「哪些营收支付了这个产品的开发与营运?经费从哪来?成本结构是如何?」你还必须了解产品如何被营销、如何被销售、如何进入市场、如何到达顾客面前,你还必须了解过程中的各种限制,例如政府法规、隐私、商业合约等所有的限制,甚至还有我们如何做售后服务、如何跨商业合作。你必须了解这个商业的各种情况,因为你必须确保团队打造的产品能够成功达到顾客面前、为公司创造营收、支付相关的成本,这就是第三个核心能力。

(4) 对大环境的深入研究

第四个,对大环境很深的认识,譬如说,目前的竞争格局、重大趋势。机器学习对我们的产品重要吗?你必须有个看法。做产品很大的挑战是要一直往未来思考,冰上曲棍球的俚语说「注意冰球即将前往的地方,而不是它走过的地方」,意思就是要看向未来的趋势,而不是今天的情况。所以,这些就是产品经理被期待的标准,这就是合格的产品经理的标准。如果你是产品经理,你主管的职责就是确保达到标准,否则你不能为团队做任何决定。

11/ 辅导产品经理

做产品真的难于上天! — Marty Cagan 70 分钟演讲2万字中文翻译(建议收藏) - 图10Coaching Product Managers
(影片秒数: 70:16 )
我可以跟你保证,如果产品经理的主管们真的落实这件事,今天将是很不一样的世界。很可惜的是他们没有做到,因为他们多数人也不知道这是怎么一回事、他们自己从没做过、他们从没看其他人做好过、或他们从没待过这样运作的公司,所以对他们来说这也很困难。但总之,就我的底线来说,每当我遇到不够格的产品经理,通常都是他们没被好好的训练、没被好好的辅导,所以我的挫折感不是针对这位产品经理,是针对他们的主管,因为我们要对主管问责,确保他们带好产品经理。
我时常跟主管们说,你顶多就和你最弱的那个产品经理一样强,所以你真的要好好花时间辅导和提升产品经理们,这是产品领导者最重要的职责,这真的要说的很清楚。当然,还有其他很重要的职责,例如产品策略、愿景、目标,但所有事情都有赖于具备够强的产品经理。产品团队也就只能跟他们的产品经理一样强,如果产品经理不够格,那么你就是浪费优秀的工程师、设计师,而这些人都需要公司负担很大笔的支出。

12/ 赢得信任的被授权团队

做产品真的难于上天! — Marty Cagan 70 分钟演讲2万字中文翻译(建议收藏) - 图11Empowered Product Teams
(影片秒数: 71:58 )
最后一个问题,讲完这个就可以进Q&A 时间。关于「被授权的产品团队」 (Empowered Product Team),如果你不确定自己的团队是「被授权的产品团队」或「功能团队」 (Feature Team) ?首先呢,如果你有这个困惑,你们很可能就是个功能团队,但我当然很希望你能对此感到肯定。
其实有一组简单的3 个测验,通过了表示这是一家有「被授权的产品团队」的良好公司。
第一个,你们有真正的跨专业跨领域团队吗?这个意思是说,对你们的产品来说,要做好这个产品,需要哪些专业技能?通常来说,是需要产品经理和产品设计师。当我说产品设计师,我指的是一位精通服务设计(Service Design)、交互设计(Interaction Design)、视觉设计(Visual Design)、甚至通常是受过用户研究(User Research) 训练的人,这是一个典型的「产品与用户体验设计师」 (Product / UX Designer) 的技能组合。更直白的说,我们真正仰赖的技能是交互设计(Interaction Design),这比视觉设计(Visual Design) 的要求还更多,当然视觉设计很重要,特别对消费性产品来说,只不过这是很普遍的技能。
第二个,真的被授权吗?具体来说,他们有被赋予要解决的问题吗,而不是被赋予要交付的功能?要被解决的问题,可能是商业的问题、用户的问题,总之就是一个待解决的问题,而不是要交付的功能,或要完成的项目。而且,团队被允许使用最佳的方式来解决问题吗?这些是备授权的团队的主要概念。
第三个,他们被问责和被衡量的方式,是基于解决问题的吗?换句话说,是衡量他们的成果(outcome),而不是他们的产出(output)?
事实上,大部分的产品团队和产品公司,并不常讨论「上市时间」 (Time to Market)。但请不要误会我,期限在产品公司是很重要,但问题是要满足期限其实并不困难。如果你已经持续做科技产品一段时间了,你总会找到方法满足任何被要求的期限。我总会砍功能、降低品质,直到我们找到方法在期限前完成,但这就变成一个空洞的胜利。
对产品公司来说,真正重要的不是「上市时间」 (Time to Market),而是「变现时间」 (Time to Money)。我说变现时间并不每次都指金钱,变现时间的重点是「真正解决问题的时刻」 (time to actually solving the problem)。如果问题是流失率是毫无永续性的12%,我们知道我们的商业模式将会崩解,除非我们把流失率降低到6%,那我们就是要把问题搞定,再降到6% 之前都不能庆祝。这就是我们说的变现时间,就是那么降到6% 的时刻,这可能表示需要100 种不同的功能或重新改版,或任何该做的事情。
做产品真的难于上天! — Marty Cagan 70 分钟演讲2万字中文翻译(建议收藏) - 图12「团队要被赋权且被问责」,被赋权的意思是「交由团队来找解决问题的最佳方法」
总之,这就是我们寻找的三件事。如果你的团队有这三件事,我们认为这就是你们想要的境界,所有我认识的世上最好的团队,都很真实的落实这三件事。你会发现,这里面没什么神奇的魔法,你没有什么做不到这三件事的理由。你没有这么做的主要理由通常主要原因是CEO 还不信任这个产品团队。现在,为了获得这样的信任,我们要回到有能力展现核心能力的产品经理身上,就是先前我谈的那些能力,就是这些让我们赢得执行长CEO的信任。
END内容回顾**

  • 1/前言(10%)
  • 2/突破敏捷的挫败感?(20%)
  • 3/你想要真正的Product Team?(45%)
  • 4/怎样让老板们信任Product Team?(55%)
  • 5/要花多少时间在Prototyping?(60%)
  • 6/满脑子只有单一方案?(65%)
  • 7/道德上该推出产品吗?(68%)
  • 8/只有无尽的产品优化?(70%)
  • 9/势不两立的量化与质化?(72%)
  • 10/产品管理的核心能力?(75%)
  • 11/辅导产品经理(85%)
  • 12/赢得信任的被授权团队88(88%)

如果你已经看到了这里,那我真的很佩服你,想必你也一定有了一些收获,消耗一下变成自己的思考,然后一起讨论下吧?

公众号:一知十
内容编辑/翻译:Adam
视频来源:Youtube https://www.youtube.com/watch?v=99go9sKp70I&feature=youtu.be&t=389
内容来源:3PM LAB