快速推进与应对不确定性 | Jeremy Henrickson(Rippling, Coinbase)

Jeremy Henrickson 2023-06-04

快速推进与应对不确定性 | Jeremy Henrickson(Rippling, Coinbase)


文字稿

Jeremy Henrickson: 作为领导者,浮在上面说”嘿,你去攻那座山头,你们几个去做那边的事”,这种做法非常非常诱人。但事实上,你真正了解挑战、问题或成功所在的方式,是亲自和身处一线的人站在一起,投入其中一件事——不管哪件事看起来最难、最复杂。所以我尽可能经常这样做,而且我发现每次做这种深入细致的练习,我总能学到很多。

访谈开始

Lenny: 欢迎来到 Lenny’s Podcast,在这里我们采访世界级的产品负责人和增长专家,从他们建设和发展当今最成功产品的宝贵经验中学习。今天的嘉宾是 Jeremy Henrickson。Jeremy 是 Rippling 的高级产品副总裁,领导产品和设计团队。此前,他是 Coinbase 的首席产品官,在此期间产品与工程团队实现了 10 倍增长,并帮助 Coinbase 在加密货币市场最疯狂的时期实现了规模化发展。在本次对话中,Jeremy 分享了他关于在规模化过程中保持速度、创建快速决策文化、产品负责人深入问题以及成为其领域世界级专家的重要性的经验教训。在面试产品经理时应该关注什么,为什么依赖框架会对你的成功造成如此大的损害,为什么你可能要避免做 MVP 而是先为最复杂的用例做设计,以及更多的内容。在与我们的赞助商简短介绍之后,请欣赏与 Jeremy Henrickson 的这期节目。

Jeremy Henrickson: 非常感谢你的邀请,我很高兴来到这里。

Lenny: 我听到的关于你的评价都是非常好的,我很期待从你在 Rippling、Coinbase 以及你建设的所有产品和团队的经验中学习。再次感谢你的到来。

Jeremy Henrickson: 非常高兴来到这里。

Coinbase 的疯狂岁月

Lenny: 我想从你在 Coinbase 的经历开始聊。你在那里担任首席产品官,而且你担任这个角色的时间,可能是加密货币市场最疯狂的时期。我想大概是在 2016 到 2018 年间,我看着比特币的价格,几个月内从一千美元涨到了两万美元。所以我很好奇,那段经历是什么样的?特别是作为产品负责人带领团队经历那样的时期,是什么体验?

Jeremy Henrickson: 给我留下最深印象的是 2017 年。加密货币在 2016 年初差不多处于最低谷,之后慢慢开始爬升,然后在 2017 年真的起飞了,真正进入了公众视野。Coinbase 当时只有一个交易所,基本上就是法币与加密货币之间的入金和出金通道。在 2017 年这一年间,使用量增长了 40 倍。

Lenny: 这对很多人来说简直是梦想成真。

Jeremy Henrickson: 既是美梦也是噩梦。我非常幸运能和我真正信任的团队一起工作,大家能肩并肩在战壕里并肩作战。那段时间学到了很多关于如何快速扩展系统的经验。人们喜欢在周六早上交易加密货币,所以很多个周六早上,系统边缘总会冒出新的故障,我们需要立刻冲进去修复。所以那段时间关于选择和谁一起工作、如何保持专注、确保对的人在对的时间出现在对的房间里,这些方面有非常多深刻的教训。

在混乱中保持专注

Lenny: 好,我们来展开聊聊其中几点。专注这个话题确实很有意思,大家总是在谈论,但实际做到却很难。我猜你是怎么让团队保持专注的?我想象一下,加密货币领域到处都是有人在暴富。

Jeremy Henrickson:

Lenny: 系统一直在出问题,你是怎么让团队保持专注的?

Jeremy Henrickson: 首先,你不能谈论什么人暴富的事。这是一个非常技术性的话题,你要谈的是客户,是他们的钱,而第一要务是安全。有一个叫 Philip Barton 的人,现在是我的朋友,他是 Coinbase 一位非常出色的安全负责人。他总是能够把我们极其快速做出的决策放在一个正确的上下文中来看,说:“看,不管我们需要多快地推进,这些是我们能做的决策类型,同时仍然能保证安全。“所以安全始终是第一位的。其次是要同时关注问题的即时性——比如网站挂了之类的——先把问题解决,但同时也要把这些情况放到我们未来六个月要去哪里的框架中去思考。我们真正的目标是什么?我们预计的交易量会是多少?从用户体验到产品深层后端,需要做到什么才能真正为用户所用?

Lenny: 作为产品负责人,在一切都在经历 40 倍增长的情况下试图让大家保持专注、让一切不脱轨,你觉得最大的挑战是什么?

Jeremy Henrickson: 我觉得最大的挑战在于,加密领域整体上充满了不确定性,连”以太坊能不能成”这种简单问题都存在争议。当时没有人能给出真正的答案,只有各种强烈的意见。所以你必须让这些辩论进行下去,因为发生的事情太多了,但辩论之后,你必须能从中形成一个清晰的公司层面的共同目标,大家一起朝那个方向努力。虽然在边缘问题上可能仍会有不同意见和争论,但你要全力朝这个答案推进,直到你决定全力转向另一个答案。我觉得我们在 Coinbase 这一点上做得相当成功,虽然过程并不总是轻松的。

Lenny: 关于这个话题,最后一个问题。

Jeremy Henrickson: 好。

Lenny: 经历过那样的时期,很多人都会经历这种高强度工作的阶段——天哪,这不是那种疯狂的、压力巨大的、工作时间超长的状态吗——但回过头看,那些时期往往成为你职业生涯中最重要的、最有意义的阶段。一方面,这也是你的感受吗?另一方面,对于正在经历类似阶段的人,你有什么建议吗?比如这种时期有没有什么积极的一面?

Jeremy Henrickson: 确实很难,对吧?并不总是轻松的。我当时有一个刚出生几个月的女儿,要平衡这些东西真的非常困难。但我一直很享受学习的速度。正是这些经历,我感觉最大程度地加速了我个人的成长和学习,因为它是在困难事物的熔炉中锻造出来的。所以我觉得当人们身处那些时期时,不妨退后一步,跟朋友聊聊到底在发生什么,把它放在一个更大的时间框架里来看——嘿,三四年或五年后我们回过头来看这段经历,你会意识到:第一,我们在那段时间里做了一件了不起的事;第二,我们学到了很多东西,而这些东西可以带到之后无论做什么中去。

规模化保持速度

Lenny: 在我们聊天之前,我问你人们最常向你请教什么方面的建议,你说人们经常问你如何在规模化时保持速度(velocity),这是每个创始人和产品负责人一直在努力做到的事情。那么你学到了什么?关于在扩展规模时保持甚至提升速度,你怎么告诉别人的?

Jeremy Henrickson: 我觉得这里有很多不同的答案,而且很多都跟你所处的业务性质高度相关,不同的业务可以以不同的方式保持速度。但我认为有一个普遍适用的真理:你需要小团队、明确的使命。对吧?如果 300 个人试图一起做一件事,光是沟通上的挑战、邓巴数(Dunbar’s number)之类的问题就会全部浮现出来,想快速行动真的非常非常难。所以要把一群较小的人组织起来,把一个总是非常庞大的问题拆解成足够小的部分,让小团队能够全力以赴地攻克,同时最小化横向沟通,这是第一点。

第二点是,在技术层面,你能把越多东西固化到一个清晰的平台中,就越能降低每个在业务领域工作的人的决策复杂度。一个拥有清晰接口、对工程师和产品人员来说都好用的平台,可以简化人们思考这些问题所需的空间。但这并不总是容易的。你不能只是写一个平台然后指望它能适用于产品。这很大程度上是一个迭代的过程,但越能在上面投入,并拥有既具备系统思维又同时具备产品思维的合适人才,就越重要。

