做产品真的难于上天！ — Marty Cagan 70 分钟演讲2万字中文翻译

本文来自Marty Cagan去年11月在台湾的演讲视频，视频来源Youtube视频，已被逐字翻译成了繁体。但仍存在差别，针对一些难以理解的语句，我再次进行了翻译，原文由3PM LAB出品。

因为演讲内容与我产品的引路人对做产品的理念也十分相似，非常推崇，所以细心整理分享，希望对大家也有帮助，开始吧！

全文共19500字，阅读时间50分钟建议先收藏

Marty Cagan是享誉全球的产品大师，【INSPIRED:产品项目管理全书】的作者，担任许多知名公司的产品教练与顾问，也是全球的产品社群中的思想领先者。曾和许多资深的产品经理一起工作(或有私交) ，包含任职于Netflix、Google、Apple、Adobe、BBC的产品经理。他参与了第一家网路产品公司Netscape的创业历程，然后再到eBay担任产品与设计副总(VP of Product and Design) ，之后创办了Silicon Valley Product Group，网罗众多资深产品人，专门为科技公司做产品顾问。

Marty Cagan 在台北演讲

透过ProductTank Taipei社群的筹备，Marty Cagan去年11月难得第一次来台湾演讲。为了向更多朋友分享Marty Cagan的产品心得，社群伙伴们张罗了当天录影录音的支援设备，并释出影片。为了加速内容的传播与扩散，我重看了录影，将演讲内容翻译成中文，并自行编修为每一段加上标题、删除了部分的聊天内容、加上段落补充说明，希望能帮助大家吸收演讲内容。

Marty 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/ 前言

PRODUCT IS HARD — An Open Discussion on Product Management

(影片秒数: 6:29 )

如果你已经做产品一段时间，就会遇到很多困难与挑战；如果没遇到什么困难，那表示你还做得不够久。所以说，做产品遇到困难是很正常的事情，这也让我想跟大家谈谈这些困难。这些跟我一直以来的写作内容有关，跟我每一个合作的团队也都有关，都是很真实很生动的主题，也令我发现「把这些问题摊开来」大家一起聊，会很有帮助。但我也要说，如果你是做产品的新手，这个分享会听起来很有难度，因为我们会谈论比较深的主题。我反而担心你听完以后，你可能会被吓跑而不想做产品了！

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/ 突破敏捷的挫败感？

Frustration with Lean and Agile

(影片秒数: 16:44 )

其中一个很常见的问题，是最近对于「精益」 (Lean) 和「敏捷」 (Agile) 方法的挫败感。这和先前的炒作宣传有关，让很多人不了解精益和敏捷的核心原则。为了避免这个情况，我们先来回顾精益和敏捷的核心原则。

The 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/ 道德上应该推出产品吗？

Not 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/ 辅导产品经理

Coaching Product Managers

(影片秒数: 70:16 )

我可以跟你保证，如果产品经理的主管们真的落实这件事，今天将是很不一样的世界。很可惜的是他们没有做到，因为他们多数人也不知道这是怎么一回事、他们自己从没做过、他们从没看其他人做好过、或他们从没待过这样运作的公司，所以对他们来说这也很困难。但总之，就我的底线来说，每当我遇到不够格的产品经理，通常都是他们没被好好的训练、没被好好的辅导，所以我的挫折感不是针对这位产品经理，是针对他们的主管，因为我们要对主管问责，确保他们带好产品经理。

我时常跟主管们说，你顶多就和你最弱的那个产品经理一样强，所以你真的要好好花时间辅导和提升产品经理们，这是产品领导者最重要的职责，这真的要说的很清楚。当然，还有其他很重要的职责，例如产品策略、愿景、目标，但所有事情都有赖于具备够强的产品经理。产品团队也就只能跟他们的产品经理一样强，如果产品经理不够格，那么你就是浪费优秀的工程师、设计师，而这些人都需要公司负担很大笔的支出。

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

Empowered 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 种不同的功能或重新改版，或任何该做的事情。

「团队要被赋权且被问责」，被赋权的意思是「交由团队来找解决问题的最佳方法」

总之，这就是我们寻找的三件事。如果你的团队有这三件事，我们认为这就是你们想要的境界，所有我认识的世上最好的团队，都很真实的落实这三件事。你会发现，这里面没什么神奇的魔法，你没有什么做不到这三件事的理由。你没有这么做的主要理由通常主要原因是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%）

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