做产品真的难于上天：《启示录》作者Marty Cagan 70 分钟演讲20000字精华翻译

导语：本文来自 Marty Cagan 2019年11月在台湾的演讲视频，视频来源 Youtube 视频，已被逐字翻译成了繁体。但仍存在差别，针对一些难以理解的语句，本文作者再次进行了翻译，原文由 3PM LAB 出品。因为演讲内容与本文作者产品的引路人对做产品的理念十分相似，所以细心整理分享给大家，希望对大家也有帮助！

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（88%）

此外，还有另外一小时的Q&A 问答互动时间，但碍于本文篇幅已经太长，希望下次再写成另一篇文章。如果你也想看Q&A，别忘了拍手鼓励喔！

估计本文阅读时间44分钟，而原本的英文演讲录影长达70分钟。如果你有70分钟的话，去看影片还是非常值得的喔！好，让我们开始吧。

一、前言

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，去年出了第二版，被翻译成数十种语言，这也是我今天在这里的原因，为了新书出版。接下来要分享的议题，都是做产品的常见问题，但他们彼此之间没有先后顺序，不过我敢说这是全世界都常见的问题。

二、突破敏捷的挫败感？

Frustration with Lean and Agile

(影片秒数:16:44)

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

The Core Principles of Agile and Lean

(影片秒数:18:23)

1. 敏捷的核心原则

当我们来看看敏捷和精益，其实就是几个核心原则。

就 敏捷 来说，去除所有外围的东西，只剩两个核心原则：

1）「要频繁的发布」

频繁的意思是「至少每两周发布一次」。

如果你每月或每季才发布一次，就算你自称敏捷，你其实没有获得任何敏捷的好处。好的产品团队甚至每天发布好几次，就是所谓的「持续交付」 (Continuous Delivery)。也不是说大家都要做持续交付，但若你不是每两周发布一次，这会是很大的问题。

2）「团队要被赋权且被问责」

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

举例来说：不是由管理层告知团队「请串接日本当地LN 公司的行动支付」，而是告诉团队「我们眼前看到的问题，是太少日本当地人购买我们的产品，海外转换率实在太低了，请你们解决这个问题」。如果串接了日本当地LN 公司的行动支付，没有解决这个问题，团队就要继续探索其他方案。

很多团队被告知要更加敏捷，但其实管理层一直给团队「待完成的功能清单」（传统意义上的产品路线图Product Roadmap），每月或每季都跟团队说「请做这些功能」，这在任何意义上来说都不是敏捷。

这是敏捷遇到的很大问题，很多团队没被问责或没被赋权。

就 精益 来说，背后也是只有两个核心原则：

1）「我们要快速学习才能创新」

创新源自于我们能够尝试多少点子，因为我们知道大部分的点子都行不通。

2）「我们得要消除浪费」

所谓的浪费就是花了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)

2. 为何「敏捷」还不足够？

可能很多人看过这张图，来自一个很有名的敏捷教练Henrik Kniberg，他长时间在Spotify 担任教练。不过上次我跟他吃晚餐的时候，他说现在到Minecraft 当工程师了，因为太想念当工程师的感觉了！

他想传达的是「瀑布式」和「敏捷」的差异，以做一台车子来比喻。瀑布式流程会花好几个月来确认每一个汽车零件，但敏捷会先做一个「可被测试」的东西。如果这个东西不管用，那就再做一个，看看我们做出来的东西是不是越来越靠近一台真正的车子。

但如果你是一个产品公司，这其实是一个真的很慢也很浪费的过程。

Problem of Conventional Lean and Agile

(影片秒数:23:43)

在一个产品公司里面，我们发现做产品有两个非常不一样的目标与阶段。任何一个科技产品公司，都会遇到这两种挑战。

1）我们要搞清楚「探索该打造的产品」，我称之为「产品探索」(Product Discovery)

这个意思是要找到一个产品方案，符合以下四个条件：

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

2）我们要「交付完整的产品」，也就是「产品交付」(Product Delivery)，是交付工程师有自信的产品，让我们可以真正开始运营这个产品

这个最终产品要符合的条件是：

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