第三点,从领导力的角度来看,就是深入一线。作为领导者,飘在上面说”嘿,你去攻那个山头,你们去做这个”是非常非常诱人的。但事实上,你真正了解挑战、问题或成功之处的方法,就是和一线的人一起待在战壕里,参与到其中一件事上——无论哪件看起来最难或最复杂的。

我尽量经常这么做。我发现每次做这种深入细节的练习,我都能学到很多东西。最后一点,就是确保团队拥有正确的经验和资历分布。有时候你启动一个团队,团队可能在做一些从零到一的事情,而他们在所有这些从零到一的事情上都非常出色。然后两三年后,同样的人要试图把产品扩展到数百万用户,结果发现:第一,他们不那么喜欢工作中的这部分;第二,也许他们在这方面没那么擅长。所以你需要不断审视团队,确保人们在做自己热爱的事情,如果不是,那就试试别的事情,重新调整团队,确保有正确的技能组合。我发现如果你把这些都做到了,再加上产品领导层说”这是我们需要做的”,并且在需要做的事情上非常清晰和精确,那么你通常甚至能随时间加速,因为你把更多东西固化到了平台中,这让工程师能以更少的资源做更多的事,这总是非常惊人的。

Lenny: 好,让我深入追问其中几个点。这些真的很棒。

Jeremy Henrickson: 请说。

Lenny: 关于小团队加明确使命这一点,在 Rippling 或 Coinbase 有没有特别好的例子来说明这一点?

Jeremy Henrickson: 一个例子大概是三年前,我刚加入公司的时候,我们决定需要做一个考勤和工时管理的产品,市场对我们有很大的需求,而我们还没做,这是很多客户需要的东西。我们可以选择很多方式来做这件事,但我们的做法是说:看,找一个工程师——一个非常优秀的系统工程师,同时也能做一些产品思考——然后让 CEO Parker 也花时间参与。就从这里开始,Sachit 又带了几个人进来。这四个人在大约九个月的时间里,构建了一个考勤和工时管理产品。这是他们唯一在做的事情。他们不需要操心我们的薪酬产品在做什么,除非需要做一些集成;也不需要操心福利团队或我们的 IT 产品在做什么。他们全身心地专注于这一件事,然后在需要与套件其他部分连接的地方做好对接,这让他们能够以极快的速度推进。

Lenny: 其中有多少是因为 Parker 在团队里帮他们扫清障碍,又有多少是因为团队足够小且足够专注?


Jeremy Henrickson: 我觉得主要还是因为团队小且足够专注。当然,Parker 能做一些事情、帮他们扫清障碍,这是只有 CEO 才能做到的,确实有帮助。但关键是在 Rippling,我们这种方式已经复制了十几次了。这是我们启动新业务的标准模式。所以不能只靠他一个人去扫清障碍,尽管他确实会这么做。更核心的是这种模式——让小团队能够独立推进事情,然后无论是 Parker 还是公司里的其他人,都可以直接找到他们说:“嘿,进展怎么样?我们做的事情对吗?让我看看最新的设计,我来给点意见。”

所有这些事情的发生节奏,比你在组织架构里往下穿透三层去做同样的事情要快得多。我觉得这也许是另一个关键点——每个人都能接触到高层领导。是的,我们有管理架构,因为必须有,但这个管理架构不会妨碍组织中任何人、在任何地方去了解实际正在发生的事情。而且这种了解是非常直接的。

Lenny: 那我们来聊聊你刚才描述的那个模式。这个模式到底是什么?这是你们做新产品的方式,我知道 Rippling 内部有很多很多产品和功能,我们待会儿会谈到。你说的是一种新增业务单元或新产品功能的方法论。

Jeremy Henrickson: 对。

Lenny: 这个模式大致是怎样的?

新产品启动模式

Jeremy Henrickson: 这个模式其实很简单。在绝大多数情况下,我们意识到需要构建某个东西,然后会有一页纸的概述说明它是什么。通常我们比较幸运,我们要构建的东西在行业中已经以某种形式存在了,虽然不是我们能做出的差异化版本,但考勤和工时管理就是一个例子——这在业内是广为人知的,有整家公司只做这一件事。所以我们从这里出发,找到一位极具创业精神的工程师,他理解什么是高速推进,理解在信息不足的情况下如何做决策,理解如何与设计搭档以极快的节奏协作。

我们给他配一位设计搭档,然后说:“来 Rippling,先用几个月时间了解我们的平台。先去另一个团队工作,了解对他们来说什么是容易的、什么是困难的,平台是怎么运作的,其他产品是如何在这个平台上构建的。去跟在这里做过产品创始的人聊聊,了解他们的经验,这样你可以从中学习、迭代,形成自己对产品的判断,然后再开始构建。”

在这段时间里,他们同时也在招募一个通常两到四人的工程师团队,这些人同样具备从零到一的 mentality(心态),然后开始构建。通常在六到九个月的时间里,我们可以把一个产品从一张白纸做到上线,或者至少做到内部使用的程度——我们会大量 dogfood(内部试用)自己的产品。然后再从这里发展壮大。有时候当你准备上线一个产品时,快到发布阶段,你会发现五六个人的团队就能持续维护这个产品,不需要再加人。有时候则需要扩编——比如这个东西马上要上生产环境了,还有一大堆事情要做,团队需要从 4 人扩到 15 人之类的。这完全取决于具体产品,但大致的生命周期就是这样,然后你继续扩大规模。

Lenny: 这太有意思了。确认一下我的理解——你们找一个创始人型的人来牵头一个新想法,这个人是从内部招募的,还是有时候也从外部找?

Jeremy Henrickson: 两种都有。

Lenny: 有意思。

Jeremy Henrickson: 两种都有。

Lenny: 好。然后你给他找一个设计搭档一起合作,来确定到底需要构建什么。是只找一个设计搭档,还是会尽量多找几个?

Jeremy Henrickson: 通常是一个。所以我们有设计师——我们有设计团队——

Lenny: 哦,设计搭档,指的是设计师,不是一家合作公司那种设计伙伴。

Jeremy Henrickson: 对对对,就是那种了解 Rippling 产品的人,了解我们的组件库,了解所有这些东西,同时在 UX、交互和视觉设计方面很专业的人。

Lenny: 明白了,是设计师。好,然后他们基本上和几个工程师一起,就是启动一个新产品线并发布的团队,随着规模增长,团队可能会扩大,也可能不会。

Jeremy Henrickson: 对,就是这样。而且比较灵活,大概每两周左右,他们会和我或者 Parker 开会——取决于谁是这件事的 DRI(直接负责人)——对设计给出反馈,做一些关键的压力测试:“如果我是小公司的管理员,或者大公司的管理员,我用这个会有什么感受?这个界面对我适用吗?“所以我们在整个周期里都在做压力测试,努力在速度和完备性之间找到平衡。

对 MVP 的看法

Lenny: 这让我想到——我听说你不太推崇 MVP(最小可行产品),你们做产品是朝着更远的目标做的。是这样吗?如果是的话,你怎么看待一个产品的初始版本?

Jeremy Henrickson: 首先,我不想贬低 MVP。我认为 MVP 有它的用武之地,非常有价值,特别是当你真的是一家从零到一、从未做过任何产品的公司,而且没有明确的市场验证的时候。但就我们 Rippling 的具体情况而言,一个最小可行产品既对不起我们的客户,也对不起构建它的团队。我这么认为的原因是:当你设计一个最小可行产品时,你优化的是速度。在这一系列优化中,你会弱化那些更深层次的产品思考——思考什么才能真正让我们的产品形成差异化,这种差异化不仅基于我们现有产品和平台的能力,还基于这个产品未来应有的样子。

