产品的本质 | Marty Cagan，Silicon Valley Product Group
The nature of product | Marty Cagan, Silicon Valley Product Group
嘉宾：Marty Cagan
全文文稿 · 按对话顺序保留完整内容，深入理解上下文。
本篇目录1 章节
§01原文文稿 · 00:00–59:28§01原文文稿 · 00:00–59:28
人们买的不是问题，而是你的解决方案。显然，如果它解决的不是他们在意的事，他们不会买；但有很多产品解决的都是他们在意的事。真正的问题是：你解决得是否比其他所有人都好，好到他们愿意买你的？这才是需要花时间的地方。这更像是我给团队的辅导。我会告诉他们：“听着，要小心。如果需要在问题上花一点时间，可以，但别花太多，因为你得尽可能多地省出时间，去想出那个能赢的解决方案。”
关于 Marty Cagan，还有什么是别人没说过的呢？他是《Empowered》和《Inspired》的作者，这两本书是产品管理领域阅读最广、影响最大的书籍中的两本。他还是 Silicon Valley Product Group 的创始人，该机构由他在二十多年前创立。比起其他任何人，他一直持续不断地为想要提升产品能力的产品经理和产品负责人提供最出色、最可落地的建议。在投身教学之前，他曾是 Netscape 的产品副总裁，也是 eBay 的高级副总裁。能请到 Marty 做客这档播客，我深感荣幸。他在产品经理圈子里绝对是传奇人物，我迫不及待想让你们听听这一期。下面，有请 Marty Cagan。
本期节目由 Whimsical 赞助播出。当我在 Twitter 上问产品经理和设计师他们最常用什么软件时，Whimsical 总是被提到最多的产品之一，而且它的用户非常狂热。Whimsical 为协作式思考而生，把可视化文本和数据画布结合成一种流畅的媒介。分布式团队用 Whimsical 做工作坊、白板、线框图、用户流程，甚至功能规格说明。它还包含数千个内置图标和丰富的模板库。看看为什么领先公司的产品团队都称 Whimsical 是游戏规则改变者。访问 whimsical.com/lenny，注册时会把我自己的模板添加到你的账户中。网址是 whimsical.com/lenny。
嗨，Ashley，你是 Flatfile 的市场负责人。你估计有多少 B2B SaaS 公司需要从客户那里导入 CSV 文件？
至少 40%。
那其中有多少家会把这件事搞砸？搞砸之后会发生什么？
嗯，根据我们的数据，大约三分之一的人在入门引导（onboarding）阶段只要有一次糟糕的体验，就会考虑换到另一家公司。所以如果你的 CSV 导入器工作不正常——考虑到客户文件里满是意想不到的数据和格式，这种情况非常常见——他们就会离开。
听到这个我一点也不意外。我一直看到，改进入门引导是提升注册转化率和长期留存率杠杆最高的机会之一。让人们更快、更可靠地到达“顿悟时刻”（aha moment），实在太重要了。
完全同意。看到我们的客户，比如 Square、Spotify 和 Zuora，能够在 Flatfile 之上发展他们的业务，真的很了不起。这是因为 Wallace data onboarding（原文如此，疑为 Flatfile 的数据入门引导）就像一种催化剂，让他们和他们的客户更快到达想去的地方。
如果你想了解更多或开始使用，请访问 flatfile.com/lenny 了解 Flatfile。Marty Cagan，欢迎来到播客。
谢谢邀请我，Lenny。
这绝对是我的荣幸。我就直接切入正题了。我注意到你对产品的思考变得越来越有哲学意味，尤其是在你最近的许多文章里，包括最近一篇叫作《产品的本质》（the Nature of Product）的文章，你在其中谈到了人们对产品管理的许多核心误解。本质上是说，人们并不真正理解，在产品文化强的公司做产品，与在你所说的产品文化不那么强的公司做产品，差别有多大。你的描述方式是：这就像试图向别人解释大峡谷是什么，却只是给他们看大峡谷的照片。所以我很想深入聊聊这个话题，听听你对自己在产品方面这种新的哲学倾向的看法，以及你在产品和产品管理领域一直看到的这些误解。
好的，当然。我的意思是，这确实令人沮丧，这也是促使我——我偶尔会经历这样的哲学浪潮，会更仔细地去审视……令人沮丧的是，我真的以为到 2022 年，好公司和其余公司之间不会还有这么大的鸿沟。有如此强烈的激励，光是盈利动机就足够了。为什么不是更多的公司想像最优秀的公司那样工作？我觉得这太令人困惑了。没错，确实如此，还有一件有趣的事，我敢说你也能体会，Lenny，我两边都有朋友。我两边都有朋友，在不太好的公司工作的那些人，说实话，很多人并不相信我对好公司工作方式的描述。他们会说：“没人这么干。”而当我把这些告诉在好公司的朋友时，他们往往也会说：“也没人那样干，他们为什么要那样做？他们疯了吗？谁会想那样工作？”所以这让我觉得难以置信。
总之，当我试图向一个从没真正在真正的产品团队工作过的人解释那是什么样子时，你会发现有时候感觉就像我在对他们说另一种语言。我意识到，他们对这套东西根深蒂固……我甚至不想说它是老派，因为问题不在于它老，而在于它已经过时了。他们认为产品经理要以某种形式做需求——PRD、用户故事，随便你怎么叫。然后设计师的工作基本上就是把它做漂亮，也许再画一些线框图。然后这一整摊东西被带到冲刺计划会（sprint planning）上交给工程师，你说：“这就是你们接下来要做的。”
这种做法太根深蒂固了。还有季度路线图也随之而来，同样根深蒂固。他们认为工作就是：“嘿，我们的工作就是不停地产出功能。”他们中很多人甚至不会多想一下，因为这是他们唯一知道的东西。当然，我会试图向他们解释：“你知道，在你们任何一个最喜欢的产品里，真的都不是这样运作的。”你们任何一个最喜欢的产品或公司都不是这样。那是一种非常不同的动物。你们之间是真正的平等伙伴。开发者不是在那里仅仅实现你那些愚蠢的点子，他们是在那里帮助你想出一个很棒的解决方案。设计师也不只是让你的东西看起来漂亮，他们是在那里帮助创造出色的体验。顺便说一句，作为产品经理，你的工作也非常不同。你需要给这个团队带来团队在设计和工程上不具备的技能，因为只有这样，大家合在一起才能真正做成需要做的事。所以当我这样描述时，两者差别相当大。我们谈论的不是细微的差别，而是相当巨大的差别。我真的相信，在这个时间点上，功能团队（feature team）和真正的产品团队不应该使用同一个 string（原文如此，疑指 title/头衔）“产品经理”。这个工作的差别如此之大，把两者都称为产品经理会产生误导。
对正在听的人来说，他们可能会想：“嗯，我到底在哪一种团队工作？我自己都不确定。”有哪些——也许三到五个——迹象，可以表明你在一家功能工厂（feature factory），或者你所说的功能团队里工作？
嗯，幸运的是，这不难判断。我是说，如果你两种都见过，就不难判断。在功能团队里，基本上你拿到的是一份典型的路线图。几乎所有人——尽管我希望情况不是这样——几乎所有人拿到的都是同一种东西，那就是一份按优先级排序的功能和项目清单。也就是一些利益相关方聚在一起，通常是每季度一次，他们说：“听着，要运营我们这部分业务，我们需要这些功能。这并不复杂。我们需要这些功能。”然后他们就把这些功能交给你。现在要明白，这些功能是可能的解决方案。所以你被要求做一点设计、大量编码，然后做一些 QA，再部署上线。更概括地说，你在那里是为业务服务的。现在把它和真正的产品团队对比一下。在真正的产品团队里，首先，他们拿到的不是一份按优先级排序的功能路线图，而是要解决的问题。
所以这可能是一个客户问题，也可能是一个公司问题，都可以，但它们是要解决的问题。然后团队会获得所需的技能，以便能为这个问题想出最佳解决方案。我的意思是，这就是 Netflix 的原则：把决策下放给真正掌握知识、最有能力解决这个问题的人。工程师每天都在和赋能技术（enabling technology）打交道，产品团队每周都在和用户及客户打交道。所以当然，这些人离问题最近，也是你想把决策下放给的人。另一个区别是，当你被给予一个要解决的问题时，那不是产出（output），而是成果（outcome），所以你要么解决了它，要么没解决。你可能知道，如今大多数优秀的团队都在做持续部署、持续交付。
他们一天发布很多次。再多发布一次又有谁在乎？如果它没有真正解决问题，就没什么可炫耀的，也没什么可庆祝的。所以在真正的产品团队里，你是在真正解决了问题、达成了那些结果时才庆祝。这就是为什么我们说产品团队关注的是成果，而不是产出。所以功能团队和产品团队，表面上看都是小队（squad），但它们非常非常不同。现在值得对产品经理这个角色再深入展开一下，因为从根本上说，设计师和工程师的角色并没有太大不同。我们要求设计师和工程师更进一步，同样关心你构建什么与你如何构建，但他们用的是你在大学或其他地方学到的技能。另一方面，在功能团队里，产品经理基本上是在那里“赶猫”（herd the cats）的，这并不简单，但他们需要把事情组织起来。
他们需要把东西收集起来。这些需求，你需要在你使用的任何工具里把它们记录下来，比如 Jira 之类，然后你需要把它带到冲刺计划会上。你需要确保它能做出来。这就是赶猫。这本质上是一个项目管理角色。但在一个被赋能的产品团队里，你要试图想出一个能解决你所分配到的问题的解决方案，这要难得多，因为这意味着我们必须发现一个有价值（valuable）、可用（usable）、可行（feasible）、可持续（viable）的解决方案。工程师无疑负责“可行”，设计师无疑负责“可用”，而“有价值”和“可持续”是最难做到的两件事，那是产品经理的责任，而这是相当重的担子。这很难。这需要技能，需要知识。这就是为什么我们说，要在真正的产品团队里当产品经理，你必须下功夫做足功课。
你谈到了这个想法：对于没有体验过的人来说，这种工作方式听起来像是梦幻之地。我在 Twitter 上问大家该问你什么问题，这个问题出现了好几次，就是人们会说：“我读过你的东西。”然后我会想：“这真的存在于任何地方吗？我从来没有体验过这种工作方式。”只是想让大家觉得这是可能的。第一，有没有一些你喜欢拿来描述这种工作方式的好例子公司？第二，再确认一下，这是可能的，外面确实有公司是这样做的，对吗？
哦，我是说，这很有意思。首先，我应该在一开始就说这一点。每当我和团队合作时，我总会设法记得在某个地方说这句话。我谈到的任何东西，老实说要非常明确地讲，我在《Inspired》里写到的任何东西、在《Empowered》里写到的任何东西，都不是我们发明的。我们所做的只是分享我们在最好的团队中看到的实践。所以判断的经验法则很简单：如果有好几个最好的团队在用，我们就会说：“好，那我们开始推荐它吧。看看它在那里效果如何。如果效果好，我们就开始倡导它。”反过来，如果有人说：“哦，你听说过这个流程吗？或者你听说过这个工具吗？”而那些公司里没有一家在用它，我就会说：“别来烦我。”它要么是江湖骗术，要么还没有被证明有效。
这些东西我们一样都没有发明，我们只是努力把它们分享出来。有一点点——我是说，我们做的事情是，努力把公司文化与技术手段区分开来，因为 Amazon 有他们偏爱的文化做法，Google 有，Netflix 有，Stripe 也有。别误会，我喜欢这些文化，但它们是不同的文化，非常不同的文化。所以我们想做的就是把二者拆开，分享技术手段本身。但你可以读书。Amazon 的《Working Backwards》描述的就是我一直在讲的东西，只不过用的是 Amazon 的术语。你可以读 Netflix 的《No Rules Rules》，看看他们是怎么做的。你可以读《Build》，它讲了 Apple 是怎么做的。这些都很棒，但你得多花点力气才能看出其中共同的脉络。这正是我们想做的。
不过所有这些公司——Stripe，很棒的 Shopify，看看 Slack 做到的成就。甚至要给 Spotify 点赞，他们多年来一直能够与 Apple 和 Amazon 抗衡。当然，我说的都是知名品牌。还有无数没人听说过的小公司，但希望如果他们继续做得好，总有一天人们会听说他们。所以不，这不是只有几家公司。如今世界各地都有很棒的公司，但确实，它们只占公司总数的一小部分。这正是真正让我困扰的地方。
你有没有概念，这个比例大概是多少？占百分之多少？
其实我就这个话题聊过，你也认识 Shreyas Doshi，对吧？
他上过这档播客。
他是我最喜欢的思想家之一。没错，他是产品领域我最喜欢的思想家之一。他真的非常出色。因为他也是那种人，起初他问我：“人们真的像你写的那样工作吗？真的，他们真有那么无知吗？”是的，他们真的是这样。那是他们所知道的一切。当然，更大的问题是，他们为什么真的会那样工作？我们会谈到这个。不过总之，我不知道。让这件事变得困难的一点是，世界上写软件的人很多。首先，你可以把他们分成两半：一半是做商业产品的，也就是打算卖给很多人的；另一半只是做定制解决方案的。很长一段时间里——我不知道现在是否仍然准确，但很长一段时间里——我读到的行业分析师说，全世界做定制解决方案的人数其实要多得多。而这些人都算不上真正的产品人。所以很难说。有人知道到底有多少公司真正在做商业产品吗？然后又有多大比例？我纯属凭经验的猜测是，也许 10% 到 15% 是优秀的产品公司，大概这样。
太好了。我喜欢有个数字。好吧。
谁知道呢？可能差上好几个数量级。
听起来合理。我想在接下来的部分对话中用一个视角，就是你在一些文章里一直推荐的那部纪录片，我最近看了，很想聊聊它。这部纪录片叫《The Lost Interview》，里面采访了 Steve Jobs，时间是在他被 Apple 开除之后、回来执掌 Apple 之前。你从中提炼出了大量洞见，我也很喜欢听、也很喜欢思考，我很期待和你一起聊聊。所以第一个问题是，这次采访最初给你留下的、总体上最强烈的印象是什么？
嗯。我喜欢它的原因之一是，他很少谈论产品本身。他喜欢谈论他的产品。他喜欢谈 iPhone 为什么很棒、iPod 为什么很棒、Mac 为什么很棒，但谈构建产品的本质，他并不常这样。我的意思是，那是他的秘方，如果你愿意这么说的话，他对此有非常出色的洞见。所以能找到这段一个多小时的采访，他在其中非常有思想，他有机会好好想想哪些事做得好、哪些出了问题。回答你的问题：在我自己的文章里，其实也在最近的书《Empowered》里，我分享了我的理论，解释为什么最优秀的公司和其余公司之间有如此巨大的差距。换句话说，为什么不是每家公司都努力像最优秀的公司那样工作？
我是说，为什么不呢？看看他们获得的估值。光为了钱，你都会觉得它们会这么做。我最好的理论是，我看到的最大原因是，他们从来没在那样的公司工作过，所以不知道那是什么样子。他们不知道好是什么样子。然后我看了这段视频，你知道，它最近又浮出水面了。而 Steve Jobs 分享了他在 1995 年的理论，天哪。我边听边想：“天哪，他的理论肯定比我的理论更好。”而且它至今仍然更贴切。他谈到了产品发现（product discovery），谈到了流程型人员（process people），谈到了所有这些真正相关的话题。但给我印象最深的，是他对为什么有这么多糟糕的产品公司的理论。他的理论是——顺便说一句，我希望每个听你播客的人都去看一看，在 Amazon Prime 上租一下只要 4 美元。
你绝对应该看一看。完整地看。所以别让我的概括打消你的兴趣。它值得一看。总之，他分享了他认为一般会发生的事：随着公司变大——显然，如果一家公司在某个时期没有一款像样的产品，它是不会变大的。但他谈的和我谈的是同一件事：为什么这么多公司失去了那股劲头？他的论点是，随着公司变大，产品在历史上变得不那么重要了。公司里会被推崇的人是营销人员、销售人员、财务人员。如果一家公司停止创新，这些就成了增长的引擎。销售、营销，或者财务——不是增长，而是削减成本。他的论点是，这种情况会随着时间发生。很快，这些人就成了你的领导者。他们是被提拔上来的人。那接下来会发生什么？优秀的产品人不想再待在那里了，他们离开，去了重视产品的公司。我认为这是我听过的比其他任何解释都更好的解释。而且它极具先见之明，因为他说这番话的时候，这种情况在许多其他公司身上还没有发生，但它至今仍一直在发生。我不久前写过一篇文章，叫《Devolving from Good to Bad》，观察了其中的一些现象，但他真正抓住了要害。老实说，我认为他说得一点没错。
我喜欢他把这些描述为公司的疾病。他们拥有足够的市场份额。事情就是这样发生的。增长在发生。他们在赢。他们不需要继续创新，于是这就变成了这种疾病。这是一种非常有力的思考方式，你要努力防止这种疾病接管你的文化、产品和公司。我认为这里有市场份额的因素。而且一般来说，这会发生在业绩不错的公司身上。事情进展顺利，那就别搞砸任何东西。为什么要推出有风险的新东西，为什么不继续卖这个似乎人人都想要的东西？
实际上，Lenny，我认为这值得强调，因为这是我经常看到的一种反模式，尤其是在创始人离开之后。你知道，在产品领域我们常常会说，有价值创造活动，也有价值捕获活动。发现（discovery）全是关于价值创造，优化则全是关于价值捕获。两者都很好，绝对如此。你应该两者都做，但创始人离开之后，很多公司都害怕了。他们真的是在害怕。产品团队害怕，高管也害怕。他们害怕的原因是，他们不知道什么是本质的、什么是附带的。他们害怕伤到那个驱动业务的东西。
当然，创始人是了解那个东西的，因为他们从一开始就在。他们拥有所有这些组织内部的知识。他们知道什么重要、什么不重要，而且他们有那份信心。有时我们会谈到创始人的道德权威。他们知道，而且深刻地知道什么是本质的、什么不是。但当他们离开后，我们经常看到公司变得害怕。我能看得出来，因为他们所做的只是些小小的、低风险的 Optimizely A/B 测试。他们只是在做这些小小的 A/B 测试。他们只是在调整工作流、主流程、增长、留存。他们只是在调整。再说一次，这没有什么错，但这些事情不会带来创新。它们不会给公司带来重大改进。所以一旦他们不再做真正的发现，在我看来，这就是终结的开始。
有意思的是，如果在顶层运营公司、有想法的人对该往哪走没有把握，你会觉得他们应该赋能一线的团队去想清楚该做什么。相反，他们却变成了这种自上而下的功能团队，对他们说：“我们就做这个吧。我不知道，但这大概是最好的主意，而且我大概比你们懂得多。”但其实他们并不懂。
事实上，这正是 Steve Jobs 在那次采访中强调的疾病之一。他称之为利益相关方、管理者的疾病，他们认为一个想法占了 90% 的工作。他就是这样点出来的。他说，他们不明白。想法是次要的。想法只是个开始。我想他说的是，“从想法到产品的整个工艺（craftsmanship）”。这就是我们所说的产品发现（product discovery）。他描述的是产品发现，以及每次迭代中事情如何不断变化。你要做权衡，开始时是一个样子，结束时是另一个样子。当然，他指出的是，这些高管大多不了解、也不理解，这才是你得到一款出色产品的真正方式。不是一群高管走进一个房间，列出他们按优先级排序的功能清单，然后直接告诉团队去做。
事实上，我们现在知道，这些东西中只有大约 20% 会产生任何正向回报。所以你会觉得外面有足够的证据让他们意识到这是致命的，但我认为这里有很多傲慢，因为每个高管都认为自己比其他人聪明，所以他们的想法才是更好的。但事实真的不是这样。我的意思是，优秀的产品团队和优秀的产品公司知道，一个想法只是眼中的一点火花，只是起点。真正重要的是做出产品，而那是实打实的工作。
这触及了一个我一定想问的问题，那就是有时候领导者会觉得：“我就是知道该做什么。为什么我们要经历这一整套流程？就做这个吧。我非常有信心这就是答案。”而你刚才说的正是其中一个很大的原因，就是很多时候你并不知道，却以为自己知道。而很多神奇之处就发生在构建、迭代、学习、与客户交谈的过程中。你是这样看的吗？
完全是。而且这里有一个危险区，很多产品团队会无意中掉进去：当我们谈论发现（discovery）时，严格来说有两种发现。一种是发现你应该聚焦的、要解决的问题；另一种是发现你将要交付的、人们愿意买单的解决方案。很多产品团队里，创始人知道这个问题。事实上，公司里大部分人都知道这个问题。但很多时候，产品团队认为他们应该——即使他们对问题已经有信心——也要花上若干周或几个月做问题验证，确保人们真的有这个问题，有这个问题的人足够多，并且理解这个问题。再说一次，在没有约束的理想世界里，这并不真是问题。但在现实世界里，时钟在滴答作响。
如果你花了比如两周，只是在验证创始人早就知道的同一件事，那位创始人此时大概非常沮丧，因为你甚至还没开始做解决方案。而人们买的不是问题，他们买的是你的解决方案。显然，如果它解决的不是他们在意的事，他们不会买；但有很多产品解决的都是他们在意的事。真正的问题是：你解决得是否比其他所有人都好，好到他们愿意买你的？这才是需要花时间的地方。这更像是我给团队的辅导。我会告诉他们：“听着，要小心。如果需要在问题上花一点时间，可以，但别花太多，因为你得尽可能多地省出时间，去想出那个能赢的解决方案。”既然我们在谈 Steve Jobs，值得指出的是，当他描述你脑子里要记住的那 5,000 件事时，那就是解决方案发现（solution discovery）。这很重要。产品团队需要知道，那里才是他们成功或失败的地方。
我知道这一点对你来说非常重要：产品经理被教导说他们的工作是弄清楚“做什么”（what）而不是“怎么做”（how）。为了强化这一点，你非常强烈地认为：“不，这完全错了。产品经理对‘怎么做’也负有很大责任。”
这个说法总是让我发笑，因为我会想：“你知道如果这是我唯一的工作，我每周需要工作多少小时吗？”大概我每周花 15 分钟敷衍一下就行了，“我做完了。我完成我的部分了。”这太荒谬了。再说一次，你只需要更深入地想一想。当你试图想出一个成功的解决方案时，我是说，外面有不同的分类法。我用的那一种是，它必须是有价值的、可用的、可行的、可持续的，大多数产品都适用。这些是风险，你可以给它们取不同的名字，但它们就是风险。产品经理负责确保解决方案是有价值的和可持续的，而这很难。这很难。这需要实打实的工作。而这是“怎么做”的一部分。这也是“怎么做”中相当不可或缺的一部分。
当然，你不会告诉工程师怎么写代码。你不会告诉设计师怎么做设计，但你确实承担很大一部分。我们所有人一起拿出那个“怎么做”。所以“怎么做”就是整个东西如何运作。显然，如何变现、隐私问题、安全问题、如何进入市场，这些都是“怎么做”，但它们是产品管理的职责。它们并不比设计师、工程师所做的更重要或更不重要，因为这四种风险中，只要有任何一种失败，你就得到一个失败的产品。所以这些是入场门槛。这就是为什么当我听到有人说“哦，你只要说一下就行，‘为什么’（why）是如此微不足道的事”时，我会发笑。这实在太无知了。我就是不知道所有这些说法的源头在哪里。
这让我想到，男人们总爱开玩笑说：“哦，我想在活动上穿点更有意思的东西。我总是穿西装。总得是西装。太无聊了。”而另一些人则说：“闭嘴吧。你为什么要让男人的生活变复杂，非得更有创意地穿衣服？我们靠西装过得挺好的。”这让我想到，如果产品经理的工作只是找出问题，然后说：“好，就这样吧。生活美好。”结果却并非如此。不管怎样，你最后那一点也让我想起最近的一条推文，我想是 Patrick Collison 或 John Collison 发的，说的是很多人认为用户研究就是用户研究来决定你做什么。人们就是这么想的。就好像用户研究引出你要做的东西。而他的观点很有意思：用户研究是在充实你对用户和客户的模型，而这个模型应该指导你做什么。你要不断地努力完善这个模型，但你应该在脑子里有一个关于客户和用户的模型，可以随时回头参考，而不是依赖用户研究来回答你所有的问题。你对这个观点怎么看？
嗯。我是说，首先，他们用 Stripe 做出的成就太棒了，那是另一个很好的例子，我也喜欢他们从优秀公司那里挑选哪些东西来为自己打造文化。所以我绝对同意，但我还想再往前走一点。因为用户研究是个很好的话题。我是说，这本身就是一个很棒的产品话题。我喜欢。我是用户研究的铁杆粉丝。你刚才听到我基本上在论证同样的事情：别跑出去把所有时间都花在验证问题上。尤其是，我们知道，他也在这么说。他是在谈构建我们用户的心智模型，这非常重要。设计良好的产品都靠它滋养。不过，围绕用户研究还有另一层，我发现那是更大的困惑来源。实际上，今天早上我刚和一个团队聊过。
他们说，他们做用户研究的方式就是测试他们的原型。当有足够多的用户说他们多么喜欢时，他们就去开发。而我说：“不，我们做用户研究不是为了这个。”而且这骗不了任何聪明的领导者。现在，我们又回到了问题发现与解决方案发现，但我们大部分时间需要花在解决方案上。那就是做原型，就是与用户一起测试，与客户一起测试，与利益相关方一起测试，与我们的开发者一起测试。我们在不断地测试。我们不只是想知道他们是否喜欢它。事实上恰恰相反。当我们做用户研究时，我们是在找出他们不喜欢它的所有原因。实际上，这是 Elon Musk 的一句话：做用户研究时，你应该专注于找出他们不会使用你的产品的所有原因。
尽管 Elon Musk 现在有一些问题，但他在产品方面相当出色。所以他在这方面非常在行。这就是你应该怎么去想这件事。用户研究人员会谈到生成式（generative）与评估式（evaluative）用户研究的区别。就我们从中获得的有价值事物的数量而言，大部分是评估式的。他们在告诉我们他们不会使用它的原因。我再补充一点，你没问这个，但它总是会出现。我讨厌用户研究人员自己跑出去做研究，然后带回一份报告，不是因为他们不懂自己在做什么，他们确实懂。原因是这份报告太常被忽略了。所以对我来说，规则是——我也对我辅导的公司里的用户研究人员这么说——如果产品经理和设计师不能在他们的产品测试期间到场，就取消这次测试。他们必须在场。这才是让他们对自己团队有用的地方。
我百分之百同意。我记得我曾带着一个研究团队去巴黎，至少我们团队的工程负责人、设计负责人，还有我和研究员都去了巴黎，与 AirBnb 房东做这些焦点小组。我们的研究员非常坚决地要求我们和她一起去，而不是只由她带回大量洞见。所以我百分之百认为那里有价值。尤其是让工程师参与这个过程，我觉得极其重要。
魔法就是在那时发生的。
本期节目由 Modern Treasury 赞助播出。Modern Treasury 是用于转移和追踪资金的下一代操作系统。他们正在为管理复杂支付流程的公司实现开发者工具和财务流程的现代化。想想通过加密货币入金通道（on ramps）的数字钱包、网约车、交易市场、即时借贷等等。他们与 Gusto、Pipe、ClassPass 和 Marketa（原文如此，疑为 Marqeta）等高增长公司合作。Modern Treasury 强大的 API 让工程团队可以把支付流程直接构建进你的产品，而财务团队可以通过简洁现代的网页仪表盘监控并批准一切，实现实时支付、自动对账、持续会计和合规解决方案。Modern Treasury 的平台每月用于对账的金额超过 30 亿美元。他们是当今市场上最炙手可热的年轻金融科技初创公司之一，已获得 Benchmark、Altimeter、SVB Capital、Salesforce Ventures 和 Y Combinator 等顶级机构的融资。请访问 moderntreasury.com 了解他们。
我想回到功能团队的话题，具体来说，当人们在你所说的功能团队或功能工厂里工作时，他们可以做些什么，来了解那种体验可能是什么样，或者即使公司整体没有转向新的产品构建方式，也能以更好的方式工作。
当然。很多公司正在有意识地努力转变为真正的产品团队。大多数人所说的转型就是这个意思。所以很多公司在这样做，但即使没有，我也总是鼓励。很多人会问我：“我是不是应该直接放弃这家公司，去一家像样的产品公司？”我总是说：“在你放弃之前，先试一试这个。我建议你去找你的经理说：‘你觉得我们做个实验怎么样？接下来一两个季度，为什么不让我们试试这样运作？’如果进展顺利，很好。如果不顺利，也没有损失。我们就回到原来的样子。”所以以产品团队为单位去尝试并不难。变得昂贵且有风险的地方，当然是改变整个业务单元。所以如果只是一个产品团队，通常他们会让他们试。尤其是当提出这个论点的人说：“我了解到，我们钦佩的一些公司并不是像我们这样工作的，也许我们应该试试这个。”
既然谈到了这个话题，他们试的或做的是什么？团队可以做哪些事情？我知道你可能正要讲到，但我很好奇。
不过这正是我接下来要建议的。假设他们得到了点头同意：“去吧，给你一个季度，去试试。我们看看是什么样子。大家都很好奇。”那么对我来说，有几件事你要做。首先，你要确保——经理可以帮上很大的忙，但产品团队也可以向上管理得足够好来做到这一点。第一，你需要确保团队拿到的是一个要解决的问题，而不是一个要构建的功能。其实，反向推导并不难。比如有人告诉你：“你得去实现‘先买后付’（by now pay later，原文如此，应为 buy now pay later）功能，放到我们的电商网站上。”现在有一千份路线图上都有这一项。如果有人这样对你说，去找提出这个需求的利益相关方并不难，你可以说：“我们会着手做这个，但你能告诉我你是如何衡量成功的吗？我们想确保我们做的东西，你会认为是成功的。你是如何衡量成功的？”
对于这类事情，通常答案很明显。是转化率，或平均购物车价值，或诸如此类。就是他们关心的一些 KPI。所以你会说：“你的看法是，如果我们增加‘先买后付’，会有更多人能够购买并完成交易，因此它会有回报，并会体现在这里。我理解得对吗？”他们大概会说对。他们也可能会说：“嗯，不，我们做这个是为了国际业务的目的或其他什么。”很好，知道了。确保你把不管是什么都记录下来。这是第一件事。你想要解决的是什么问题？现在，最难的部分是，就像我说的，通常我们有设计师和工程师，他们非常愿意真正去做自己所受训练的事，但产品经理通常需要做一些功课，才能让自己有能力做到这一点。
我讨厌那些设有单独产品负责人（product owner）的公司的想法，因为产品负责人只是一个行政角色。产品负责人几乎从来不具备做产品经理的技能。所以这是个问题，但我们就假设有一位产品经理，而且从来没有人辅导过这位可怜的人，所以他们真的懂得不多。那么这位产品经理需要做的第一件事，就是让自己做好准备，以所需的方式为团队做出贡献。总的来说，这意味着四件事。首先，他们必须真正了解用户和客户。他们必须几乎被视为用户和客户方面的专家之一。我记得我还是工程师、想转做产品经理时，指导我的人明确说过，在拜访 30 位客户之前，我不被允许替团队做任何决定。他给的数字是 30。美国 15 位，欧洲 15 位。
而解决这个问题的，是他安排的一次为期三周的出差。有趣的是，我当时并不认为我需要拜访客户，因为我以前是开发者，我做的是面向开发者的产品。我心想：“哦，天哪，我唯一拥有的就是我了解我们的客户。”而他说：“嗯，我唯一能确定的是，这从来都不是真的。”所以我不得不去拜访客户。不管怎样，这是第一件事。第二件事是，他们必须是数据方面的专家。你的产品是如何被使用的？这如何随时间变化？销售分析是什么样的？用户分析是什么样的？所以你必须知道你的产品实际上是怎么被使用的，这只是了解你的客户的另一种方式，但很重要。第三件事——这通常是最难的一件，也是你的利益相关方会据此评判你的一件——是你必须了解业务的不同部分。
你必须知道它如何营销、如何销售、如何付费、如何变现。如果有任何合规、监管、隐私、安全方面的问题，你需要知道那些是什么。所以你必须让那些利益相关方相信，你理解问题是什么，你明白该关注什么，并让他们相信，只要有任何疑问，你都会给他们带来一个他们能看到的原型，确保没有问题。所以你需要与业务各个部分建立这种信任。第四个领域是，你必须了解竞争格局。你必须了解行业。你必须了解趋势。我认为这是有趣的部分之一。有一些不错的行业人士可以关注。你可以做到这一点。所以这就是你带给团队的四件事。要认识到，设计师没有这些信息。
工程师也没有这些信息。如果团队要成为一个被赋能的团队，并且要想出解决方案，他们就需要团队里有人带来这些知识。而那就是你，作为产品经理。这是被赋能团队失败的最大单一领域。产品经理能力不足，或者委婉点说，不称职。好。第三，如果团队现在要做决策，他们需要战略背景。换句话说，他们需要了解大局。产品愿景是什么？产品战略是什么？其他团队在做什么？这与我们在做的事有什么关系？这就是战略背景。通常，我们从领导者那里得到这些，但至少，产品经理将不得不去了解那是什么，尤其是产品战略。好。最后，产品团队需要技能，即发现（discovery）技能和技术手段，对我来说这是有趣的部分。
这就是我写《Inspired》这本书的原因，为了分享最常用的技术手段。也有其他书谈到这些发现的技术手段。但读点东西，学习这些技术手段。如今有很好的技术手段，比我们以往任何时候都更好。我是说，我们做产品发现已经很久很久了。实际上，Steve Jobs 在 95 年对此做了很好的总结。但如今的技术手段，比我刚开始学习时以及他当时谈论的，要好得多。好得多。所以你需要学习这些技术手段。这是产品经理的行业工具。所以回答你的问题，如果你在一个功能团队，想试一试，成为真正的产品团队的一员，这就是你需要去做的四件事。公平地说，它们不需要花很长时间。最长的一项是产品经理学习这些技能，如果他们以前从未学过的话。但即便如此，通常也只需要两到三个月。
哇。这太有洞察力了。我很好奇，产品经理怎样才能为尝试这样的事情做好成功的铺垫，因为我觉得这是一个高风险的实验。如果不成功，公司会说：“哦不，这太糟糕了。没用。我们不会这样做了。”
这种事会发生。
嗯。你提到了人们可以做的很多事情，然后你提到读《Inspired》。还有没有别的，能让人们在更大的公司里进行这类实验时为成功做好铺垫的事情？
嗯，具体就我们现在谈的内容来说，有 Teresa Torres 的新书《Continuous Discovery Habits》。那是一本非常好的书，正中要害，非常多地谈到这些技能，它基本上会手把手带你度过最初的几周。另一本好书是《Sprint》，Jake Knapp 写的。它同样会手把手带你。当然，用 400 页来讲一种技术手段，这是个特定的技术，但它是个好技术。这些书也会手把手带你走过去。另一件事是，如果你能找到可以辅导或指导你的人，就去找。我是说，我就是这样学会的。
我也是。
我认识的大多数人也是这样学会的：他们有一位在乎他们职业发展的经理，对他们说：“这是你需要做的。”我记得我第一次了解发现（discovery）的概念时。我当时是工程师，后来被提拔为技术负责人（tech lead）。我的经理说：“既然你现在是技术负责人，你必须像关心怎么构建一样，关心你构建的是什么。”他说：“这意味着你必须参与到你以前作为工程师从未参与过的事情中。”我当了好几年工程师，沿着那个小阶梯一步步往上爬。我觉得这非常有意思。事实上，那是我对产品的初次尝试，因为我开始做我们今天所称的发现。我开始参与进去。我开始去拜访客户。我开始了解这些问题。如果我能改变这个行业中的一件事，那就是每个人都会有一位在乎他们职业发展、并能帮助他们把工作做得更好的像样经理。
我们怎样才能让这成为可能？
因为有时我有愤世嫉俗的倾向，这些年来世界变化实在太小，但我最近非常高兴，如果……现在我知道是什么造成的了。是“大辞职潮”（great resignation）造成的，但 Microsoft、Google、Netflix、Apple 的高管们，都一直在吹嘘他们多么重视辅导。你注意到了吗？我是说，字面意义上，Google 的 Sundar 一直在说，他们在领导者身上寻找的头号特质是做一个好教练。第二是他们不是微观管理者，并且知道如何赋能自己的团队。而在 Microsoft，他们对领导者有三条原则，也就是他们一直在宣传的对经理的要求。第一，辅导。第二，关怀。第三条我忘了是什么。然后在 Apple，他们对领导者有四大职责。辅导是其中之一。所以他们都更高调地谈论这件事。当然，这不是偶然的。他们很久以来就一直在乎辅导。通常是因为 Bill Campbell 影响了这些公司，但他们确实重视辅导。只是现在他们谈得多得多了。他们本质上是在说：“来这里工作吧。我们在乎你的职业发展。”
嗯。我知道你在教教练。我想你最近办了一场会议，你在辅导教练们，是吗？
是的。不太算会议。我们的问题是，SVPG 很小，只有五个人。而且我们的档期已经排到将近一年之后了。所以总有人问我们可以推荐谁，事实是，我们认识并且能推荐的人并不多。我是说，有很多人在做功能团队那一套，但来问我们的人是想成为一家优秀的产品公司。所以我们认识的人不多。因此我们决定在欧洲办一场、在美国办一场活动，邀请独立教练参加。我们不向他们收取任何费用，这只是一种认识他们、并希望能帮到他们的方式。所以几个月前我们在伦敦办了一场，12 月我们会在纽约办一场。
这绝对是我收到的最常见的问题之一：“我去哪里找教练？谁是好教练？”所以我真的很喜欢你在培养更多教练、帮助教练变得更好。顺着同样的思路，你认为产品管理这个角色正在如何变化和演进？
这是那种有两条岔路的回答。在优秀的公司里，它真的没怎么变。我是说，二十多年来，在优秀的产品公司里，它真的没怎么变。他们使用的技术手段确实发生了一些巨大的变化，但工作本身、原则没有变。然而，如果你更全面地看整个行业，那简直是一团糟。有太多与产品相关的头衔，其中大多数都很荒唐。真正让我抓狂的有两个：整个欧洲到处都是产品负责人（product owner），这些产品负责人是由敏捷教练（Agile coach）教出来的。这些教练大多一天产品都没做过。他们只懂流程，所以教的就是流程。这就好比随便从街上拉个人来，说：“我来教你 Scrum，然后你就会突然变成工程师。”
这有多荒唐？Scrum 不会教你如何开发，就像产品负责人课程不会教你如何成为产品经理一样。结果就是，在无意中，盲人领着盲人，我们从来没有过如此高比例的完全不合格的产品人。当然，在美国，这个问题没那么严重。东海岸比西海岸更有这个问题，但没那么严重。我们这边有别的情况。有一些非常好的产品运营（product ops）的实施和定义，但也有一些真的很糟糕，它们造成了同样的问题。我想告诉大家的一点是，忘掉所有这些愚蠢的角色和术语。对产品经理来说，真正神圣不可侵犯的有三件事。其他一切我都非常灵活，但这三件是神圣的，因为它们正处于在这份工作中取得成功所需的核心。
第一，产品经理需要不受阻碍地接触他们的用户和客户。任何试图插在他们和客户之间的人都没有在帮忙。尽管他们往往是善意的人，他们会说：“哦，这是我在客户成功部门的工作，或者我在销售部门的工作，或者……”不，一旦你被切断与客户的联系，作为产品经理你就完了。第二，产品经理需要不受阻碍地接触工程师。如果你不是每天与一群工程师一起解决问题，你就不是产品经理。所以，同样地，有这些乐于助人的人，叫作产品负责人、项目经理，或各种不同的变体，他们认为自己的工作是与开发者对接，扮演中间人的角色。而他们不明白为什么自己多年来没有创新。
原因就在这里。他们切断了那个关键的环节。第三是不受阻碍地接触利益相关方，因为一个好产品解决的是刚刚变得可能的事——这就是为什么工程师如此关键——面向真正的用户和客户——这就是为什么这点如此关键——并以对业务行得通的方式——这就是为什么接触利益相关方如此关键。如果你有这三件事，能直接接触这三者，这才是关键。如果你还有其他职责，嗯，只要你愿意疯狂加班，那也行得通。但如果你想过一种更理智的生活，你可以把所有这些其他事情都交出去。
项目管理、质量保证、产品营销，所有这些事情。运行时、生产运维。字面意义上，你可以把这些交给其他人，但不要把这三件事委托出去。我就是一直在恳求这些公司。他们没有意识到自己这样做造成的伤害。当然，他们为什么这么做，也不是什么秘密。他们说：“哦，产品经理的工作对一个人来说太难了，所以我们要把它分成两半。”他们根本不知道自己造成了多大的伤害，但他们就是在这么做。所以卸下其他职责没有问题。这是件好事，尤其是随着规模增长，但绝不能触碰那三件神圣的事。
太棒了。我正想问这个。产品经理这个角色有太多要做的事，是一份如此高强度、职责如此之多的工作。所以出发点是好的：从产品经理的盘子里拿走一些事情。具体来说，我看到产品运营（product ops）在增长，正如你所说，再深入一下，你觉得那不是一个好的角色、不是一个有成效的方向吗？还是有时候它其实是有帮助的？
嗯，根据我刚才说的，如果你现在谈产品运营，如果产品运营的设立是为了取代那三件事中的某一件——这是一些常见的定义——那就糟糕了。我是说，产品运营也有很多好的定义，但有些工作，我应该说有些产品，有很大的运行时责任，运行时生产环境、生产问题、缺陷分诊、试图弄清楚发生了什么。有一点这样的事情是完全正常的。
每家公司里每个人都要做这些。但有时它变得太多，以至于没有时间去弄清楚接下来应该构建（billed，原文如此，疑为 built）什么。每天都在救火。这是产品运营的一个好定义。另一个好的定义是，那些创建工具来帮助产品经理提高效率的人。这是个好定义。但请注意，这些都没有拿走那三件事中的任何一件。而常见的定义之一是，他们会说：“哦，我们从客户那里得到了大量关于产品如何被使用的数据。我们设立了一个产品运营的人，来梳理这些数据。”然后他们会告诉产品经理他们认为产品经理应该听到的东西。
为了强化这一点，那三件事再说一遍是什么？以防有人没听全。
好的。直接接触客户，直接接触工程师，直接接触利益相关方。
太棒了。最后一个问题也许是，在产品管理领域，你还担心其他趋势吗，关于产品经理这个角色的发展方向？
嗯，我对刚才描述的那两个趋势非常担心。我要说的是一直存在风险、而且不会消失的东西。顺便说一句，Steve Jobs 谈到过这个。这是他谈到的另一种疾病，那就是流程型人员（process people）的疾病，顺便说，这也是产品运营的另一种糟糕的实例，就是流程型人员。我知道这是从哪里来的，我理解，但规模化是困难的。你认识谁不觉得它难吗？
我不认识。
它很难。从根本上说，有两种规模化的方式。你可以靠流程来规模化，也可以靠领导者来规模化。据我所知，唯一能带来好结果的方式是靠领导者来规模化，但对很多公司来说，更容易、更有吸引力的是靠流程来规模化。这就是为什么你会看到——你可能看着 safe（原文如此，疑为 SAFe）这样的东西说：“这些人是不是疯了？他们是不是脑子有问题？这里面没有任何好东西。这只是重新包装的瀑布模式。他们到底在想什么？”嗯，他们在想的是：“哦，我们有了靠流程规模化的答案。”
这非常有吸引力，尤其是对某些甚至不懂软件的老派 CIO 来说。所以它疯狂地增长。而且不只是这一个。有一大堆这样的流程，人们被愚弄了。这只是营销，所以他们自称敏捷（Agile），但它与敏捷毫无关系。它是敏捷的对立面。所以我非常担心这种认为流程曾经是答案的思潮，因为它不是，它就是不是。我认识的所有最优秀的领导者，不管我们谈的是 Bezos 还是 Elon Musk 还是其他任何人，Steve Jobs 在那段视频里也在说：小心流程型人员的疾病。他们会毁掉你的公司。
这是一个多么精彩的收尾方式。最后还有两个问题：如果大家想联系你、了解更多，在网上可以在哪里找到你？听众怎样才能对你有所帮助？
嗯，我们发布的所有内容都在 svpg.com 免费提供。也就是 siliconvalleyproductgroup.com。你也可以在社交媒体上找到我，不过我是不情愿的，我只做最低限度的事。社交媒体上的信噪比实在太糟糕了，我尽量专注于其他地方。但你肯定可以在那里找到我。嗯，我是说，在我职业生涯的这个阶段，我只是在享受乐趣。我不向任何人索取任何东西。不过，我告诉你一件我喜欢的事，我喜欢收到难题。我的大多数文章都是由我以前从未被问过的问题启发的。
所以当我把同一个问题听了足够多次，我就意识到也许我应该写写这个。我喜欢这样。尤其是即使那是我需要去多学习的东西。而且在我职业生涯的这个阶段，我有一本很棒的人脉名册，我可以去找他们说：“嘿，Lenny，你怎么看这个？”或者 Shreyas，或者 Teresa。我认识的所有这些人都非常聪明，我可以去找他们问：“你怎么看这个？”然后我把一切汇总起来，写成文章。所以，是的，如果你真的试过了，却找不到一个难题的好答案，欢迎给我发邮件。
太棒了。把你们的难题发给 Marty。Marty，非常感谢你来做这期节目。这正是我所希望的一切。我真的很感谢你加入我，谢谢你来到这里。
嗯，再次感谢邀请我，Lenny，也祝外面的每个人好运。
非常感谢你的收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你最喜欢的播客应用上订阅本节目。也请考虑给我们评分或留下评论，这真的有助于其他听众发现这档播客。你可以在 lennyspodcast.com 找到所有往期节目或了解更多关于本节目的信息。下期节目再见。