这些都是完整产品应具备的特性。有些人会说第一个是“build the right product”，第二个是“build the product right”。

「探索」和「交付」是非常不一样的目标与挑战，而令很多团队遇到问题的情况，就是公司「要同一群人，在同一时间，处理这两个挑战」。例如，有些公司会叫团队「交付产品时，也要确保这是正确的产品」，但这并不合理，会造成很多浪费。

补充：就我的亲身经验来说，叫团队「交付产品时，也要确保这是正确的产品」，可能造成两种浪费。

第一种是团队小心谨慎的闭门工作了4 个月，发布产品后发现这是错误的产品；第二种是团队超级迅速的发布了好几次产品，其中有些成功了，但也创造了极大的技术成本，打造了难以维护、难以扩张、很低效能的产品，得再花4 个月重构，令团队无法继续迅速发布。

Discovery and Delivery

(影片秒数:25:50)

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

所以，在产品开发团队中，我们会分离这两种行为、这两种风险。

1. 第一种：在探索阶段，我们尝试想出一个valuable, usable, feasible, viable 的产品。
2. 第二种：在交付阶段，我们现在知道要打造什么产品，我们有合理的信心去卖出这个产品、支持我们的市场行为，所以现在可以请工程团队用可靠的方式打造这个产品。

我想要特别说明，这只是一个简单的描述，不是完整的流程。

举例来说：现在已有很多交付阶段的工作流程，其中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)：这个产品对公司没有商业价值，或无法在市场竞争中存活，就是「产品做出来了，顾客也爱用，但是无法赚钱，或拿不到更多预算与资金，或无法赢过竞争者」的状况。

4. 在探索中用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。

三、你想要真正的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% 的公司有真正的产品团队，剩下的都是功能团队，这真的是全世界都很常见的问题。很多人常常以为这些卓越的产品团队都在旧金山，到了南韩或新加坡就很难看到这种团队，事实上不是这样。

首先，在旧金山，也有很多糟糕的团队，我看过很多。这对我来说当然很惊讶，因为过个马路就有另一个卓越的团队、来自卓越的公司；其次，在全世界各个角落都有卓越的产品团队，我遇过的一些顶尖团队其实在北京、班加洛、斯德哥尔摩、柏林，到处都有。

四、怎样让老板们信任Product Team？

Validating Ideas vs. Discovery Solutions

(影片秒数:40:15)

好，来谈下一个问题。虽然这些问题没有按照顺序，但如同我说的，这些是一旦你开始做产品，就开始体会的问题。

现在，其实很容易让产品团队学到各种探索的技巧，快速测试的方法，然后判断一个产品概念是否可行。今天如果一个高管说「我们需要串接PayPal 这个支付方法」，如果你学会了现代产品方法的探索技巧，只要几天的时间，你就可以搞清楚它能否带来效果，而且是在动工以前就搞清楚。

很多团队擅长这些探索与测试的技巧，但仍然发生很不幸的情况。

当高管或利益相关人说「我们需要做这个、做那个」，而产品团队几天后回头说「我们不打算做这些，因为测试后发现这些构想不可行，原因如下…」。问题是，经过几次这样的情况，高管们开始觉得很挫败，因为他们只听到「这些不可行」，他们肯定会纳闷「那你们到底要做什么？」

我试着跟产品团队说，你们的工作不只是告诉大家「为何这些不可行」，你们的工作还必须告诉大家「这些构想更能解决问题、更有机会成功」。

如果今天的课题是「国际交易支付量过低」，产品团队除了告诉大家「串接PayPal 不是个好方法」，还必须告诉大家「PayPal 以外还有哪些方法」可以解决问题，这才是优良产品团队和新手产品团队的差别。优良的产品团队知道，自己还必须提出可行的方案，而且这些方案要更有机会成功。

我们可以在很多公司，见证这种做法的影响力。因为，只要产品团队开始展现这些能力，高管们开始认定这些团队是「问题排除者」 (Problem Solver)，而不是「阻碍者」 (Blocker)。只会验证点子(validating ideas) 的团队是阻碍者，你可以在很多公司看到这样的症状。

五、要花多少时间在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种原型：