所以这在某种程度上限制了产品创造力,但更糟糕的是,它会导致在技术上构建出错误的东西。如果你只考虑简单场景,作为一个工程师,没有人来挑战你说”等等,那个医疗医院管理的场景怎么办?那是关乎生命的关键场景”——那你就会做出一组不同的架构假设,然后在这些假设之上继续构建,再构建六个月、九个月、一年,最终你会在那些假设之上堆叠几十甚至上百个决策。


Jeremy Henrickson: 而且一旦你把这些决策嵌入到产品中,再想推翻就极其困难了。因此我们深信:当然,要理解那些简单场景。理解如果你是一家两个人的公司,你不需要所有这些额外的东西,你接近这个产品时它会是什么样子——但同时也去理解,在全球拥有 10,000 名员工、面临那些极其复杂的使用场景意味着什么?什么样的模型才能支撑那种场景?我们要确保,在进行技术和产品设计时,能够容纳那种视角,即使我们在第一个版本中不会支持它,即使我们做出产品决策说:“看,我们现在确实不需要处理那种场景。“你仍然以一种不会阻碍你未来到达那里的方式来构建产品。这样做会多花一点时间吗?当然会。但从长远来看它能为你节省时间吗?绝对能。所以这就是我们的方法。

全球薪酬产品的实例

Lenny: 你能不能想一个具体的例子,在 Rippling 或 Coinbase 构建过的某个产品——它本来可以是一个非常简单的最小可行产品(MVP),但最终你们做出了正确的选择,在光谱上往更完整的方向走了一步?

Jeremy Henrickson: 好的。我认为在 Rippling 一个很好的例子就是我们的全球薪酬产品。我们本可以说:“嘿,我们只需要支持一个国家。我们需要支持,比如说,英国。“那我们就把所有美国的东西复制过来,照搬一下,把所有东西改成英国的样子。这会是最快的做法——当然这极大地简化了问题——但我们没有这么做。我们的做法是:看,我们需要同时上线六个国家,而这六个国家差异非常大。它们在 HRIS 方面、在名义雇主(employer of record)方面、在如何支付全球承包商方面、在薪酬如何运作方面都会有不同的要求,而我们要打造一个能同时适用于这些国家的系统。这带来了大量的下游影响。

但这意味着,现在我们的全球薪酬系统中,添加一个国家——虽然不容易——但比你不得不不断地复制粘贴、然后还要维护那些几乎没有底层关联性的各个版本要容易得多。相反,我们的系统中有 80% 是固化在全球薪酬平台中的,然后 20% 是各国特定的。而这部分特定内容大部分不需要由工程师来处理——让工程师去改那些本地特定的东西成本非常高——而是可以由合规部门的人来配置,由法务部门需要将正确文件录入系统的人来配置。所有这些都可以通过系统来处理,这让我们在后续推进时能快得多。

先设计最复杂的场景

Lenny: 我听你把这种理念描述为——你鼓励团队先为最复杂的使用场景做设计。这是你给这些团队的指导方针吗?

Jeremy Henrickson: 百分之百,说过很多次了。这是那种直到你亲身在这里经历之前,很难真正理解的东西,因为首先,它与大多数人过去的背景和文化截然相反。大家习惯的做法是:不不不,别想那么多,就聚焦这一个个案,把它当作一个切入点,然后从那里开始扩展。这也是为什么我们让新人,尤其是那些处于创始角色的新人,进来后先花几个月时间浸润在文化中,真正学习这些经验教训。这也是为什么我们对处于萌芽期的新产品介入非常深入,确保我们不会掉入那个陷阱。特别是因为,与此同时我们也在说:“嘿,但我们需要尽快发布这个产品。“所以你要在这两件事之间取得正确的平衡。

复合型创业公司

Lenny: 所以当我想到 Rippling,我觉得你们的文化就是用困难的方式、正确的方式做事。其中一个要素是,我听说过一个概念——Rippling 是一家”复合型创业公司”(compound startup)?这个词是什么意思?这种理念又是如何影响你们构建产品、组织团队的方式,以及你刚才谈到的那些关于最小可行产品(MVP)和新产品构建方面的做法?

Jeremy Henrickson: 复合型创业公司对我们来说,意味着我们本质上是很多个协同运作的业务。想想我们提供的产品——我们有薪酬,而有专门做薪酬的整家公司;保险和福利,有专门做这个的整家公司。事实上,仅仅是福利的一个片段,就是一整家公司的整个生命周期。我们的 IT 产品、设备管理、身份管理、考勤和工时管理产品——这些东西每一个本身就是一个行业,有数十亿美元规模的公司在分别服务它们。Parker 在创立公司之前的洞见是:当你把这些都分开时,结果就是所有这些数据被反复复制,根本不可能在各处保持同步。正确的做法是拥有一个单一的系统记录源——一个地方、一个数据库,所有信息都驻留在那里,这样每个下游系统都能始终在正确的时间拥有正确的数据。

然后你可以在此基础上构建工作流、报表、分析和权限管理等所有这些底层能力。所以复合型创业公司的理念就是:所有这些不同的业务都受益于建立在同一个平台之上。这个理念的激活能极高。所以在我加入公司之前,Parker、技术联创 Prasanna 等人构建了所有这些产品的第一版,他们能做到这件事本身就是一个奇迹。但一旦做到了,我们就拥有了那个平台,可以继续在那个基础之上构建新的垂直业务和新创项目。

差异化:单一系统记录源

Lenny: 这涉及到一个在本播客中多次出现的话题,就是差异化的重要性。感觉这就是 Rippling 的差异化所在。它不会只是这些垂直解决方案中某个做得更好的版本——核心差异化在于,我们要把所有事情都做了,而且因为全部在一个平台上,一切都会好得多。这是最初的构想来源吗?还是有不同的理解方式?

Jeremy Henrickson: 是的,我认为是这样的。核心论点是,拥有一个单一的系统记录源在很多、很多、很多方面都更好,对吧?最简单的一点是,有一个单一的事实来源,所有其他产品都可以依赖它。但除此之外,如果你不是从一开始就以所有东西都在一个单一系统记录源中为前提来构建,有很多其他事情你就做不了。你没法构建一个——比如说——能跨所有这些产品查看各种属性的权限系统。你突然之间就得做集成,而每个产品说的是不同的语言。你连一些简单的事情都做不了,比如构建一个产品然后问:这个人的经理是谁?大多数产品做不到这一点。大多数产品是找到某个事实来源系统,导出所有人的姓名和邮箱地址到电子表格里,再带上另一个邮箱地址或另一个名字,可能还有一个员工 ID 标识那个人向谁汇报,然后上传到另一个系统——顺便说一下,这些数据立刻就过时了,因为组织架构一直在变。

Jeremy Henrickson: 而在 Rippling,这一切始终是准确的。我们就是那个系统记录源。所以我们的所有产品只需要问:“嘿,这个人的经理是谁?“系统立刻就能给出答案。而这只是一个非常、非常简单的例子,说明了一件事——只有当你从一开始就解决了最复杂的用例,就像之前说的,解决了所有这些数据都必须放在同一个地方这个问题,你才能做到这一点。所以我们的差异化能力归根结底就是这一个根本性的决策,它让我们能够做到其他任何公司实际上根本不可能做到的事情。

快速决策的文化

Lenny: 你觉得 Rippling 文化中最独特的地方,可能是你还没提到的,是什么?

Jeremy Henrickson: 我觉得最根本的一点是执行速度。我认为是决策的速度。这可能是最难在人到来之前向他们解释清楚的事情。你很难理解,直到你亲身体验。就好像——我们不要把会议安排在下周、明天或今天晚些时候。我们正在开会,需要做一个决定,那就当场做决定;如果做不了,我们就立刻在 Slack 上拉需要的人进来通话。今天之内,这个决定就会做完。

当然,确实存在一些不可逆的决策不能这样处理,但在大多数情况下,我们非常重视决策的节奏和响应速度。我待过各种规模的公司,从 5 个人到 5000 个人的,没有一家公司能以 Rippling 这样的节奏运转。我认为我们能够持续保持这种节奏——这部分也要归功于我们是一家复合创业公司(compound startup),拥有这些小型独立运作的团队等等——这是公司文化中非常具有差异化的一点。

Lenny: 我正在读 Kevin Kelly 的新书,不知道你有没有看过。书里全是各种小建议,其中一条就是:通常做某件事最好的时间就是现在。这感觉和你们思考问题的方式很契合。我很好奇,你们是如何创造出这种快速决策的文化和能力的?纯粹是自上而下由创始人塑造的行为模式,还是有其他你觉得有效的方式来建立这种快速行动、快速决策的文化?

Jeremy Henrickson: 显然,很大一部分原因在于 Parker 本人。这是他性格中的一个特质,他喜欢快速做决策,同时这也是他一个刻意的战略选择——要让这家公司成为一个快速决策的公司。所以他不断以身作则,对吧?在 Slack 里、在面对面交流中、在一切可能的方式中。整个公司都有一个期望——如果你去看我们的领导力原则(leadership principles),这种快速决策的能力是每个人都身体力行的。但除此之外,我认为我们还做了很多事情把它融入到了工作方式中,比如我们做季度规划的方式。我们的决策时间线没有给拖沓留下太多空间,而且我们期望人们——尤其是产品方面的人——对自己的领域了如指掌,对吧?

在产品部门,你不是负责某个小功能,你负责的是一个产品,而且你被期望成为这个产品的全球顶尖专家。如果你确实做到了,那就意味着你不必花三天时间回来找人才给出答案,你可以脱口而出:“是的,我认为应该这样做”,或者”给我 30 分钟查一下,我就能告诉你我们需要怎么做。“所以所有这些因素叠加在一起,就形成了一个决策速度极快的环境。

Lenny: 你提到了季度规划,你说有一个时间线,规定在这些日期之前必须做出决策,而且有一种文化就是——我们坚守这个时间线,如果你没赶上,那我们就继续往前走了。

Jeremy Henrickson: 没错。对还没适应这里的人来说,当我们真的继续往前走的时候,他们会感到震惊。就是——不,不,那个日期已经过了。你不能事后让所有人都来应对你行动不够快这个事实,对吧?这不是什么敌意的事情,只是大家需要适应。这是一个深层的组织文化原则。而所有人都站在它身后这一事实,意味着它会靠自身的引力不断被强化。

Lenny: 你们有没有整理过内部价值观?这是你们觉得很有价值的东西吗?

Jeremy Henrickson: 有的,事实上我觉得它们非常有价值。实际上我们的 COO Matt MacInnis——他在我加入之前大约一年加入了公司——他一直是推动这件事的人。你可以去——我不记得具体的 URL 了——在 Rippling 上搜索”Rippling leadership principles”就能找到。它们确实真实反映了这家公司的文化。我们制定这些原则的方式是,几年前我们进行了一次内省,去审视到底是什么让一些人在这家公司取得了成功:谁成功了,为什么成功,为什么他们喜欢在这里?或者反过来看,为什么有些人不合适,为什么有些人不喜欢这里?那些真正产生差异的东西,就是我们写下来的东西。

如何让公司跑得更快

Lenny: 对于一个正在听节目、心想”我们需要跑得更快”的人——每个人总会有这种感觉,我们需要跑得更快,决策更快——你会给他们什么建议,帮助他们在自己的公司实现这一点?

Jeremy Henrickson: 我觉得这非常取决于具体情境,但我认为首先要从那个负责顶层产品决策的人开始——他需要对哪些是优先事项做到极其清晰,更重要的是,对所有不是优先事项的事情也做到极其清晰,对吧?有太多事情可以被说成是重要的,或者人们可以为它们的重要性找到理由,但它们从根本上是在分散注意力,偏离了完成核心任务的目标。

其次,这个人需要一追到底。我们的领导力原则中有一条叫”去看”(go and see)。就是亲自去看那个东西,然后一路追到最底层,和写那行代码的工程师交谈。因为不可避免地,仅靠顶层沟通是不足以传达什么重要、什么不重要的细节的。你不需要在每个地方都这样做,但如果你在足够多的地方这样做了,它的效果就是创造出一种清晰的期望——那种全面的清晰度——并推动每个人都提高一点标准,帮助人们理解期望是什么,对吧?我认为,如果缺少了这种清晰的期望,人们很难发挥出最佳水平。所以我们尽量频繁地这样做。

“去看”原则的由来

Lenny: 好的,我确实想在这个话题上多花点时间,但在此之前——关于”去看”(go and see),我很喜欢这条原则。最近这在好几档播客里都被提到了,就是人们持续提问、一路追到最深处的那些可能性到底有多重要。最近一个例子是 IO 谈到做现金卡的时候,亲自跑到工厂去,看卡片是怎么印出来的,类似这样的事情。

Jeremy Henrickson: 对。

Lenny: 首先,你是否知道这个原则最初是从哪里来的,为什么它对你们来说变得如此重要?其次,有没有一个例子,是你自己这样做,或者你看到别人这样做,最终带来了非常重要的成果?

Jeremy Henrickson: 在我们拓展全球业务的早期,当我们第一次试图弄清楚全球薪酬到底是什么的时候,很容易就会想说,“好吧,我们要进入英国市场,那应该和我们美国做的差不多。“但我们的薪酬负责人亲自去深入了解之后说,实际上,这些是我们知道会不一样的地方,但这些是我们没有预料到会不一样的地方。这让我们意识到,必须彻底改变我们的方法——重新思考如何了解每一个国家、如何进入这些国家,并获得真正完整的体验。

而这又反过来推动了其他事情的落地——比如,每个国家都有税务申报,每个国家做法都略有不同,那我们怎么构建一个税务申报系统,能够满足我们将在每个国家运行薪酬的需求?正是因为在最早期对一个国家的实际运作方式进行了深入审视,然后对下一个国家做了同样的事,我们才得以把所有这些事情启动起来。并不是说我们在那个阶段就知道了所有答案,但它让我们在非常早的阶段就开始推动一系列需要做的事情,这些东西随后随着时间的推移变得越来越清晰、越来越精确。

Lenny: 所以那个团队的负责人基本上就是亲自去研究了每个国家的税法——

Jeremy Henrickson: 对。

Lenny: ——各个国家的。

Jeremy Henrickson: 没错,一路追到最底层。就是,好吧,我们打开那本大厚书——当然现在都是线上了——翻开来看,或者你在美国的话,你得去看俄亥俄州或宾夕法尼亚州,它们有各种各样基于地方城市或县的税收。只要看几个这样的案例就非常有启发性,你会想,天哪,我怎么考虑配置这些税种的变化——而且这些变化是没有提前通知的?某个城市的管理者或市立法机构——不管他们叫什么——他们决定改税率。那我们怎么知道这件事?我们怎么去更新?怎么确保更改在正确的时间生效?

除非你一路追到最底层,去看这些东西实际上是怎么运作的、怎么传达的、怎么被思考的,否则你根本不会想到这些问题。我认为产品的每一个方面、在每一个维度上都是如此,对吧?它可能是一个技术层面的事,可能是设计层面的事,可能是合规、监管或政府相关的事,但无论是什么,那个细节永远存在。除非你沉下去亲眼看到它、亲自理解它,否则你并不真正理解你的产品需要做什么。

不要把这个环节委派给别人

Lenny: 我觉得这里有一个字里行间的关键信息——不要把这个环节委派给别人。你的团队里可能有税务专家,我猜很多领导者会说,去把这件事搞清楚,然后告诉我。而我觉得你说的恰恰相反——你自己亲自去,去学习,成为这方面的世界级专家。