1. 实行性原型(Feasibility Prototypes)
2. 用户原型(User Prototypes, Low-Fidelity or High-Fidelity)
3. 即时资料原型(Live-Data Prototypes)
4. 混合原型(Hybrids) 也可在这篇文章，找到简短介绍。

六、满脑子只有单一方案？

Not Considering Alternative Solutions or Approaches

(影片秒数:50:40)

这个问题，和前一个很相关，也是人类的天性，很常见。

当我们被赋予一个问题，例如要改善国际的购买比例，或要降低流失率，或要增加营收，或要找到新市场的第一个参考客户，不管是什么目标、要解决什么问题，我们很自然的会立刻获得一些点子，不管是自己想的或他人提供的。

然后，我们就决定尝试这个点子，立刻开始制作原型。这很好，但问题是，如果这是我们唯一认真考虑的点子，而且这个原型其实最后不成功，那然后呢？该怎么办？

很多团队接着采取的行动，就是继续制作原型(prototyping)、继续20、30、50 次迭代，直到他们用完所有的时间，或直到放弃。

其实，你真正想要理解的是「总是有很多种解决问题的方法」，所以当你在做少量规划的时候，你要确保自己记得「这里有5 种解决问题的方法」，至少要把这件事记在心上。我们认为其中一个方法最好，所以从这里开始，但如果我们没获得成果，我们就要尝试下一个。

举例来说，有个Teresa Torres和我都呼吁的方法，叫做「机会与方案树状图」 (Opportunity Solution Tree)。如果你没听过Teresa，她是个很棒的产品探索教练，是她让这个方法流行起来。这是个快速、轻量的规划技巧，让我们架构自己的工作。

七、道德上应该推出产品吗？

Not Thinking Enough About Ethical Risks

(影片秒数:52:57)

这是一个完全不同的主题，但这在我们产业中也不是个秘密，就是说我们不够用心思考道德上的风险。

前面我提到产品失败的4 大风险：价值(Value)、易用性(Usability) 、实行性(Feasibility)、商业可行性(Viability)。除此之外，我常鼓励团队多考虑第5 个风险，也就是道德风险(Ethical Risk)，就是问自己：我们应该打造这个产品吗？

换句话说，就算用户喜欢我们的产品，这对用户来说真的是件好事吗？

举例来说：用户是个14 岁的青少年，你成功的让他一天花4 小时在手机上，这是件好事吗？如果这是个教育类的科技产品，可能是件好事，但如果这是个游戏，也许不是件好事。

这是我们要留意的事情，而且不只是对用户，也要想这对社会是好的吗？对我们事业是好的吗？这合法吗？有些公司正在尝试的事情，可能在法律的边缘上，这显然不是件好事。

同时，你也要了解，公司在大多数时候都不刻意造成问题，大部分都是无意的。但我想强调的是，产品经理通常是第一群看到潜在问题的人，因为他们就在第一线，观察对顾客与用户的影响。

所以，如果你看到打造中的产品有什么问题，你真的会提出这个议题，向你的主管提出讨论，甚至向你的CEO提出。当然，这是个很敏感的问题，你需要委婉一些的提出，你要确保自己做足功课，真正了解事业如何运作。

总之，很显然，我们这个产业，应该在这方面做得更多。

八、只有无尽的产品优化？

Confusing Optimization with Discovery

(影片秒数:55:09)

这也是个完全不相关的问题，但也真的很常见。

今日，有非常多做产品优化上很棒的工具，例如Optimizely、Google Optimize。说清楚一点，这里讲的「产品优化」 (optimization)，指的是低风险、线上流量、即时资料的AB Testing。

我们基本上是微调各模块，看哪一个成效更好，最常见的就是做在转换漏斗(funnel) 上。我强烈建议每个团队，只要你有正在线上的产品，你获得了真实的流量，你就应该执行这些测试，没有任何不这么做的理由。

但问题是，我看到很多公司，他们只在做这件事情。我可以告诉你，如果这是你唯一做的事情，你正在一个缓慢死亡的道路上，因为这只是「捕捉价值」 (value capture) 的行为，就像提高价格一样。