Jeremy Henrickson: 没错,没错。你亲自去做,亲自去学,然后我们才有理由去雇那个税务专家——我们现在确实有税务专家,顺便说一下。那是我们成功中极其重要的一部分,拥有这样的专业人才,但前提是必须先有一个具备产品思维的人深入到底层去。税务专家在税务方面当然很厉害,对吧?那是他们热爱和擅长的事情,但这不意味着他们天然就是出色的产品思考者。所以那个有产品思维的人必须先深入到同样层次的细节中,才能真正理解它。

Lenny: 关于在这类事情上应该花多少时间, versus 日常的产品领导工作——要成为多个国家税务系统的世界级专家,这需要大量时间。你会给出什么指导吗?还是说,没有比这更重要的事情了,这就是你的工作,你不做这个在做什么?你怎么思考这个问题?

Jeremy Henrickson: 我觉得,如果一份工作需要八十个小时,那其中四十个小时应该花在这上面。我认为,除非你亲自深入到那个层面,否则你无法真正理解一个产品。对,这确实需要时间,你说得对,你也不能忽视工作的另一半——和工程团队沟通、写文档等等。但如果你不知道自己在说什么,写文档又有什么意义?所以我们非常看重这一点。这也是为什么我们在 Rippling 至少保持产品组织非常精简的原因。我们期望单个领导者能够了解产品的完整范围。事实上,优秀的产品领导者确实能做到这一点,因为他们天生有好奇心、有兴趣,有能力吸收大量信息。而且这也很有趣,因为现在我周围都是一群在各自领域非常出色、真正理解自己在做什么的人,那是一个相当了不起的状态。

领导者要经常做对决策

Lenny: 我看着这份原则清单,忍不住想继续追问。其中有一条原则我很喜欢——它让我想到亚马逊也有一条类似的原则,就是”领导者经常是对的”。

Jeremy Henrickson: 对。

Lenny: 为什么你觉得这条很重要?我知道这些原则不一定都是你设计的,但我猜这是你们经常遵循、经常被提起的一条。

Jeremy Henrickson: 这条是我最喜欢的原则之一,因为我认为尤其对一个产品组织来说,对吧?产品领导者必须在大多数时候做出正确的决策,因为他们的决策会反映到整个组织中,他们的决策本质上就是在消耗时间和精力。如果他们做出了好的决策,公司就会表现得很好;如果做出了糟糕的决策,公司就不会。我在产品领导者身上非常看重的品质之一,就是那些能够在信息不明确、情况模糊、信息不完整、决策空间复杂的情况下,审视这一切,倾听每个人的意见,阅读需要阅读的资料,然后说:这就是我们要去的方向。

即使其他所有人都在说,“嗯,我不知道,这感觉不对,因为这个原因、那个原因”——如果他有信心做出那个判断,然后一年后你回头看,发现他是对的,这是极其有价值的。而且这是一种真的很难测试的能力。你可以通过和人们交谈来了解,问他们,“嘿,这个人通常是对的吗?“人们会想一想,但在某个特定公司的语境下,你必须花时间去验证这些决策大体上是否正确。这也是我们所有价值观中独特的一条——它很难学会。你要么非常擅长做这类决策,要么不擅长,对吧?这是一种我们非常看重的非常特殊的能力。

全球扩张的决策

Lenny: 好的。换个话题,我知道你们正在进行全球化扩张。我们之前稍微聊过一点。

Jeremy Henrickson: 是的。

Lenny: 围绕这个方向我有几个问题,因为很多公司都是先在一个国家起步,大多数公司都是如此,然后才决定拓展到新市场。所以第一个问题是,你们如何决定要进入哪些市场?具体来说,先从哪里开始,然后如何对市场列表进行优先排序?你大概的算法是什么样的?

Jeremy Henrickson: 首先从一个前提假设出发,就是我们最终必须在所有地方都有布局。你其实不一定非要在世界上每个国家都建设原生的全球薪资系统,但这样做确实合理。但你肯定希望能够向世界上任何国家的人支付薪酬,能够在世界上任何地方雇佣承包商,并且他们的信息能出现在你的人力资源系统中。所以对我们来说做这个决定的时候,我们很幸运地——已经有相当多的客户了,数千家客户。所以我们不仅知道他们的美国员工在哪里,而且由于我们是员工系统,我们实际上知道他们在其他地方的员工在哪里。所以我们很容易就能判断——当然仅仅关注总部在美国的公司,数据并不完整——但如果我们只看总部在美国的公司,我们就知道这些客户有迫切需求要向X、Y、Z国家的人支付薪酬。我们直接按原始数字顺序列出来,然后评估,在每个国家建设的难度有多大,价值有多大?在英国、加拿大、德国或印度等地建设的战略价值是什么?然后我们讨论了风险在哪里,哪里比较困难,哪里周期很长,哪些国家需要很长时间才能获得审批之类的。我们就这么做了个堆叠排序,然后重新审视这个决定。我们早期关于具体进入哪些国家的决策,后来随着时间推移做了重新调整。随着我们深入各个国家、了解更多信息,我们对排序做了一些微调。但大体上,我们最初制定的那个基本列表现在仍然基本正确。

Lenny: 好的。另一个很多创始人都在纠结的问题是,什么时候开始国际化扩张?因为有利有弊。你有没有一种感觉,是什么让你们决定开始走向国际的?

Jeremy Henrickson: 我觉得我们的情况有点特殊,但我认为这个问题的正确答案始终是:比你认为需要的时候更早开始,比你认为不得不做的时候更早去做。因为如果你从来没做过这件事,它比你想象的要难,比你想象的更专业。英国人真的很在意 “color” 里面有没有一个 “u”,就像我们很在意没有那个 “u” 一样。这些微妙的文化差异,公司需要花很长时间才能吸收。所以我的观点是,你应该总是在比你认为自己应该做的时间更早的时候去做。在我们的情况下,这是我们一直都知道必须要做的事情。事实上,我们有一个非常清晰的论点:不全球化的公司——尤其是在薪资领域,但也包括保险、福利和IT领域——如果不全球化,十年后就无法生存下去。因为公司本来就在变得全球化,然后新冠疫情发生了,公司全球化的速度大大加快了。全球化不再是百人以上公司的专利,开始向下渗透到非常小的公司。小公司跨国经营变得司空见惯。这极大加速了我们的时间表。然后你会发现其他公司也注意到了这一点,开始尝试解决这个问题的不同部分。所以存在一个竞争维度,这在大多数方面是次要的,因为我们本来就要做这件事,但这确实也给大家添了一把火。

国际化扩张中的惊喜与教训

Lenny: 关于国际化扩张,你觉得最令人意外的是什么?对于那些可能刚开始考虑这条路、想着”糟糕,我们应该想想这件事”的人,有什么启示?

Jeremy Henrickson: 我觉得最令我意外的事情——我第一次经历这个是在 Guidewire 时期——也是每次我再做这件事时最令大多数人意外的,就是:每个国家都是独特的。你不能把美国的做法直接搬到另一个国家。其他国家会觉得这是冒犯。不管你在这里有多成功,当地人总是相信——不管对错——他们当地的情境是特殊的。你必须尊重这一点。这体现在一些细节上,比如 “color” 里有没有一个 “u”。或者如果你看到给另一个国家的人做产品演示时,详细的人员信息界面里出现了社会安全号码,你就立刻失去了信誉。不管你其他所有功能做得多好都没用。

我认为这一点始终是最让人意外的,就是这种程度有多深——虽然事后看来似乎很明显。如果有人拿一个德国系统、用翻译得很差的内容到美国来演示,我们也会觉得它很烂。但真正困难的是去适应那种思维模式。所以要在组织层面克服这个问题,需要投入大量精力。

Lenny: 非常有道理。我现在换个方向。

Jeremy Henrickson: 好的。

对框架的看法

Lenny: 框架。我知道你不算是框架的忠实粉丝。我们在录制之前聊过这个话题。所以我很好奇听听你的看法——为什么你可能不太推崇框架,以及如果你不是直接对团队说”嘿,这是你们应该用的框架”,那你是如何为团队提炼流程和概念的?

Jeremy Henrickson: 听着,我认为框架是很有帮助的。所以我不完全是反框架,但我反对用流程来替代深度的产品思考,明白吗?我倾向于只保留刚好够用的流程,来搭建一个框架,让正确的决策能够在其中发生。我认为尤其是当公司规模扩大时,会有一种危险,你最终会说,“只要我们在 Jira 里把所有东西正确分类,我们就能做出非常好的优先级决策。“我的意思是,清晰的分类当然非常有帮助,Jira 里没有的那些东西——比如数据和分析——也同样重要。但你真正需要做的是决定什么是重要该建的,然后找到一种高效的方式来构建它。所以我认为,对于任何一个给定团队来说,正确数量的流程,或者说正确的框架,实际上取决于他们所处的具体生命周期阶段。

所以你不会听到我说,“哦,我们需要用这个 Scrum 方法或者那个 Combine 方法,或者随便什么最新的新东西。“我不在乎那些。我在乎的是,什么东西能让这个团队在当前的情境下、在他们生命周期的这个节点,尽可能高效地构建正确的东西。不同的团队用不同的方式,我完全接受。我唯一在乎统一的地方有两点:一是季度规划流程,二是所有东西确实都需要放在 Jira 里,因为否则你无法真正搞清楚到底在做什么、不在做什么。

有害的流程与框架

Lenny: 有没有哪种流程或框架是你觉得适得其反、需要避开的?比如”我们在这个东西上吃了不少亏”,或者一般来说,“我们还是从头重新思考吧”。

Jeremy Henrickson: 没有,我没觉得哪一个特定框架是——我没有持续地发现某一个框架特别有问题。我认为任何框架都有它的用武之地,合适的地方、合适的时机。我认为危险在于,任何时候如果有人教条地说”我觉得我们应该用流程 X”——因为在我经验中这几乎从来不是正确答案。我认为也有一些例外情况,比如你创建公司的基础就是流程 X,所有人都认同并理解这个流程,那我觉得它可以非常非常好。在工程方面,我认为这非常有价值。比如测试驱动开发(test-driven development),第一行代码就是测试,而不是实际的功能代码。太棒了,我非常支持这一切。但在产品领域,我觉得情况不太一样。

Coinbase 与 Rippling 的产品开发差异

Lenny: 如果你必须比较 Coinbase 和 Rippling 在构建产品的流程方面、或者说产品开发方面的异同,你会说最大的区别是什么?

Jeremy Henrickson: 我认为这些差异很大程度上源于不同的领域。加密货币,正如我们之前聊到的,真的很难预测会发生什么。有太多关于加密货币未来的问题——什么会重要、我们到底需要建什么、什么能存活下来。所以在 Coinbase,我们的流程核心就是围绕这些辩论,做出决定,然后”虽然不同意但承诺执行”(disagree and commit)。然后从执行的角度来看,能够快速行动。这就是 Coinbase 的关键所在。而在这里,我们在高层面上知道自己需要构建什么。关键在于,我们如何基于我们拥有的这些出色的平台能力来实现真正的差异化?或者说我们如何演进这些平台能力,以持续构建出比市场上所有东西都断崖式领先的产品?这会催生一种不同的决策流程。所以对我来说,我的思维模型——我如何对待这些事情——其实是一样的,但它们在实际开发软件的过程中会产生不同的结果。

Lenny: 具体差异到底是什么?你在日常中感受到的是什么?是时间线上的差异?是速度上的不同?还是你组织工作的方式、你计划多远的未来?你觉得具体的差异是什么?

Jeremy Henrickson: 我认为差异在于日常决策的速度。因为在 Rippling,随便找一个团队——比如你在设备管理团队,你知道自己该做什么,对吧?没有模糊地带。你不需要争论 Mac 或者 Windows 未来会不会存在。完全没有那种认知失调。就是”我们需要构建这个东西”。困难的是搞清楚怎么构建,对吧?因为有各种不同的东西可以利用,但基本上我们就是需要把这事儿做成。

所以我觉得这里整体的速度会更高一些。这并不是说这里的人比在 Coinbase 工作更努力。Coinbase 是一个速度极快的环境,但它也受制于一个事实——你根本不知道加密货币市场会怎样,你必须对此做出极其快速的反应。所以我觉得可能这一点是——对环境的反应能力,加密货币环境的动态,以及监管环境的不确定性,所有这些东西。我们在 Coinbase 变得非常、非常、非常擅长快速处理这些事情,而在这里,我们需要处理这类情况的程度要低一些。

Coinbase 的压力与回忆

Lenny: 听起来在 Coinbase 压力挺大的。

Jeremy Henrickson: 是的,我意思是,也很有趣。是的,压力很大。我意思是,我做过的每一份工作都有压力,但每份工作的压力各有各的独特之处。但所有那些压力,我认为都是以问题的形态存在的,是在一个真正有趣的问题的语境下的。这就是为什么我一直留在了这些地方。但确实,压力很大。

Lenny: 回头看的话,会觉得是一段很愉快的经历吧。

Jeremy Henrickson: 是的。不,有很多非常好的回忆。我回头看的时候,我记得那种压力,但我不会重新体验到它,你知道吧。我记得的是建立那些关系、构建那些我有幸参与的很棒的产品。所以我对我去过的地方几乎只有美好的回忆。

Lenny: 我也有同感。你经历了那些艰难时刻,然后回头看,你会觉得”哇,那真是太酷了”。但前提是结果不错、公司做成了——

Jeremy Henrickson: 确实。

Lenny: ——你会觉得那是成功的。很多时候你在一家创业公司,生活糟糕了两年,最后没做成。虽然也有收获和好的回忆,但就没那么辉煌了。

Jeremy Henrickson: 是的,这话说得对。不过,我毕业后的第一家公司是一家叫 Reactivity 的公司,那是互联网 1.0 时代,我们在摸索这个互联网的东西到底怎么运作,如何基于这些新技术创建公司,以及如何帮助其他公司构建东西、搞清楚方向。那家公司从根本上来说没有成功,最终拆分之后被收购了,这很好,但那是一群非凡的人,我非常幸运能和他们一起工作,我很珍惜在那里度过的所有时光,它对我后来做的一切都是奠基性的。所以即使那次努力没有在传统意义上获得回报,我在那里学到的东西的价值、以及我有机会共事的人,都是真正杰出的。我觉得自己非常幸运。

Lenny: 这确实是一个很好的观点。我觉得我甚至应该纠正我刚才说的——即使事情没有成功,传统意义上讲,那些经历最终也会以各种意想不到的方式变得极其有价值。

Jeremy Henrickson: 是的,百分之百同意。

招聘产品经理

Lenny: 好,那么最后一个话题。

Jeremy Henrickson: 好的。

Lenny: 我想聊聊招聘产品经理和面试。

Jeremy Henrickson: 好。

Lenny: 这些年来你招了很多产品经理。我很好奇,关于在产品经理以及产品领导者身上应该看重什么,你有什么心得是其他人可能不够重视的?

Jeremy Henrickson: 我倒不觉得我在这方面有什么特别独到的见解。但确实有几件事我在面试中会比较强调,可能因为这是 Rippling 所以会更注重。第一件是,候选人走我们的面试流程时,有一个环节是做案例分析(case study),这个案例分析的一个重要特点是,它实际上太复杂了,候选人不可能一开始就有所有的答案。问题的空间太大了,做不到面面俱到。这就意味着在面试中——或者说在案例分析中——有很多机会可以随机提问,或者改变某个假设前提。观察人们如何应对这些变化,非常能说明他们理解新问题有多深入、理解速度有多快、以及思维有多敏捷。