这是件好事，没什么不对，但如果你只做这件事，你只是逐渐消耗价值而已。我们身为产品人的工作，是要创造更多价值，大余我们捕捉到的价值。产品探索(Product Discovery) 就为了「创造价值」 (value creation)，产品优化(Product Optimization) 只为了放大价值。

所以，不要只做产品优化，要确保你创造更多价值。

九、势不两立的量化与质化？

Qualitative vs. Quantitative Learning

(影片秒数:56:47)

再来一个问题，这个问题某种程度上碰触到了公司文化。

当你刚认识一间公司，很快的你可以稍微看出他们的文化。有些是极度偏重量化驱动的文化，他们的CEO非常相信量化驱动的决策，又有另一些公司的CEO极度相信她或他的直觉，这则是非常质化导向的文化，这些都是很有公司文化的表现。

我总会试着跟两类型的老板们解释，每一个优秀的产品公司，没有例外，都必须擅长两种方法，因为它们回答很不一样的问题。

量化测试告诉我们「实际上发生哪些现象」，但它的限制和主要的问题，就是无法告诉我们为什么。

量化分析能告诉我们「App 中3% 的用户使用此功能」，但它没办法告诉我们「为何另外97% 的用户不使用」，质化测试就在此时派上用场。所以，好的公司都必须擅长两种技巧。

就以Google 来说，这家以数据为典范的公司，拥有如此巨大流量的公司，其实长期以来都在做质化测试。又以Apple 来说，这家以质化洞见为典范的公司，他们的量化分析也做得一样好。

我会这么说：在Google 的标准测试要基于量化方法，但当他们要获得解释时，就会运用质化方法；在Apple 每天都做质化的测试，但当他们要获得数据时，就会运用量化方法。他们两种都用，因为只有单一一种都会造成偏差，很不一样但都有用。

十、产品管理的核心能力？

Product Management Competence

(影片秒数:59:22)

基本上，几乎所有之前提到的议题，都有赖于具备核心能力的产品经理。

在今天的开头，我提到我们产业的一个大问题，就是大部分的产品人— 不管职称是产品负责人(Product Owner) 还是产品经理(Product Manager) — 都欠缺足够的训练，他们还没真正学会如何做好自己的工作。也就是说，他们还不具备足够的核心能力。

这里要清楚解释一下，产品经理(Product Manager) 是工作上的职称，而产品负责人(Product Owner) 是这些人在敏捷团队中扮演的角色。正如同交付经理(Deliver Manager) 是工作上的职称，而敏捷专家(Scrum Master) 是这些人在敏捷团队中扮演的角色。

如果你有一个产品负责人，其本身的工作职称不是产品经理，那是另一个问题，通常你要确保产品经理就是产品负责人。

回到产品经理的核心能力，到底是什么呢？

产品经理的4 大核心能力：

Product Manager Competence

(影片秒数:60:30)

我认为有4 个核心能力：

1. 对用户和顾客的深入研究
2. 对用户操作的深入研究
3. 对商业的深入研究
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. 对大环境的深入研究

第四个，对大环境很深的认识，譬如说，目前的竞争格局、重大趋势。机器学习对我们的产品重要吗？你必须有个看法。

做产品很大的挑战是要一直往未来思考，冰上曲棍球的俚语说「注意冰球即将前往的地方，而不是它走过的地方」，意思就是要看向未来的趋势，而不是今天的情况。

所以，这些就是产品经理被期待的标准，这就是合格的产品经理的标准。如果你是产品经理，你主管的职责就是确保达到标准，否则你不能为团队做任何决定。

十一、辅导产品经理

Coaching Product Managers

(影片秒数:70:16)

我可以跟你保证，如果产品经理的主管们真的落实这件事，今天将是很不一样的世界。很可惜的是他们没有做到，因为他们多数人也不知道这是怎么一回事、他们自己从没做过、他们从没看其他人做好过、或他们从没待过这样运作的公司，所以对他们来说这也很困难。

但总之，就我的底线来说，每当我遇到不够格的产品经理，通常都是他们没被好好的训练、没被好好的辅导，所以我的挫折感不是针对这位产品经理，是针对他们的主管，因为我们要对主管问责，确保他们带好产品经理。