面试中的提问质量

Jeremy Henrickson: 有些人在这方面极其出色——某个假设前提一变,他们眨两下眼睛,就会说:“哦,那会有这四百条连锁影响。“然后就开始一条条列出来。而有些人则会完全手足无措。显然对我们的环境来说,前者对我们真的、真的很重要。我觉得另一件对我来说非常重要的事,是人们所提问题的洞察力,这首先反映了他们对这份工作的真实兴趣。

人们在越兴奋想去一个地方工作时,往往越会做足功课,会向别人打听情况,提出的问题也就越好。而且这些问题的质量差异可以非常大。这没关系,我不指望质量始终如一。但有时候有人提出一个问题,我会觉得:“天哪,我根本想不到问这个问题。太有洞察力了。“然后我会停下来,需要想一想该怎么回答。这实际上反过来推动了我自己变得更好一点。当这种情况发生时,我就知道面前很可能是一位非常优秀的候选人。

Lenny: 有没有一个具体的例子浮现在你脑海中,某人问了一个非常好的问题,让你回想起来觉得”哇,那个问题真棒”?

Kyle Boston 的面试故事

Jeremy Henrickson: 我记得大约三年前,我在面试一位叫 Kyle Boston 的人,Kyle 现在负责我们的平台产品组织。我记不清他具体问的问题是什么了,但大概是这样的意思——“等一下,如果你有这么多产品,底下又有这个员工系统记录,那你们有没有想过如何创建这些底层平台技术的不同支柱,比如[听不清]之类的东西。“那是在我们还没有将平台的概念从员工系统记录完全正式化之前。

我记得我当时想,是的,我们应该这么做,这个想法之前也出现过,但真正让我印象深刻的是,一个几乎对公司没有任何背景了解的人能提出这样的问题。就好像,天哪,你在同时面试很多家公司的时候,花了几周时间思考 Rippling,就能如此深入地思考到我们所构建平台的本质,这立刻让我对他的思维能力产生了极大的信心,相信他能想清楚我们需要他去思考的那些问题。

产品经理需要具备商业思维

Lenny: 我觉得这触及到了一个点——产品经理需要成为商业领导者,而好的问题往往是关于业务本身、业务的未来、如何让运营更高效等等,虽然也有产品组织的层面。但我发现这是产品经理面试中一个非常被低估的要素,就是去思考更大的商业图景,而不仅仅是产品经理负责的产品本身。

Jeremy Henrickson: 对我来说是两个方面。一方面是思考更大的商业图景,有相关的背景知识,不管是收入问题还是战略问题;另一方面是对细节的追问。比如:“等一下,我被问到的这个事情——或者你 Jeremy 刚才说的那个事情——它的含义其实是所有这些东西。“他们能理解这不是一个简单的生意,这真的很难,真的非常复杂。而他们能够产生这些洞察来帮助自己理清这些细节,这真的很酷。

给产品经理的面试提示

Lenny: 你之前提到过你会给产品经理一个提示,能不能不要透露你现在实际问的是什么,但有没有一个你过去用过的提示的例子,或者你认为适合给产品经理候选人的那种提示的一个好例子?

Jeremy Henrickson: 从总体方法来说,我认为提示应该始终反映他们即将加入的实际业务。所以我们的整体流程其实相当短。基本上就是通过某种方式联系上我们,最终和招聘经理对接上,和他聊一次。然后基本上就是和我进行一次对话,是一次产品讨论。之后是一个案例分析,紧跟在那之后。这就是全部流程了,加上边缘的一些其他对话。真正重要的是,人们如何思考那个与我们的业务相关的产品讨论,以及如何思考那个案例分析。这是第一点。第二点是,我的面试中始终有一部分,听起来可能非常简单,就是:“嘿,你有什么问题想问我吗?”

实际上我们是在进行产品讨论之前就做这一步。这是一个极其重要的问题,因为它再次反映了人们思考了什么、没有思考什么、思考的深度如何、以及对这个角色的投入和兴趣程度。在第二阶段,不要求完美,但当人们——无论是事先准备了一组想问的问题,还是临场发挥——你都能从这些问题中了解到很多:人们如何看待产品,他们在寻找什么,他们喜欢做什么、不喜欢做什么。

给早期职业产品经理的建议

Lenny: 对于那些可能正处于职业早期的产品经理听众,你会给他们什么建议来帮助他们在职业早期加速成长?

Jeremy Henrickson: 保持谦逊。做一个产品人意味着,你身处的是一个没有人知道正确答案的世界——因为如果有人知道,他们早就已经做出来了。所以无论你多聪明,外面总有很聪明的人。总有你不知道的东西,总有别人会知道你不知道的事情。只有承认这一点,你才能真正保持谦逊,说出”我愿意接受所有这些我不知道的东西”,并愿意去综合这些信息,得出不同的结论。

所以我发现这种谦逊是早期职业领导者之间最大的区分因素之一——那些能够放下自己在学校或第一份工作中有多厉害的人。我自己也经历过这个过程,要认识到这份工作永远很难,这份工作每一天都是关于发现。如果你能保持那种好奇心、思维的弹性、创造力,并且让解决问题的思路保持开放,那会非常棒。但如果你把自己封闭起来,认为自己总是有正确答案,那就没有希望了。

优秀的领导者经常改变想法

Lenny: 这让我想到了另一条原则,我屏幕上还挂着——“优秀的领导者经常改变想法”,或者就是”改变想法”。

Jeremy Henrickson: 对。愿意看到新信息后说,我的心智模型因此调整了,或者很简单地承认”我错了”。我觉得同样重要的是,你要处在一个允许你说自己错了的环境中,对吧?每个人都会犯错。虽然要对的时候比对的时候多,但每个人都会犯错,对吧?能够处在一个你可以说”是的,我错了,我错的方式是这样的,我们继续往前走”的环境中,这是极其有力量的。

与产品型创始人共事

Lenny: 最后一个问题。你多次提到 Parker,他身上很清楚的一点是,他是一个非常有产品思维的创始人。他对产品应该是什么样有很多强烈的观点。作为一个产品领导者,面对这样的创始人,往往是一个充满挑战的位置,类似于在创业公司做第一个产品经理,而创始人对产品有强烈的主见。所以我的问题就是,你从与一位对产品应该是什么有非常强烈观点的创始人合作中,学到了什么关于做好产品领导者的经验?

Jeremy Henrickson: 好问题。我觉得你需要具备适应性,对吧?就像任何其他关系一样。你要理解这段关系的本质是什么,对方在意什么,你在意什么,你们以什么方式相互挑战。我认为根本前提是,你要确保那个人是愿意接受挑战的。我见过一些产品负责人或 CEO,他们不太愿意被挑战,我没办法跟那样的人合作。

Parker 确实观点非常强烈,但他也极其博学,这让我们的讨论非常精彩。而且我发现,不管是什么——甚至不只是 CEO,不管一个管理者有什么样的个人特质,你都要找到与之合作的方式。我觉得这种适应性……我把自己看作一块可塑的拼图,能够嵌入各种形状。我认为这其实是我的一项核心能力。所以我和 Parker 之间配合得很好,在我们之间建立起深厚的信任基础之前,这一点非常重要,而要建立这种关系,深厚的尊重是极其关键的。这些年我们的尊重越来越深,我们并不总是意见一致,但我们可以就此展开完全理性的讨论,这正是其中的乐趣所在。

Lenny: 适应性其实——我曾经做过一次优势识别测试,那是我排名第一的优势。我觉得我们在这一点上是共通的。

Jeremy Henrickson: 太好了。

Lenny: 嗯,看来这确实是身处这个位置的一个重要特质。好了,接下来进入我们非常激动人心的闪电问答环节。我准备了六个问题,准备好了吗?

Jeremy Henrickson: 好,准备好了,放马过来。

闪电问答

Lenny: 开始了。你向别人推荐最多的两三本书是什么?

Jeremy Henrickson: 首先是史上我最喜欢的系列小说——Neal Stephenson 的《Baroque Cycle》。它是一部九卷本史诗,或者说是三卷本、九册的史诗,取决于你怎么算。它讲的是启蒙运动前夕到启蒙运动初期那段时期的故事,是历史小说,非常有趣。另外我也很喜欢 Iain Banks 的《Culture》系列,那是一个超级有趣的遥远未来宇宙,我非常喜欢。

Lenny: 最近最喜欢的电影或电视剧是什么?

Jeremy Henrickson: 看了《The Last of Us》,我是那个游戏的忠实粉丝,觉得他们改编得非常好。最喜欢的电影嘛,算是比较近的吧,其实也没那么近——我很喜欢《Tenet》,我对他们敢去拍这样一部电影的能力印象深刻,从头到尾都非常享受。

Lenny: 这游戏算是结束了,但我们之前有个喝酒游戏,只要有人提到《The Last of Us》就得喝,之前它已经取代了《White Lotus》。我现在就喝口茶。

Jeremy Henrickson: 好的,没问题。我尽量吧。我平时喝茶,但今天只有水。

Lenny: 也行。不过有意思的是,这个话题出现得不多,所以我们先这样吧,看看会不会形成新的规律。然后《Tenet》感觉就像——我刚才在想,它就像一部”复合”电影,就像复合创业公司拍成电影一样,一部电影也非常复杂——

Jeremy Henrickson: 对,所以我才喜欢。我喜欢在电影进行的过程中在脑子里梳理多条时间线的图谱。

Lenny: 你心里的那块拼图在试图找到所有的拼图碎片。

Jeremy Henrickson: 没错。

Lenny: 你最喜欢问的面试问题是什么?你之前可能已经回答过这个问题了,还有什么别的吗?

Jeremy Henrickson: 我觉得我确实回答过了。不,我最喜欢的问题就是”你有什么问题想问我吗”,毫无疑问。

Lenny: 很好。你最近发现并喜欢的产品有哪些?

Jeremy Henrickson: 我提两个吧,不知道能不能算”最喜欢的产品”,但有两个印象比较深。前几天我太太的电脑坏了,我发现是 CPU 散热器坏了,而 Corsair H60 CPU 散热器非常容易安装,而且兼容很多种主板,我觉得非常棒。另一个就是我现在耳朵上戴的这个。我之前买的第一副好耳机上周坏了,不得不赶紧做了些研究,找到了我现在最喜欢的新耳机。这副 Focal Bathys 非常出色。我算是个音频发烧友,喜欢听古典音乐和环境音乐,所以需要很大的动态范围和降噪功能,这副耳机目前表现非常好。

Lenny: 它们叫什么名字?

Jeremy Henrickson: Focal,好像是 Bathys,B-A-T-H-Y-S。

Lenny: 有具体的型号吗,还是就那一种?

Jeremy Henrickson: 就那一种。

Lenny: 好的。

Jeremy Henrickson: 你看到就知道了。

Lenny: 好,我们会在节目笔记里放链接,说不定我也买一副。有没有什么你在做产品方式上做过的相对较小的改变,但对团队执行力的提升产生了很大影响?

Jeremy Henrickson: 最近在 Rippling 的一个创新,大概是引入了我所说的”imperatives”(要务)。这些东西不管是自下而上还是自上而下产生的,都是整个产品和工程团队所有人需要做的事情。而同样重要的是,那份清单上没有放进去的东西。在一个我们可能同时选择做上百件事情的环境里,能够对那个清单进行强制排序、划一条线,说”这些是每个人都必须做的”,这给我们带来了比以前更多的聚焦和清晰度。

Lenny: 所以 imperatives 本质上就是比如未来一个季度或半年的优先事项,对吗?

Jeremy Henrickson: 这是所有人的优先事项,然后你要把它整合进你自己团队的优先级里。每个团队仍然在制定自己的优先级,但他们必须把这组事项纳入考量。

Lenny: 你们通常有多少个?这个方法很棒,我喜欢这个建议。

Jeremy Henrickson: 取决于你在什么粒度上讨论,大概十个吧,不少。我们正在推进全球化、平台大规模改进以及一系列其他大型项目。所有这些都产生了许多必须跨团队同步推进的事项。我觉得这是公司发展过程中很自然的一个阶段,而我们正好处于这个周期中。

Lenny: 太棒了。

Jeremy Henrickson: 这个方法效果不错。

Lenny: 最后一个问题:有什么我应该问你但没问的问题?

Jeremy Henrickson: 大概是,我和孩子们做什么吧?我有两个孩子,一个九岁一个——

Lenny: 你和孩子们做什么?

Jeremy Henrickson: 一个六岁。我和孩子们做什么?我是个桌游爱好者,虽然我没有刻意推他,但我儿子可以从早到晚玩桌游。所以我们经常一起玩欧洲策略桌游。我女儿现在也到年纪了,也开始感兴趣了。我们一家刚玩完《Pandemic Legacy》,明晚的奖励是我们开始玩《Gloomhaven》,会很开心。

Lenny: 这两个游戏我都不了解,听起来都很难很复杂。

Jeremy Henrickson: 很好玩,很好玩。

结语

Lenny: 太棒了。Jeremy,我们今天聊了很多话题,感觉这是一期复合播客(compound podcast)节目。非常感谢你抽出时间,感谢你的到来。最后两个问题:正在找工作的听众如果在网上看到你的信息想联系你、了解更多,应该去哪里找?听众怎样能帮到你?

Jeremy Henrickson: 好的。LinkedIn 是最方便的在线联系方式。如果今天我聊的内容让你感兴趣,我们确实在招聘资深的、有创业精神的产品经理。所以如果我们网站上那些领导力原则(leadership principles)看起来让你感兴趣,我很期待听到你的消息。

Lenny: 了解这些职位并申请的最佳方式是什么?

Jeremy Henrickson: 网站是目前最好的渠道。信息会直接送到对应的招聘人员手上,他们会立刻告诉我。

Lenny: 好的,rippling.com,应该也有一个招聘页面。

Jeremy Henrickson: 上面有招聘网站,很容易找到。

Lenny: 好的,链接会放在节目备注里。Jeremy,再次感谢你的到来。

Jeremy Henrickson: 非常感谢邀请,这次很开心。

Lenny: 大家好,非常感谢收听。如果你觉得这期节目有价值,可以在 Apple Podcast、Spotify 或你喜欢的播客应用上订阅。也请考虑给我们评分或留下评论,这真的能帮助其他听众找到这档节目。你可以在 lennyspodcast.com 找到所有往期节目或了解更多关于节目的信息。下期再见。

术语表

原文中文
case study案例分析(case study)
Coinbase保留原文
component library组件库
compound startup复合创业公司(compound startup)
disagree and commit”虽然不同意但承诺执行”(disagree and commit)
dogfood内部试用(dogfood)
DRI直接负责人(DRI)
Dunbar’s number邓巴数(Dunbar’s number)
Ethereum以太坊
go and see”去看”(go and see)
imperatives要务(imperatives)
Jeremy Henrickson保留原文
Kevin Kelly凯文·凯利
Kyle Boston保留原文
leadership principles领导力原则(leadership principles)
Matt MacInnis保留原文
MVP最小可行产品(MVP)
Parker保留原文
Reactivity保留原文
Rippling保留原文
Sachit保留原文
system of record系统记录(system of record)
test-driven development测试驱动开发(test-driven development)
time and attendance product考勤和工时管理产品
zero-to-one从零到一

此文档由 AI 分片翻译(translate_long_document)