我时常跟主管们说，你顶多就和你最弱的那个产品经理一样强，所以你真的要好好花时间辅导和提升产品经理们，这是产品领导者最重要的职责，这真的要说的很清楚。

当然，还有其他很重要的职责，例如产品策略、愿景、目标，但所有事情都有赖于具备够强的产品经理。产品团队也就只能跟他们的产品经理一样强，如果产品经理不够格，那么你就是浪费优秀的工程师、设计师，而这些人都需要公司负担很大笔的支出。

十二、赢得信任的被授权团队

Empowered Product Teams

(影片秒数:71:58)

最后一个问题，讲完这个就可以进Q&A 时间。

关于「被授权的产品团队」 (Empowered Product Team)，如果你不确定自己的团队是「被授权的产品团队」或「功能团队」 (Feature Team) ？首先呢，如果你有这个困惑，你们很可能就是个功能团队，但我当然很希望你能对此感到肯定。

其实有一组简单的3 个测验，通过了表示这是一家有「被授权的产品团队」的良好公司。

1. 你们有真正的跨专业跨领域团队吗？

这个意思是说，对你们的产品来说，要做好这个产品，需要哪些专业技能？通常来说，是需要产品经理和产品设计师。

当我说产品设计师，我指的是一位精通服务设计(Service Design)、交互设计(Interaction Design)、视觉设计(Visual Design)、甚至通常是受过用户研究(User Research) 训练的人，这是一个典型的「产品与用户体验设计师」 (Product / UX Designer) 的技能组合。

更直白的说，我们真正仰赖的技能是交互设计(Interaction Design)，这比视觉设计(Visual Design) 的要求还更多，当然视觉设计很重要，特别对消费性产品来说，只不过这是很普遍的技能。

2. 真的被授权吗？

具体来说，他们有被赋予要解决的问题吗，而不是被赋予要交付的功能？

要被解决的问题，可能是商业的问题、用户的问题，总之就是一个待解决的问题，而不是要交付的功能，或要完成的项目。而且，团队被允许使用最佳的方式来解决问题吗？这些是备授权的团队的主要概念。

3. 他们被问责和被衡量的方式，是基于解决问题的吗？换句话说，是衡量他们的成果(outcome)，而不是他们的产出(output)？

事实上，大部分的产品团队和产品公司，并不常讨论「上市时间」 (Time to Market)。

但请不要误会我，期限在产品公司是很重要，但问题是要满足期限其实并不困难。如果你已经持续做科技产品一段时间了，你总会找到方法满足任何被要求的期限。我总会砍功能、降低品质，直到我们找到方法在期限前完成，但这就变成一个空洞的胜利。

对产品公司来说，真正重要的不是「上市时间」 (Time to Market)，而是「变现时间」 (Time to Money)。我说变现时间并不每次都指金钱，变现时间的重点是「真正解决问题的时刻」 (time to actually solving the problem)。

如果问题是流失率是毫无永续性的12%，我们知道我们的商业模式将会崩解，除非我们把流失率降低到6%，那我们就是要把问题搞定，再降到6% 之前都不能庆祝。这就是我们说的变现时间，就是那么降到6% 的时刻，这可能表示需要100 种不同的功能或重新改版，或任何该做的事情。

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

总之，这就是我们寻找的三件事。如果你的团队有这三件事，我们认为这就是你们想要的境界，所有我认识的世上最好的团队，都很真实的落实这三件事。你会发现，这里面没什么神奇的魔法，你没有什么做不到这三件事的理由。

你没有这么做的主要理由通常主要原因是CEO 还不信任这个产品团队。现在，为了获得这样的信任，我们要回到有能力展现核心能力的产品经理身上，就是先前我谈的那些能力，就是这些让我们赢得执行长CEO的信任。

内容回顾：

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，微信公众号：一知十，内容来源：3PM LAB，视频来源：Youtube

视频链接：https://www.youtube.com/watch?v=99go9sKp70I&feature=youtu.be&t=389

原文链接：https://mp.weixin.qq.com/s/tyBmZAmNl3QfBsLiVTorvA

本文由 @Adam 授权发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议