构建卓越文化 | David Singleton（Stripe CTO）

David Singleton 2023-05-04

构建卓越文化 | David Singleton（Stripe CTO）

访谈记录

David Singleton： 我们在 Stripe 思考产品开发的方式，核心是要找到合适的早期用户群体，与他们共同创造产品。最好的例子可能是 Stripe Billing。当我们开始做 Stripe Billing 产品时，我们发现一些现有用户——比如 Figma 和 Slack——已经在用 Stripe 处理支付，但它们采用的是订阅制的商业模式。我们判断未来会有越来越多这类公司出现，而且可以明显看到，它们正在不断突破这一领域的可能性边界。

所以我们决定与他们共同创造产品。我们建立了共享的 Slack 频道，非常频繁地向他们展示产品进展，收集反馈。只有当最初的 Alpha 用户群体对产品非常、非常满意之后，我们才会考虑将其推向更广泛的用户群。这就是我们在 Stripe 构建产品的方式。这也意味着，在 Stripe 构建产品的每位工程师，实际上都具备并会运用你在其他公司通常在产品经理（PM）身上才能看到的许多特质。

嘉宾介绍

Lenny： 欢迎收听 Lenny 的播客，我在这里采访世界级的产品领导和增长专家，从他们打造和增长当今最成功产品的宝贵经验中学习。今天的嘉宾是 David Singleton。David 是 Stripe 的首席技术官，负责领导其工程和设计团队，担任这一角色已超过五年。在加入 Stripe 之前，David 是 Google 的工程副总裁，在那里工作了十余年。在与 David 的交谈中，你会很快感受到他对打造卓越产品和卓越团队这门手艺的热忱。我们深入探讨了 Stripe 独特的招聘方式，他们如何打造了一支极具产品导向的工程团队——这使他们在很多年里都不需要招聘第一位产品经理；他们如何将”在工艺上精益求精”（be meticulous in your craft）这一运营原则落地执行，包括许多引人入胜的内部流程，比如工程师演讲（engineer occasions）、走访一线（walking the store），以及一种叫做摩擦日志（friction logging）的实践。David 还分享了在 Stripe 的可用性和规模要求下运行工程文化所需的一切，以及 AI 已经如何影响他们的工作方式，还有关于领导力、管理和规划方面的经验教训。非常感谢 David 抽出时间来做这期播客，我相信你一定能从中收获有价值的东西。那么，接下来为您带来 David Singleton。

Stripe Sessions 大会

Lenny： David，欢迎来到播客。

David Singleton： 谢谢邀请，Lenny。很高兴来到这里。

Lenny： 我知道 Stripe Sessions 大会马上就要到了，就在下周，我想你这段时间肯定特别忙。所以更加感谢你在百忙之中抽出时间来。

David Singleton： 谢谢。这是我的荣幸，也很有趣。Stripe Sessions 是我们的年度用户大会，我们会邀请许多在 Stripe 上构建业务的企业齐聚一堂，这既是一个分享我们过去一年在做什么的好机会，也能从他们那里学到很多关于他们希望我们做什么。我觉得这非常令人振奋。当然，筹备工作确实很繁重，尤其是今天，我正在花不少时间准备一些演示——我很喜欢搭建演示。所以今天真的很高兴能来参加你的节目。

Stripe 的人才吸引力

Lenny： 在准备这次对话的过程中，我意识到 Stripe 的校友在这个播客上表现非常抢眼——无论是来自 Stripe 的嘉宾数量，还是那些节目的质量和受欢迎程度。比如 Claire Hughes Johnson、Shreyas Doshi 和 Eeke。我的第一个问题本质上就是：你们到底做了什么，才能吸引、招聘、拿下并留住这个级别的人才？我不会接受”我们坚持高标准”或”我们只是花很多时间在招聘上”这样的答案。我好奇的是，你们做了哪些其他公司没有做的事情——也许是 Stripe 在发现和招聘人才方面独特的地方？

Stripe 的核心理念与使命

David Singleton： 好的，我很乐意跟你多聊聊我们如何发现和招聘人才。不过我觉得有必要先退一步讲讲大背景，因为这对后面的话题很重要。想一想 Stripe 在做什么——我们的核心论点是：互联网经济在未来将比今天大得多、重要得多。过去十年的发展确实印证了这一点。所以我们本质上是一家充满了具有产品思维的构建者的公司，致力于让企业在这个大背景下更容易地起步和运营。我们最初从构建信用卡支付 API 起步。在 Stripe 出现之前，在线接受信用卡支付实在太困难了——你得去跟银行谈，可能还得跟 Visa、MasterCard 签合同，然后还得把一大堆非常复杂的基础设施拼接在一起，这又给你的业务施加了各种限制和要求。

从支付痛点到 Stripe 的诞生

David Singleton： John 和 Patrick 在之前的一次创业中，其实讲过一个很有趣的故事：他们在做那家公司的时候——那是一家互联网公司——他们原以为最难的部分会是在数据中心里组装硬件。但因为那时 AWS 之类的服务已经出现了，那部分其实相当简单。然而，当那家公司需要接入在线支付的时候，难度丝毫不亚于他们原本预期组装硬件的程度。他们实际上还得部署一些物理硬件，还得建立一大堆合作关系，而且作为一个初创团队——一群还没有什么声誉的人——要被认真对待、要能接入那个体系，真的非常困难。这就是 Stripe 诞生的灵感来源。所以我们一开始解决的就是一个非常重大而深刻的问题，帮助这些企业起步和扩张，并且在早期就明确采取了以开发者为中心的方式。

以用户为中心的扩张逻辑

我觉得接下来值得了解、也很重要的一点是，随着我们的规模扩大，我们真正找到下一步该做什么的方法，就是非常密切地关注我们的用户——那些在 Stripe 上构建业务的企业。他们从现有产品中获得了什么？在我们已经解决的问题旁边，还有哪些问题让他们不得不投入大量精力，但他们真心觉得不应该自己来解决、希望我们能帮忙？当我们发现这种需求与我们已有工作的相邻性发生交汇的时候，通常就是我们构建下一层经济基础设施的契机。所以我们今天把自己做的事情理解为：为互联网乃至更广阔的范围构建经济基础设施。

使命如何吸引对的人才

回到如何吸引对的人才以及为什么这很重要这个问题——首先，很多人，我想大多数人来到 Stripe，是因为他们看到了一个帮助规模化企业的巨大机会。所以归根结底是参与一项有意义的使命，而且被这样一种理念所驱动：我们花大量时间与用户在一起，与那些真正需要我们帮助的人在一起，并以他们为导向。我认为这种心态吸引了一种特定类型的人——想要承担很大自主权的人，想要深入理解问题并提出自己的解决方案的人。因为我们构建的是基础设施，我们的方式是真心认为最好的工作是在幕后默默完成的。我们不需要出去搞那些声势浩大的发布会，而是希望我们所有的用户能这样做，我们则在幕后安静地工作，让他们的业务随时间推移变得更好、更高效。

我认为这会吸引具有某种心态的人——对挖掘那些可能不那么显而易见、也不那么吸引所有人的困难问题充满兴趣和韧性，然后真正埋头苦干，直到取得巨大进展。所以这会吸引长期主义的思考者，关心构建的人，以及真正希望紧密协作的人。所以当我思考 Stripe 与其他公司的不同之处时，核心就在于这种目标的单一性。我们的使命是提升互联网的 GDP，并构建相应的金融基础设施来实现这个目标，而完成这一切需要大量的团队协作与合作。这会吸引一种特定类型的人。在寻找这些人的时候，我们不会隐瞒这些。你必须在意这些，我认为才能对在 Stripe 工作感到兴奋。

招聘中的耐心与个人化

所以我们在引进人才时非常努力地把这一点表达得非常清楚。为此，我们在招聘时往往非常有耐心。特别是对于关键岗位，尤其是领导层招聘，我们很乐意花时间，去见几十甚至上百个人。有时候我们会遇到一个人，觉得他非常适合某个岗位，但他目前没法加入。那我们就会耐心等待，继续跟他保持个人关系，往往到了某个时间点，他加入就水到渠成了。而要做到这一点，还有一个特点是 Stripe 的招聘是一件非常个人化的事情。你看，很多其他公司的招聘就像一台机器。顺便说一下，我们也有一个很棒的招聘团队，但公司其他部门的人会与招聘团队非常紧密地合作。

所以这不是一台交付新员工的机器，然后你想着”哦，这个人来了，我可以把他安排去做那件事”。我们的管理者会花大量时间去精确识别各个岗位到底需要什么，然后去了解潜在的候选人——世界上能做这些工作的人——并且与他们深入交流，为什么在这里他们可能会觉得：第一，能在这个使命中获得很强的个人成就感；第二，与他们在其他地方能投入时间和精力的事情相比，这里代表着更大的机会。说到这一点，我认为 Stripe 对于很多加入的人确实提供了——我也很在意在文化中保持这一点——那就是巨大的学习机会。

学习机会与文化

今天在 Stripe 的很多人，做的与当初加入时完全不同的工作。要做到这一点，他们往往需要学习大量新东西，向新的领域拓展自己。而且想想我们正在构建的那套金融基础设施——这个领域确实奖赏那些愿意深入学习这些系统运作细节的人，这些系统在更广泛的世界里并不那么广为人知或被充分理解，需要消化大量的上下文知识。而这样做之后，你就能构建出更好的东西。你把这些上下文知识与彼此分享，帮助其他人学习。所以我认为这一切都汇聚成了你提到的那群人。你提到的每一位都是很棒的在 Stripe 或曾经在 Stripe 工作过的人，大家共同服务于我们的用户。

Lenny： 我总是很喜欢听各家公司内部怎么称呼自己的员工。所以叫 Stripes，记下了。

David Singleton： 没错。

Lenny： 所以总结一下你刚才分享的——我一边听一边在记——就是那些帮助 Stripe 打造这支不可思议的团队的关键要素：一个强大的使命，一个能吸引顶尖人才的使命。听到这里的人可能会说”是啊，你说得倒好听”，但根据我的经验——我投资了不少公司，也跟很多创始人合作过——当公司没有一个让人们真正关心的使命时，招聘有多难，与拥有一个真正有意义的使命时相比，差距是巨大的。这种力量确实非常强大，我完全能理解为什么效果这么好。然后你提到的其他要素：耐心，招聘经理与候选人之间的个人联系。我在 Twitter 上也看到了，很多产品经理就是那样做事——基本上就像在 Twitter 上经营一个小创业公司一样，比如 Jeff Weinstein——

David Singleton： 对，所以——

Lenny： Atlas。

David Singleton： Jeff 是我们 Atlas 产品的产品经理，他是一个很好的例子——他非常在乎去弄清楚这个世界到底是怎么运转的。比如说，他和团队最近推动的一件事就是认识到，在美国创办新企业时，最令人沮丧的步骤之一就是必须向国税局（IRS）申请雇主识别号（Employer Identification Number）。这个申请以前积压非常严重，而且非常困难。在拿到这个号码之前，你无法开始经营你的业务。

Jeff 深入研究了细节，团队也深入研究了细节，就是不断地追问：一定要这样吗？一定要这样吗？最终我们与 IRS 合作，使得我们能够以快得多的速度发放这些号码——基本上在你注册的瞬间就能拿到。我认为这恰好是一个绝佳的例子，说明保持好奇心、怀揣为用户解决问题的执着热情，然后持续不断地攻克难题，就能带来出色的成果，而且是在一个你可以从彼此身上学到很多东西的环境中。

Lenny： 我希望他因此获得了大幅晋升，因为他让 IRS 做了他需要的事情。这太不可思议了。我想再就招聘这个话题深入一层，然后再转向另一个话题。

David Singleton： 好的。

Lenny： 面试流程大概是什么样的？我不太清楚你在产品经理招聘流程中参与程度如何，但我很好奇高层面上是什么样的，以及工程师招聘流程，你能分享多少就分享多少。

结构化面试与贴近真实工作的考察方式

David Singleton： Stripe 所有岗位的招聘都有几个非常共同的特点，尤其是工程师和产品经理。其中一点是，我们有结构化的面试流程。我们让每个人都经历一个非常一致的流程——在帮助候选人了解他们为什么可能想来这里时，这非常个性化。但我们评估人才的方式是一致的。我认为这很重要，因为这意味着，作为面试官、作为招聘经理，你才能真正开始理解你可能得到的回答的广泛范围，以及当你问相似的问题时，你能从各个候选人身上了解到什么。这些流程的另一个共同点是，没有任何刁钻的问题。我们努力把人放在一个尽可能接近实际工作的环境中。

比如说，对于工程师，我们有几道不同的编程练习题。他们与面试官共享屏幕。这实际上类似于结对编程——欢迎使用 Google 搜索、Stack Overflow 搜索答案。我们不在乎这些。我们只关注结果。我们很乐意你在过程中向面试官提问。我们设计的这些练习尽可能地接近 Stripe 需要解决的真实问题。产品经理那边也是如此。比如我们让产品经理做的一项是书面练习，我们显然有各种不同的问题，我们发现这对于真正观察一个人如何攻克一个他们在工作中将要解决的真实问题非常有价值，以及他们是否会以一种充满好奇心、深入细节、与面试官协作的方式来完成。这就是核心要点。结构化、一致的流程。然后是尽可能接近真实工作的问题。

Lenny： 产品经理那边的问题，是让他们在家做还是在办公室做？

David Singleton： 各种形式都有。目前 Stripe 很大程度上处于混合办公模式，所以我们的很多面试仍然通过 Zoom 进行，不过我们的办公室里也有大量活跃的活动。书面练习通常是在你自己的时间里完成的。我们建议设定一个时间上限，这样不会对你的日常生活造成不合理的负担。其他练习则是与面试官在 Zoom 上一起完成。

Stripe 的产品型工程师文化

Lenny： 好的。说到 Stripe 的产品经理，Stripe 有一点很有名，或者说有点”臭名昭著”——你们等了很长时间才招聘第一位产品经理。据我了解，大概是在第 200 名员工、大约五年的时候。这在我看来说明你们非常擅长培养具有产品思维的工程师，或者说招聘和建设一种具有产品思维的工程师文化。你们是怎么做到的？你们是如何着手做这件事的？另外我也很好奇，产品经理最终带来了什么，以及他们现在是如何协作的。

David Singleton： 是的，如今的 Stripe 拥有大量的产品经理、大量的工程师，产品经理是一个极其有价值且重要的职能方向。我接下来会更多地谈谈大家现在在做什么。我们最初的团队确实是一个工程团队，不过我们招聘第一位产品经理的时间比你说的要稍微早一点。但他们都极具产品思维。坦率地说，在我密切合作过的、长期了解的所有早期团队成员中，每一个人都同样可以成为、实际上也在扮演着产品经理的角色。如果你回想 Stripe 第一款产品的性质——我们如今为从小型到大型企业解决广泛的金融基础设施问题，但最初的产品是非常面向开发者的，而且我们在许多工作中至今仍以开发者为核心。

面向开发者的产品，最好的产品经理通常是非常技术型的。他们大多是前工程师，或者可能现在还在业余时间鼓捣代码，但同时又为问题带来了大量的用户洞察和战略思考。Stripe 早期团队的每一个成员都必须像这样行事，才能按照我们的方式和我们期望的方式工作。再次提醒，那就是要非常深入地了解我们的用户，然后将这些亲身洞察带入我们的产品开发闭环中。事实上，我们在 Stripe 思考产品开发的方式，就是找到正确的早期用户群体来与他们共同创造产品。也许最好的例子，或者至少一个很好的例子，就是 Stripe Billing——我们的订阅和发票解决方案。

当我们开始做 Stripe Billing 产品时，我们意识到现有用户中有不少这样的公司——比如 Figma 和 Slack。他们已经在用 Stripe 做支付，但有订阅制的商业模式，我们判断未来会有更多这类公司出现，而且我们可以看到他们确实在把这个领域的可能性推向边界。所以我们决定与他们共同创造这个产品。负责 Billing 的早期团队找了一批这样的公司，包括 Slack 和 Figma，但还有更多，去深入了解他们。那些在这些公司中运营这些系统的个人，团队亲自了解了他们的挑战以及对未来的期望和愿景，然后将他们纳入了一种共享的产品开发闭环。

所以我们建立了共享的 Slack 频道，我们非常频繁地向他们展示产品，获取他们的反馈。只有当最初的这个 Alpha 群体对产品超级、超级满意时，我们才会认为它可能准备好面向更广泛的用户了。这就是我们在 Stripe 构建产品的方式。这意味着在 Stripe 构建产品的每一个工程师，实际上都具备、并且会运用你在其他公司通常在产品经理身上才能找到的许多特质。

产品经理的枢纽角色

不过，这并不意味着产品经理在这里没有真正重要的工作要做。关于 Stripe 还有一点值得了解，也算是有些独特的，那就是在 Stripe，构建产品更像是一项跨职能的团队运动。常见的职能大多数公司都有——工程师、工程经理、产品经理、设计师——这些人都会贯穿整个产品开发生命周期全程参与。但此外，如果你想一想我们产品的本质，就会发现我们的很多产品其实是在对整个金融体系的运作进行抽象。

比如，某个国家有某种能力，另一个国家又有不同的能力，我们希望让它们都能一致地运作。这时我们的金融合作伙伴关系就很重要了。所以有时候，我们合作伙伴团队的同事也会参与到产品的早期开发阶段。同样地，当你考虑到产品法律以及风险、合规等许多其他职能时，我们实际上需要他们的创造性思维，才能为用户构建出正确的东西。所以关键是，这是一个比我见过的大多数公司都更加跨职能协作的过程。而产品经理在其中扮演着绝对的枢纽角色。产品经理非常频繁地承担起那种协调各方、凝聚合作的工作。他们也常常负责综合我们从用户那里学到的信息。

并非所有岗位的人都在与用户对话，但产品经理很可能是与用户交流最多的人，也大概是综合提炼做得最好的人。他们通常也带来大量的产品战略——我们今天在做这件事，但它如何与更大的目标衔接，因此我们如何做出正确的选择，确保走在正确的长期路径上。所以这是一个超级重要且有价值的角色。我是说，你刚才在通话中已经提到了几位优秀的产品经理，我认为 Stripe 的产品经理们体现了我在前面谈到的许多文化和运营原则，他们为我们所完成的工作做出了巨大贡献。

在工艺上精益求精

Lenny： 完美的过渡，正好引出我接下来要问的问题——你们的运营原则之一是”在工艺上精益求精”。我知道这是你非常重视的事情。我好奇的是，这听起来当然很好，每个人都希望这能成为自己工作的重点和核心价值观。但总会有一个权衡——我们总得尽快发布产品。我们怎么等到它完美呢？所以我想先问的是，你们是如何将这条原则落地执行的？然后我还有几个后续问题。

David Singleton： 很好的问题。在我谈这条运营原则之前，让我先交代一点背景——

Lenny： 好的。

David Singleton： 我们的运营原则到底是什么。Stripe 有运营原则，它们有点像企业价值观，但又不只是价值观——它们比价值观具体得多，远没有那么抽象。实际上，我们刚才在谈论 Stripe 早期团队。我认为他们做的最好的事情之一——当然他们做了很多了不起的事，找到了早期的产品市场契合——但最有远见的事情之一，就是稍微绕了个弯，思考了一下：我们迄今为止的工作方式中，有哪些我们认为促成了我们的成功，并且在我们继续扩张时依然重要。我们把这些提炼成了一套运营原则，所以——随着规模的扩大，我们把那些从最优秀的 Stripes 身上提炼出来的行为方式形成了一套运营原则。我们非常重视它们。我们在内部经常讨论运营原则。我经常看到 Stripes 在庆祝彼此的工作时，会用哪条运营原则得到了最好的体现来表述。我们的很多反馈流程也围绕运营原则来设计，虽然不全是。顺便说一下，我们的第一条运营原则是”用户至上”。所以在这次通话中，我们已经触及了不少关于如何将用户置于核心、理解我们到底应该做什么的内容。那种与用户建立深厚的个人关系来指导一切的信念，正是源自这条运营原则，也被它所概括。我们的运营原则还分为几个类别：我们如何工作、我们是谁，以及领导者必须执行的若干条。

比如，“我们如何工作”类的另一个例子是”带着紧迫感和专注行动”。我们深信，即使我们构建的是将存在数十年的基础设施，也必须相对快速地解决用户当下的需求，这样才能真正为用户创造价值。总之，运营原则涵盖了很多方面。你问到”在工艺上精益求精”，这也是一条关于我们如何工作的原则，在 Stripe 非常重要。你也提到了一个挑战，Lenny——要做精益求精，但又有那么多事情要做，我该在哪里精益求精呢？因为如果对一切都要精益求精，很多进展可能都会陷入停滞。好吧，首先让我讲几个故事。

摩擦日志

在我加入 Stripe 之前，我花了一些时间体验产品，这也是我决定加入的重要原因之一。有一件事让我非常惊喜——当我开始集成产品时，有些地方卡住了。我在 API 集成上犯了错误，收到了错误信息，但我并没有卡很久，因为 Stripe 团队做了一件事：我们让 API 返回的错误信息直接链接到文档中告诉你如何解决问题的那个部分。

Lenny： 太妙了。

David Singleton： 这就是一个”在工艺上精益求精”的绝佳例子。这在当时是非常少见的，当然现在也很少见——把 API 的错误信息做得这么好，谁会去看呢？但事实证明，开发者在构建过程中遇到问题时，是会去看的。而且这其实是一个高风险时刻，因为这是一个关键时刻。这就是我们在产品中精益求精的一个例子。

而我们如何确定在哪里精益求精、在哪里真正打磨细节、做到超越常规，方法依然是——尽可能做到以用户为先。我们有一个在产品团队中广泛使用的流程，甚至那些为 Stripes 内部构建工具的团队也在用，叫做摩擦日志（friction logging）。它的运作方式是：你需要把自己放在一个特定用户的立场上。你需要非常清楚地知道，我此刻在为谁模拟这个摩擦体验，这一点很重要。

比如，我可能正在集成 Stripe Billing API，我可以把自己放在一位 Atlassian 工程师的立场上——Atlassian 是全球最大的 SaaS 平台之一，目前正积极使用 Stripe Billing 来自动化所有收入流程——我可能会把自己放在那个人的心态中。我可能最近刚见过他，对他做这件事的了解比其他情况下更多一些。

David Singleton： 然后我会实际走一遍使用产品的完整流程——从控制台开始，跳转到文档中我需要参考的具体页面，开始编写代码等等，完成整个集成过程，同时非常仔细、非常认真地记录下整个体验。就是意识流的笔记，但会特别关注那些我遇到了摩擦、且我认为那个特定用户心智模型会觉得困难的地方。然后这些就是我们倾向于投入大量精力去认真思考”如何解决这个问题”的地方，并在打磨细节上倾注大量心血，把它做到位。

顺便说一句，我刚才给你举的那个错误信息的例子——实际上，Stripe API 处理那些边界情况的代码量，比主流程的代码还要多。我觉得这相当了不起。大多数人不会这么做，但事实证明，这不仅是我个人印象深刻的地方——当我与 Stripe 用户交流时，这也是他们最常提到、最让他们感到惊喜的产品体验之一。这是他们能更快采用 Stripe 的原因，也是他们持续采用其他 Stripe 产品的原因，因为他们知道这比做任何其他事情都更容易。所以这真的很重要。关键在于，我们对在哪些地方特别精益求精是有意为之的，一旦确定了这些地方，就会以一种相当系统化的方式去做。这本身也是一门好生意。

结账流程的优化与收入提升

举例来说，实际上就在今天早些时候，我们发布了一篇博客文章，介绍了我们一直在优化两样东西——一个是我们所谓的 payment element，这是一种”自带电池”的即插即用 UI 组件，可以直接在你的网站上嵌入支付集成。你可以对它进行样式定制以匹配页面的其余部分，但它本身已经包含了很多强大的功能。另一个是我们的一套托管服务，叫做 Stripe Checkout。这里的要点是，我们花了多年时间在网上审视了大量的结账流程，找出了所有那些有问题的边界情况，一直在这些产品上努力优化它们。而且我们不会止步于此——我们还一直在反复琢磨：在我们已经构建的流程中，还有哪些事情是可以减少延迟的、减少一次点击的，诸如此类。

我们发现——我们最近测量了这样的差异：一批真实用户从相当标准化的、自建结账流程的集成方式迁移到我们提供的这些界面上——无论是 payment element 还是 Stripe Checkout——结果发现，这使用户的平均收入提升了 10.5%。这个数字非常惊人。要知道在这个行业里，你做的那些小改动，甚至那些你倾注心血和汗水的大改动，通常带来的提升都是用基点来衡量的——也就是百分之一的百分之几。而我们这一系列小变化随着时间不断累积，最终叠加到了 10.5%，这非常了不起。关键是，你之所以能达到这个效果，是因为你知道这件事最终可能很重要，并且在过程中的每一步都精益求精，最终它复合成了一个巨大的影响。所以我认为这一系列体验正是这条运营原则真正发挥作用的领域。

正是对这些流程的思考，促使我们构建了 Link——这是我们的一款一键结账产品。它对我们的用户客户体验以及转化率等方面都产生了巨大的影响。所以这真的很重要。

网站与产品页面的精心打磨

还有一个领域我想提一下。我认为 Stripe 在网站、我们的很多营销页面和产品说明页面上投入了大量心血和关注，这一点大家可能都有所耳闻。对于我们这样一家公司来说，在这些体验的构建上做到极度精益求精，是否立刻就能看出意义所在——这一点并不那么显而易见。但我们确实这么做了，而且我认为这对我们和我们的用户来说都真的很重要。我们之所以进入这种模式，是因为我们意识到自己正在构建大量的基础设施。

我们构建了所谓的全球支付与资金网络（global payments and treasury network）。这实际上就是我们的产品基础设施——负责将资金转入 Stripe、代用户持有余额、将资金转出、处理不同企业之间资金流转的所有自动化流程，以及我们必须处理的所有监管相关事务，都在这个庞大的支付引擎中完成。但作为一个用户，你很难走进来亲自检查这些并判断”它到底好不好？“你也许可以去跟一批其他 Stripe 用户聊聊，但从外部很难了解。所以，如果我们用来解释这些产品价值和能力的体验本身在细节和用心程度上做到极致，这实际上能帮助我们的用户准确理解我们是如何为他们服务的。

我们网站上所有那些精益求精的做法正是由此而来的。我们有很多这样的特色功能——比如页面上有一个旋转的地球，展示你在不同国家可以使用哪些支付方式；再比如我们主页上那种大型动态波浪效果。总的来说，Stripe 在发布产品时常常会创造这些令人惊艳的互联网时刻。我们这么做是因为希望用户能够看到我们所投入的心血和关注。这在某种程度上带来了一个美妙的附带效应——这些体验往往会在 Twitter、LinkedIn 和其他平台上被大量分享，因为它们本身就值得一看——不仅因为它们很美，还因为它们经常推动了 Web 平台的技术边界。而这反过来意味着，那些自己也在推动互联网商业发展的人，就更有可能了解 Stripe、了解我们的能力。

所以在 Stripe，精益求精以各种不同的方式产生着实实在在的影响，我很享受在这么多不同领域以这种方式工作。

摩擦日志的实操流程

Lenny： 沿着这个方向我还有几个后续问题，但在此之前，我想深入聊聊这个摩擦日志的流程。

David Singleton： 好的。

Lenny： 想了解一下你们具体是怎么操作的。大概有两个问题：这是人们日常工作中的常规任务吗，不管是高管还是 PM 们？另外，有没有一个共享的模板——就像你刚才提到的，你是谁、你在什么公司、你想解决什么问题？你们在战术层面是如何将这个流程落地运作的？

David Singleton： 好问题。这个实践在通用场景下非常有价值。在很多地方都可以应用摩擦日志，来真正照亮最有效的投入时间和精力的方向。

我们在 Stripe 的很多不同职能和场景下都使用这个实践，但确实几乎每个产品团队都有一个人——通常是 PM，有时是工程经理——他会以一个定期循环的方式，走一遍产品的端到端流程并撰写一份摩擦日志。多年来，我每个月都会以一个新用户的身份走一遍 Stripe 的注册流程，写一份摩擦日志，然后标记公司里相关的负责人来处理我们观察到的一些问题。

退后一步审视的价值

David Singleton： 这种退后一大步的过程之所以有价值，是因为到了现阶段我们有很多人，有数千名工程师在并行工作。虽然每个人都非常重视在工艺上精益求精、注重细节，但各自的细节打磨可能会导致体验上的分歧。通过以固定的节奏、用摩擦日志的方式把所有内容放在一起审视，确实帮助我们在并行运作的同时保持了整体的协调一致。因此，高层领导、高管——我想说的是我们较大业务领域的负责人——通常也会亲自实践这个方法，以确保他们负责的所有内容都整合得很好。所以它实际上是递归式地在不同层级上发生的。

摩擦日志的模板

关于你问的有没有模板——其实流程相对简单。是的，有模板，事实上 Stripe 有一篇开发者文章，也许我们可以放到节目备注里，里面就有这个模板。但它的内容说白了就是：说清楚你想做什么，非常明确地界定你试图建立心智模型的那个用户是谁，因为这样能帮助你在走流程的过程中做出正确的判断。然后就是保持一个非常清晰的意识流日志，记录你在构建过程中发现的一切。

另外，还有一点非常重要——也要表扬做得好的东西。我经常把这些文档发送给公司里很多人。这是一个认可出色工作的绝佳机会。比如我碰到那个链接到文档的错误提示，我就会说，这个做得太棒了，干得好。

给团队留出改进体验的空间

Lenny： 作为一个曾收到过公司 CEO 发来他们在尝试预订时遇到的各种问题邮件的 PM，当时的感受往往是：天哪，我有那么多目标要达成，有这个时间线，有这些正在推进的事情，根本顾不上。你们的文化是怎样的？你是如何给团队空间去做那些”就是为了让体验更好”的事情的？你实际上是怎么操作的，才能让 PM 们收到这些问题时不至于压力山大？

David Singleton： 这要从我们的运营原则说起。因为我们的运营原则是用户优先和在工艺上精益求精，所以我们所有的规划方式实际上都很好地围绕这个理念构建——我们会预留足够的时间来真正把体验做好。也许最突出的例子甚至不是摩擦日志中发现的问题——稍后我们也许可以聊聊我们在可靠性方面的投入——但总会有出问题的时候。

有一点对我来说非常重要，那就是我们必须是一个学习型组织。我们需要理解为什么会出问题，然后采取行动防止同样的问题再次发生。这意味着我们会识别即时修复项——我们就是这么称呼的——并且仔细地对它们进行优先排序。其中大多数重要的修复项，实际上会优先于路线图上的其他工作被安排。也就是说，作为一个 PM，在构建路线图和计划时，你确实需要考虑：我大概需要在这个领域预留多少带宽，来处理摩擦日志中可能出现的问题，以及应对那些运营层面的事情？

这因团队而异，也因产品阶段而异。Stripe 并没有一个”预留 50% 时间做这些事”的统一规定，那样也没道理。但我们确实鼓励并要求每个团队认真思考：他们应该为这类活动预留多少时间。这样说合理吗？

Lenny： 完全合理。我本来想问你有没有一个固定比例，结果基本上就是你们信任团队自己去分配合适的时间。

David Singleton： 没错。

UX 评审实践

Lenny： 好的。沿着这个方向，我实际上问了 Shreyas Doshi 我应该问你什么问题。

David Singleton： 哦，有意思。

Lenny： 你肯定不知道我会这么做。他说我应该问问你加入 Stripe 后不久是如何做上线前 UX 评审的，而且他说你在这方面非常擅长。具体是什么样的？别人可以从你的经验中学到什么？

David Singleton： 我在 Stripe 早期做 UX 评审的方式，以及 Stripe 各个团队至今做这类评审的方式，其实运用了我们刚才讨论过的一些方法。摩擦日志这个实践，很多时候是异步进行的——有人会坐下来留出一个下午，走一遍产品并做详细的记录，这非常有用。

但我们同样觉得一起走一遍这个流程非常有价值。所以我们会把构建该产品的团队召集起来，同时也会请很多跨职能的合作伙伴参加。比如负责处理用户相关问题的支持人员，以及该团队所属组织中的高管，一起来做这些走查——我们采用的是与摩擦日志完全相同的方法：想象我们是某个特定的用户，一起去体验产品。然后非常开放地讨论。我们现在的做法是：我们有一个要讨论的问题清单，任何人都可以在 PM 通常边走查流程边演示时往里面输入内容。最后我们会聚在一起，逐一讨论每个问题——这个需要解决吗？我们到底怎么看？这就是我早期采用的方式，也是我们如今大规模推广的方式。

一起看产品的价值

一起做这件事有很多好处。有人曾经这样跟我描述：如果你是厨师，你会去尝那碗汤，然后和你的厨房团队讨论汤里放了什么、哪些地方好、哪些地方不好。如果你经营一家电影公司，你会坐下来和大家一起看很多电影。所以，一起看产品，我觉得这件事非常有活力，而且在传达我们对工艺的标准、以及我们希望产品在大规模、跨公司的层面为用户如何协同运作的价值观方面，也非常有价值。

在此基础上，我们偶尔还会做一件事——我在 Stripe 偶尔也做过——叫做”走访一线”，我们会和全公司一起看产品。我们有一个每周例会叫 Friday Fireside，不是必须参加，但公司大多数人都会参加。我们做过几个系列，会一起走一些非常关键的产品流程，讨论这些流程如何体现我们的各种优先事项和试图推动的转变，但核心始终围绕用户体验和特定用户。事实证明，这在帮助所有人建立共同语言、对齐认知方面有着巨大的价值。

这些大概就是 Shreyas 想到的一些方法。

Lenny： 令人惊叹的是，你们从这么多不同的角度来追求高质量的最终产品——走访一线、摩擦日志、全公司一起看产品的会议、UX 评审。这就是为什么你们能构建出如此高质量的产品。光有一个”我们要做伟大的东西”的价值观是不够的，你必须从那么多不同的维度去推进才行。

价值观需要实践落地

David Singleton： 是的，这是一个很有意思的观察。我认为几乎你谈到的任何东西都可以被称为一种价值观。我是说，拥有价值观很重要，但你需要有相应的实践支撑，才能让这个价值观对每个人都变得真实可感。所以我们非常频繁地发现，对于任何产品开发团队，只要他们确定了能够真正代表他们想为用户交付的体验的正确指标，然后定期、可预测地聚在一起看团队在这些指标上的表现，其他一切就会自然而然地发生。因为你清楚自己要推动什么，你在自己的时间优先级中做出的每一个微决策，以及你实际在做的每一项工作，都会向上对齐到那个目标。所以我为什么这么说呢——你必须有一个可预测的、定期的机制，向上对齐到你想要交付的价值，才能真正让它落地。

如何准备 UX 评审

Lenny： 回到 UX 评审的话题，有一个问题想问。向 CTO 做这样的评审汇报通常压力很大。你会给产品经理、设计师和团队负责人什么建议，来准备这样的会议？无论是在 Stripe 还是其他公司？

David Singleton： 我个人尽量让自己尽可能友善、不那么令人紧张，但我知道不管我怎么做，这类会议的压力感是无法完全消除的。在 Stripe——我认为大多数公司大概也是如此——但至少在 Stripe，核心要诀是换上用户的视角。如果你充分理解你的用户，理解他们希望从体验中获得什么，然后在被问到任何问题或感到不安时——比如”这个问题猝不及防”——把它拉回到”记住我们正在为用户做什么”，通常就能让任何这样的会议进展得非常顺利。这是我最主要的建议。

在任何公司中，随着你管理的团队越来越大，都会存在一个风险——个人贡献者（IC）总体上与你直接交流的时间非常有限。所以总有一种风险：你可能做了一个相当无关紧要的评论，但它被脱离上下文解读成了非常重要的指示。因此我个人也非常努力地将自己的反馈锚定在”我们想要交付的用户体验是什么？这件事真的重要吗？“——承认这个风险的存在。是的，这确实需要持续不断地练习。

构建更好产品的建议

Lenny： 你已经涉及了其中一些，但如果有人想提升自己构建产品的能力——不管是产品经理、设计师还是工程师——你通常会给出什么样的建议来帮助人们构建更好的产品？

David Singleton： 几乎总是回到我们这里已经谈过的那些东西。还记得最开始我谈到的与用户紧密迭代吗？如果你有一个倾听用户的机制，能很快把东西交到他们手上，然后获取他们的反馈，形成反馈循环，你就不太可能走偏。尤其是当你花了很多心思确保这些是正确的用户——他们的需求与你的战略对齐——那么这个反馈循环如果运转良好，实际上很难出错。

如果你没有这样的反馈循环——实际上，当我和行业内各家公司的人交流时，令人惊讶的是，在产品开发周期中这种反馈循环不存在的情况非常普遍。如果你还没有，那就去想办法建立它；如果你已经有了，但从你产生”这可能很重要”的想法到获得用户反馈之间，无法非常快速地把东西放到用户手中，那就想办法加快这个过程。在 Stripe，我们在所有开发者工具和基础设施上投入大量精力，使得变更能够持续交付到生产环境，这样我们就能非常迅速地将它们呈现在用户面前——这非常重要。

（赞助商广告段落已跳过）

深入一线与 Engineercation

Lenny： 我听说过关于你的一点是，你会深入到非常细节的层面，作为 Stripe 这种规模公司的 CTO 真的会钻到很深。我接触到一个词叫”engineercation”，我想它和这一点是相关的。你能谈谈这个吗？你怎么看待深入一线这件事？

David Singleton： 首先，关于深入细节有多重要这件事。在 Stripe，我们发现这对工程经理尤为重要，但实际上对所有管理者来说都很重要——他们需要对团队是否走在正确的轨道上、在哪里遇到了阻碍有一个非常详细的了解，以确保我们能在单位时间内为用户取得最大的进展。我们发现，同样地，我们所解决问题的性质非常奖赏领域专业知识的积累，即对事物的深入理解。我们要求所有管理者成为团队计划的主编。而我认为做到这一点的唯一方法就是为自己建立正确的信息循环，去真正了解一线实际在发生什么。

当然，如果我每天都在做 IC 工程师级别的工作，那会非常有害——那不是一个能够帮助引导团队的人该做的事。所以重要的是要有选择地、在合适的节奏下去做。我认为这非常有价值。

Engineercation 是我个人会做的事。它显然是 engineer 和 vacation 的混成词，但它绝不是假期。至少我对这个名字的理解是——你在 engineercation 上做的事情是：我会连续腾出几天时间，实际上是三到四天，加入一个团队，领一个小任务——希望是一个我们能从头到尾完成并上线生产环境的小功能——按照团队完全一样的体验来做这件事。这样你就能了解开发者工具、构建基础设施、代码如何被审查、文档质量如何、我需要等多久才能看到自己的东西上线，才能启动我之前谈到的那个与用户的反馈循环。你实际上是去加入一个团队，做真正的工作。

摩擦日志的价值

David Singleton： 在做这件事的过程中，保持记录摩擦日志是非常有价值的，因为你要把这段体验写下来，一方面作为自己的备忘——它帮助你在接下来一整年里参与的各种权衡决策和优先级讨论中有所参照，这些上下文确实很有帮助。所以我实际上会定期重读这些报告。同时，把这份工作成果分享给团队也非常有价值——这表明你理解一线实际是什么体验，以及我们打算如何把这些信息融入优先级排序中。这就是你做的事。不过说回来，做这件事最难的往往是腾出连续几天的时间。之所以我把它类比成假期，当然人们都去度假。

顺便说一句，我每年都很努力把所有年假用完。我认为休息一下、重新充电创造力是很有价值的。关键在于，你度假的时候，世界照常运转，一切都没问题。所以我也用同样的方式——我会推掉所有会议来清空日程，切换到创客日程（maker schedule）来做这件事。我在 Stripe 做过很多次。我建议 Stripe 的工程经理们在入职后的头三到六个月内做一次 engineercation。这能让你获得大量关于团队实际体验的上下文，然后对于持续每年做一次的人来说，它持续提供大量的上下文。

如何跟上技术变化

Lenny： 这太不可思议了。我从来没听过这样的流程。你怎么保持对基础设施和代码的知识和了解？毕竟你要亲自写代码，而一切变化得那么快。

David Singleton： 这个流程恰恰就是为了帮你做到这一点的。我刚才解释时可能遗漏了一点——我们通常会在团队里指定一个伙伴来带你完成整个过程。值得一提的是，在 Stripe 我们大量使用 Ruby 编写代码，同时也写很多 Java、TypeScript 之类的语言。但我们的核心基础设施，也就是核心产品基础设施，大部分是用 Ruby 实现的。我刚加入时从未写过一行 Ruby，而我知道自己想做这件事——实际上在加入之前也做过类似的事情——所以我很害怕：如果我去了却写不出一行 Ruby，会失去多少公信力。但我的第一个伙伴是一个叫 Ajhja 的人，他现在还在 Stripe 做得很出色。在那三天里他帮我学了 Ruby，他们（有些听不清）了我一下，但最终大家都非常感激我做了这件事。

Lenny： 想象一下那个不得不审查你 PR 的工程师。

David Singleton： 我告诉他们，这是流程中很重要的一部分。请不要对我有任何区别对待。当然，要让这件事运作良好，你必须先设定期望——如果有些东西不是你想要的样子，不要对我采取什么行动。这是一种纵向的、以建立共识为目标的过程。

意想不到的发现

Lenny： 在这个过程中，有没有什么让你感到特别意外或有趣的发现？过去几年里让你印象深刻的？

David Singleton： 我遇到的最有趣的事情之一是：随着规模扩大，我们都知道在自动化上投资是很有意义的。但在我们的开发流程中有很多地方，虽然我们做了自动化，但大家仍然在努力互相帮忙——比如说，如果你想用某个东西，请去找那个团队谈。而如果你和另一个人在不同的时区工作，往往更好的做法是把它好好文档化、自动化，然后也许把咨询渠道开放出来就行。所以碰到这类摩擦点，然后围绕它展开好的讨论，确实很有帮助。但 Stripe 的一个好处是，这类改进并不依赖于我去做什么。

开发者生产力投资

我们真的很重视让 Stripe 成为工程师们能做出职业生涯中最好工作成果的地方。这意味着要为他们配备好的工具和良好的开发者生产力。所以我们在开发者生产力上投入很大。我们有一个专门负责开发者工具的团队，他们运行的正是我刚才描述的那套产品开发流程——只不过服务对象是内部用户。也就是：深入了解你的用户，频繁地与他们交流。比如，我们每月做一次调查问卷。我们的规模足够大，每月可以抽样足够多的人，从而获得具有统计显著性的全组织样本，而不需要每个人都回复。每个人每六个月只需回复一次。我们非常直接地问：你的体验如何？然后我们用这些结果来确定开发者生产力团队的工作路线图优先级。我们也会度量一切——我们知道人们在哪里卡住了。当我们把自由文本回复和数据结合起来看，就能帮助我们投资在最能让所有人更高效的地方。

Lenny： 好，这正是我接下来想聊的方向。让我铺垫一下这个问题。我最近看到你的一条推文——我这里有些笔记，我直接念一下：你们平均每天向核心 API 部署 16.4 次变更，正常运行时间达到了 99.999%，而此时此刻，全球每十个人中就有一个曾与 Stripe 驱动的企业进行过交易。所以我的问题是，要实现这样的成果需要什么？尤其是在工具、文化以及你刚才谈到的那些方面？

可靠性与持续变革并行

David Singleton： 我认为值得先说一点：在 Stripe，我们正在做的事情我认为是相对独特的。我们为在 Stripe 上构建业务的企业——也就是我们的用户——提供的服务，对他们来说是真正关乎业务存亡的。我们说的可是流入你企业的真金白银，帮助你维持运营、甚至让你的运营成为可能，也许还包括给你的员工发工资等等。以及我们围绕账单订阅做的所有收入自动化，我们的财务自动化产品，帮你完成月末结账——这些东西容不得差错。同时，Stripe 如今的资金流动规模，已经相当于 Stripe 刚创立时整个电子商务的总和。所以我们在极其关键的规模上运营。面对这种既关乎业务命脉又涉及巨大规模的局面，我们对用户有着巨大的责任——要把事情做对，为他们提供极致的可靠性和可用性。

所以我们确实对此深思熟虑。当然，要做到非常可靠有一种方法，那就是尽量少改动。永远不改动任何东西，出故障的机会就少得多。但我们没有采用那种方法。用户的需求在快速演进，我们服务他们的方式和能够服务他们的方式也在快速演进，因此我们能否在一个持续变化的环境中运作就至关重要。希望我已经解释了为什么这很重要——比如之前说的那种反馈循环，因为只有当你能把东西真正交到用户手中，反馈循环才成为可能。所以我们选择设计我们的工作方式，同时做到这两点。这确实需要大量的心血和关注，也需要大量的系统支撑。也许我来逐步展开说一下。

开发流程与自动化测试

David Singleton： 首先，我们的开发流程以及将变更推入产品的方式中，有很多设计使得这一切成为可能。其中一点是我们非常重视拥有高质量的测试套件。所以我们坚信自动化测试。我们没有手工测试人员，因为手工测试人员不可能覆盖我们提供的海量 API 端点和配置组合，但自动化测试可以。因此我们努力构建大量的自动化测试覆盖，然后每一位工程师提交的每一项变更，在甚至有可能进入生产环境之前，都要先经过这套测试的全面检验。然后我们在变更最终进入生产环境的过程中，会将其置于越来越接近真实、覆盖面越来越广的环境中。所以我们有多个预发布（staging）环境，在那里运行一组更真实的端到端测试。最后当某个变更真正上线时，它会从极小比例的流量开始，逐步扩展到全部流量。

这样我们就能在问题变得严重之前发现它们。为了实现这一切，我们需要做很多事情。比如说，Stripe 工程师提交的每一项变更——通过测试之后——实际上会在大约 45 分钟内自动进入生产环境。我认为没有多少金融服务公司是这样运作的，至少在最近几年之前没有。这需要一种思维上的转变。你必须默认变更会自动上线，并为此建立正确的系统和流程。另一件重要的事情是，我们必须专注于系统性地提升应对各种故障的能力。我之前提到过，成为持续学习的组织对我来说非常重要。

故障应对与事件响应

当然，还有一点也很重要——事情总会出错。有时候是某个下游合作伙伴出了故障，有时候是我们控制范围之外的网络中断，诸如此类。所以问题在所难免。因此我们必须建立正确的系统，将任何单个故障造成的损害降到最低。我们在这方面下了很大功夫。我们在很多地方部署了冗余系统，我们仔细考虑如何确保一个用户的故障不会波及其他用户，而且当问题发生时，我们会非常积极地去修复。这在大多数公司包括 Stripe 都叫做事件响应（incident response）。我认为 Stripe 在事件响应方面做得非常、非常好。我们有很好的工具，既能快速声明事件，又能迅速召集合适的人员来解决问题。

但我们不止步于此。我们非常认真地复盘每一次事件，不仅找出”怎样才能阻止这一次事故发生”，更要找出”怎样才能在未来预防这一整类问题”。正如我之前所说，我们把处理这些问题的优先级排在路线图上其他一切事项之上——记住我们正在做的事情有多么重要，如果我们做不好这一点，就无法为用户快速推进。这就是我们的做法。

持续改进与混沌测试

顺便说一句，我不想给人一种我们已经把一切都搞明白了的印象。当然，所有这些都始终在不断演进之中。我们总是在努力思考如何做得更好。比如近年来我们意识到，从所谓的混沌测试（chaos testing）中可以获得很大的收益——也就是主动注入错误，确保系统在出现故障时不会对用户造成影响。所以我们一直在不断演进，也非常乐于向其他公司学习，向我们的用户学习。这是我们非常重视、并且以极其严谨和系统化的方式去思考的事情。

Lenny： 你是说从推送代码到进入生产环境只需要 45 分钟？

David Singleton： 通常是的。我刚才描述的那套测试，会在每一个变更上运行，而且它和你提交给另一位人工审查的过程是并行进行的。所以它会先跑一次，通常需要大约 15 分钟。然后一旦变更被合并到我们的代码库中，我们会再运行一次同样的测试套件，又是一个 15 分钟。之后通常需要大约 30 分钟让系统自动部署到生产环境。这就是我们的运作方式，也是我们思考如何与用户建立紧密反馈循环的方式——这意味着你可以在早上收到用户反馈，当天就能想出解决方案，并且在当天结束之前就把改进交到用户手中。我认为这个在 24 小时内完成的循环是非常重要的。

Lenny： 这太厉害了。我记得在 Airbnb 的时候，测试跑完要好几个小时，因为数量太多，他们后来慢慢优化了。但我习惯的量级更接近那种。

David Singleton： 保持这个数字需要持续不断的努力。顺便说一下，这些数字很重要，对于我们这种规模的公司来说，这个量级大约是合适的。当然，随着你增加更多的功能，你就会增加更多的测试。所以我们不得不发明一些机制来让测试更多地并行运行。我们现在有一种叫做选择性测试执行（selective test execution）的机制——对于那些在进入生产环境之前必须跑的完整测试套件，我们会在更多的机器上并行运行所有测试。但对于针对单个变更运行的测试，我们实际上有系统能够判断：哪些测试对这个特定变更是真正相关的？这已经成为一个真正的创新来源。事实上，Stripe 的分布式变更与测试环境是我们实际运行的最大分布式系统。运行它所需的精力、努力、严谨和工艺，与运行其他一切系统是一样的。

开发者生产力的提升

Lenny： 你们做过的哪些事情对开发者生产力的提升影响最大？

David Singleton： 我们之前已经提到过几个了。那个自动部署机制确实产生了非常大的单独影响。在我们引入它之前——大概是在过去五年内的某个时候——每次部署到生产环境都需要一位工程师实际盯着它，看着它上线，确保所有监控图表看起来正常。这有点像轮盘赌，因为你总希望自己的变更能跟别人的变更捆绑在一起，这样别人就会替你盯着。所以能够做到——你的变更上线的同时你的手指已经在键盘上写别的东西了，而且变更会被自动监控——这对我们的生产力是一个巨大的提升。还有一些非常小的改变也起了作用。这就像优化结账流程一样，非常小的改进也能累积产生巨大的效果。比如大约八个月前，我们做了一个改进——我们使用的代码审查工具是 GitHub Enterprise，这在业界很流行，但我们在它之上构建了很多自己的体验和控制功能。我们在 PR 上加了一个小复选框，叫做自动合并（auto merge），意思是：一旦审查者说这个变更没问题了，我不需要再回来看它，系统就会自动接管。这仅仅砍掉了一个让人分心的人工步骤，但它叠加起来对生产力产生了很大的变化。所以如果你刻意去做，这些非常小的改进能够逐步累积成巨大的影响。

AI 对产品构建的影响

Lenny： 我现在想换个方向聊聊。AI 现在非常火。AI 是否已经影响了你们构建产品的方式？如果还没有，你认为未来几年它会从哪里开始切入？

David Singleton： 我们对 AI 非常兴奋。先退一步说，Stripe 从很早期开始就在产品核心使用了机器学习和高级机器学习技术。Radar 是我们的支付欺诈解决方案，它是我们产品线的核心，从推出之初就使用了机器学习。另外，考虑到 Stripe 的业务性质，我们需要在系统中做大量工作来识别不良行为者——欺诈分子或欺诈性商家。因此我们多年来一直在这些领域大量运用机器学习技术，没有它们公司根本无法运营。所以 ML 和 AI 之间的区别在于——当我们今天谈论 AI 时，主要是在说大语言模型的应用，而这些模型实际上基于一项叫做 Transformer 的新技术。这源于 Google 几年前发表的一篇论文，大约四五年前。我们在一年多前将 Transformer 技术融入了那些系统，事实证明它对我们为用户解决这些问题的能力产生了非常深远的影响，这非常好。

但我们同样对大语言模型的应用感到兴奋。这实际上有两个维度。第一，我们感到荣幸能够帮助和服务大量在这个领域创业的企业。AI 初创公司和其他公司之间一个很大的不同在于，运营一家 AI 初创公司在计算资源方面其实相当昂贵——在这些 GPU 机器上运行这些模型的成本很高。因此这类公司通常需要从第一天起就有变现模式。我很高兴地说，大多数 AI 公司都在使用 Stripe，我们也在非常努力地确保满足它们所有的需求。比如 OpenAI 使用我们来变现 ChatGPT Plus 和他们的所有其他产品。而且不止于此，我们实际上还在帮助它们支撑所有的订阅、收入追踪以及围绕业务的财务运营。这里的关键在于，我们多年来一直在这些东西上投入了非常大的工程团队，这意味着任何想要自己构建对账产品和订阅商业模式的人，都需要投入大量工程团队。但如果你能用 Stripe，你就可以把那些非常宝贵的工程资源集中在这个领域日新月异的创新上。所以我们对这一点感到兴奋，同时我们也对将这些 AI 技术应用于自身、更好地服务用户的能力感到兴奋。比如在 Sessions 大会上，我们会展示其中几个案例。

我们在 OpenAI 还处于 beta 阶段——年初时 GPT-4 的私密 beta——就开始与它们合作了。我们首先想到的是，Stripe 有大量的文档，我们在让文档做好这件事上倾注了大量心血。但如果你想在 Stripe 集成中实现某个目标，通常需要花相当多的时间阅读文档并作为终端用户去综合理解它们。我们意识到可以让 GPT-4 阅读我们所有的文档，将它们存储为嵌入向量（embeddings），然后为开发者回答问题。所以现在我们的文档中已经有一个早期版本的发布，事实证明相当有价值。我们还能够将这些技术应用到产品的其他领域。我们在 Sessions 上会展示一个早期版本——在我们的收入和财务自动化套件中，有一个非常强大的产品叫做 Sigma。它允许你对所有 Stripe 数据编写 SQL 查询，这样你就可以精细地检视你的 Stripe 数据来理解你的业务。哪个国家的销售增长最快，哪个国家的哪个细分市场有什么特征——非常强大的产品。但对于非开发者来说，采纳它可能有一定挑战。你确实需要知道如何编写 SQL 查询，除非你只用菜单里预设的那些，否则无法获得这个产品的全部价值。而事实证明，借助大语言模型，我们可以应用这项技术让你用自然语言提问，我们的引擎会实际为你编写 SQL 查询。我们做了大量工作来调优它，确保它可靠且可理解，进展非常顺利。我们也在将这些技术应用于提升内部效率、更快回答用户的问题、更快地互相帮助方面看到了很好的前景，这些我们也在做。

有一件具体的事情让我很兴奋——在 ChatGPT 发布后不久，我们意识到如果能将它应用到 Stripe 内部的许多场景中会非常棒。但正如你可以想象的，我们日常处理的很多数据对业务和用户来说都非常敏感，我们对此非常重视，围绕这些数据有大量的治理机制。但我们想让这项技术变得可用，我们不能直接说”嘿，Stripes，去用 ChatGPT 吧”。所以我们搭建了一个与 GPT-4 的集成，以及一个内部 UI 来使用类似的模型。但我想向所有观众分享的一点是——我们在这个工具中内置了预设（presets）。在使用大语言模型时，你需要编写一个提示词（prompt），帮助模型进入一个能够解决当前特定问题的状态。我们发现编写提示词这件事对许多不同岗位的人来说都是可以上手的，不仅仅是工程师。我们市场团队的同事、用户支持团队的同事也都能使用。而且你可以在提示词上投入大量心血，让它效果非常好。我们让它可以在全公司范围内共享。所以我可以抓取一个帮我以正确语调撰写博客文章的预设，我发现它对我和公司里许多其他人来说都非常有价值。所以我认为，目前在企业服务用户和运营方式上有大量的创新可能，我们正在代表我们的用户努力运用所有这些创新。

Copilot 与工程师生产力

Lenny： 那作为工程师呢？你们对 Copilot 持什么态度，有没有类似方向的东西你们觉得有用或有所顾虑的？你怎么看待这个问题？

David Singleton： 我们对 Copilot 感到兴奋。我们已经把 Copilot 提供给内部工程师使用了。我们进行了相当严格的试验，确保我们对它在实际提升代码编写能力方面的效果、以及它生成的代码质量感到满意，结果发现它对我们非常有效。不仅在生产力方面，也在帮助工程师感觉他们可以将精力投向更大的问题——这些东西应该如何组合在一起——而不是那些微观问题上。因为我们收到了非常好的反馈，所以我们在内部非常广泛地开放了它，我们也非常期待看到这个领域未来的发展。

Lenny： 你对生产力提升有没有一个感觉？比如说你有很多 10 倍工程师，一个顶尖工程师从 Copilot 中获得的收益，和一个较新的工程师相比如何？

Copilot 的实际效果

David Singleton： 说实话现在下结论还为时过早，因为我们最近才大规模开放使用。我们通常看到它加速的是这样一类任务——记得我提到过我们在构建全面测试套件上投入了多少精力。实际上，用 Copilot 来生成测试用例，效果极其出色。编写好的测试需要大量重复的模板代码和相似的概念，但你也必须非常仔细地思考：这到底是不是在测试我想要的东西？Copilot 帮你省去了大量模板代码的生成工作，让你真正去思考那些至关重要的问题。我认为这也会对我们所写代码的质量产生深远的影响。但现在说这些还为时过早，因为我们刚刚推出不久，还很难衡量它的实际影响。

Lenny： 我跟一位工程师聊过，他就说，我喜欢亲手写代码，现在这东西替我写了，让我有点难过。所以他就把它关掉了。我觉得随着时间推移，人们会想：“嗯，说得也是，那部分我本来也没怎么享受过。”

David Singleton： 对，说说我的个人体验吧。我热爱写代码，真的非常热爱写代码，这基本上就是我的娱乐方式。但我也很喜欢用 Copilot 写代码，因为就像我说的，它意味着我可以把注意力集中在那些真正重要的部分。我觉得这在 Stripe 内部是一个相当一致的体验。

管理大规模团队的心得

Lenny： 太好了。你管理着一个庞大的工程团队。我不知道你有没有公开过工程师的具体人数，但我知道人很多。这是一个很宽泛的问题——关于管理人员或者说管理工程师，你有哪些经验教训？方向随你选。

David Singleton： 哇，大问题。可以谈的方向太多了。我分享几个观察吧，它们不一定有一个统一的主题。随着我负责的团队越来越大，我反复学到的一件事就是：我个人实际上不会参与到任何真正重要的决策中去。一个组织每天都在做出成千上万的决策，每一位工程师或 PM 每天都在做上百个小决策和一些大决策，这些决策影响着整体的走向。

最重要的事情是真正把重心放在招聘上——雇佣正确的人，这意味着雇佣那些你能够赋予极大自主权的人。如果我试图介入大量决策，一切都会陷入停滞。怎么做到这一点？显然，严格把关很重要，我们前面已经描述过我们的招聘流程了。我非常注重在招聘过程中非常深入地了解候选人。顺便说一件我之前没提到但我觉得很重要的事——在 Stripe，我们在招聘过程中非常重视推荐信和背景调查。

这通常在流程的后期进行。但如果你让一个人经历了整个面试流程，你总共大概跟他相处了八个小时吧？而如果你跟他以前共事过的人交谈，你实际上是在利用数千小时的直接经验。我们对此非常认真，我们会努力提出巧妙的问题，从中获取真实的信号。我确实发现，当涉及到那些后来产生了变革性影响的人选时，推荐信往往是让你对是否录用产生最强信念的时刻。

招到正确的人，然后你就要信任他们。不过，信任这件事很有意思。信任一个刚招进来的人其实相当困难，对吧？毕竟你对这个人还没有什么依托。我的经验是，你确实需要在开始时慷慨地给予信任，默认先选择信任。然后你需要让人们承担足够的责任，让他们证明自己能够驾驭这份信任。有时候，这意味着把一个你认为很可能最终能胜任重要角色的人，先放到一个较小的岗位上。其他时候，你就是有一个需要填补的大角色，那你就要非常自觉地去信任和委托，同时给予大量支持。

我一直在努力委托——有时甚至超出了我感到舒适的程度——因为这是在相当规模下运营的唯一方式。我想说的另一点……抱歉，这真的是一盘大杂烩，各种各样都有。

Lenny： 很好。

David Singleton： 随着我所负责的组织不断壮大，我意识到的另一件事是，你必须极其自觉地管理自己的时间。有几百甚至几千人，完全有正当理由想占用你的一些时间。如果你任由收件箱里涌入的东西或日历上排好的事情来决定你把时间和精力花在哪里，那结果将是随机的。很有可能这些事情并不会累积成最大的影响力。我个人大概十年来一直在运行一个循环——每周日晚上，其实通常从周日下午就开始了，我会阅读上周发生的很多事情。

然后在周日晚上，我会给自己写一个清单——你在这个播客里问了我一个问题，就是从我的角度来看，什么算是这期播客的巨大成功？

我每周日晚都会为自己的那一周做同样的思考。我列一个清单：如果我们这周完成了这些事情，那就是一个好星期。当然，我们需要保持灵活，一周中总会有意外情况出现。但说真的，这个清单很大程度上决定了我决定把时间花在哪里。我尝试鼓励组织中的每个人都这样思考，我认为这确实能随时间累积成更大的影响力。我想说的最后一件事是——我提到过运营原则（operating principles）对文化有多么重要。我认为对于任何管理者和领导者来说，也包括个人贡献者（IC）PM，你如何出现、如何表现，真的会塑造你身边的文化。

我非常努力地每天都保持一致的呈现方式，即使经常会有各种出问题的事情、糟糕的事情、困难的事情。保持前后一致其实非常重要。当然，要与我们所持有的所有价值观和我们想要建立的文化保持一致，从而在规模上真正树立榜样。不同的日子，这有容易有困难。最后一件事是，我认为管理好自己的精力也非常重要。

有些任务可能不是最重要的，但我知道我能从中获得很多快乐和能量，然后这种能量会延续到其他需要完成的事情上。

关于规划与优先级排序

Lenny： 在进入非常精彩的快问快答环节之前，我还有两个问题。第一个是——我感觉 Stripe 在规划、组织和优先级排序方面做得极其出色。我知道每家公司内部都没有外部看起来那么光鲜，但你觉得你和 Stripe 在规划和优先级排序方面学到了什么，是其他公司可能缺失的？

David Singleton： 是的，你这么说很有意思。我会说 Stripe 内部的规划并没有你想象中那么高的净推荐值。但我确实认为它实际上非常有效。顺便说一下，我认为 Stripe 的规划方式之所以在内部口碑不是最好的，原因在于我们增长非常迅速。这意味着几乎每次我们重新进入规划周期时——这也是 Stripe 的一个主题——我们都会从第一性原理出发重新思考许多内部工作方式。

我们通常不会默认直接拿来其他公司运行过的、或者我们之前用过的现成体系。我们会认真思考，结合我们正在为用户做的事情，这件事应该怎么做？即便是从第一性原理出发思考时，我们也经常会走出去和许多其他公司交流，从他们的经验中学习。这其实是我在 Stripe 非常欣赏和享受的一点。我在这里学到的东西，很大一部分不仅来自公司内部的人，还来自许多我们有幸密切合作的伙伴——因为他们的业务构建在 Stripe 之上，或者他们与我们处于相似的规模阶段。

一个很好的例子是 Amazon。Amazon 是 Stripe 的用户。因为与他们的合作关系，我加入 Stripe 的前几周就见到了 Charlie Bell，他当时负责 Amazon 的运营。我们现在在 Stripe 做的很多事情，都是从那段经历中学来的。这并不是说”哦，因为 Amazon 这么做过，我们就照搬”。我们会和他交流，也会向许多其他公司学习。关键是我们重视从他人那里学习，然后加以应用。

规划的核心方法

回到规划这个话题——因为我们倾向于从第一性原理出发深入思考，而且一直在快速增长，所以对我们公司来说正确的规划流程实际上在这些年里发生了非常显著的变化。我们每年会以较深的方式做一次规划，然后在年中以较轻的方式再做一次。你可以想象，如果每年做一次，而且你在快速增长，你就会想要重新审视具体怎么做。我觉得对于有条件反复运行同一套规划流程的人来说，你可以不断迭代和调优。而我们不得不随着推进做出更加刻意、更加大刀阔斧的变革。我们做法的核心有几件事。第一，非常重要的是要明确你在任何产品领域中所服务的用户是谁？在计划中把他们的需求放在首要位置非常重要。另外，Stripe 有一件事，它不算反常规，但在业界也不是最常见的做法——我们非常努力地服务于从极小到极大的各类企业。从那些通过 Stripe Atlas 刚刚起步的人，一直到跨国公司、财富十强、甚至财富榜首的公司。

这些企业之间的用户需求差异非常大。因此在任何领域，每个团队都需要明确自己服务的是谁。然后我们运行一种类似倒 W 形的流程。通常先由各个团队提出他们认为最重要的事项。然后一组产品负责人会聚在一起，尝试将其最重要的部分综合成一份公司整体战略草案，再把它带回各个团队，让他们思考：“如果那是我们的大方向，我的计划是否需要调整？”

我们再把它收上来做综合，然后再分发下去，让每个人都能带着充分的上下文在各自的团队中传达。我们发现以我们目前的规模，这种方式非常有效。

Lenny： 我还没提过这个，但实际上我的 newsletter 也在用 Stripe，我一天要查看好多次 Stripe 的应用，所以我大概属于”财富第一百万强”之类的级别。

David Singleton： 你有什么反馈吗？说真的，我很想听听你对 Stripe 的反馈。

Lenny： 挺好的。应用告诉我我……

David Singleton： 不不不，别告诉我们”挺好的”。有什么让你烦的？

Lenny： 关于流失率、按同期群（cohort）留存率这些，我非常在意，用于 newsletter 分析时，我其实用的是另一个工具，它给我的感觉是能更好地呈现一张按同期群显示多少人还在的表格。Stripe 在同期群留存指标方面还有提升空间。

David Singleton： 好。也许我们可以邮件聊聊这个。在 Stripe，我们确实非常重视——每次和 Stripe 用户交谈，我们都在寻找反馈，任何场合都是如此。我们经常把用户请到周五炉边谈话的开场环节——我之前提到过——我们总是会向他们征求反馈，而且我们真的、真的希望据此采取行动。

展望 Stripe Sessions

Lenny： 我希望我能有更多反馈，它真的很好用。最后一个问题，Stripe Sessions 马上要开了，在这期节目播出之前就会举行。大家应该关注什么？Stripe 的下一步是什么？

David Singleton： 我们在这次通话中已经谈到一些将在 Stripe Sessions 上首次公开发布的内容。按照我们的开发流程，这些功能已经在一些 Stripe 用户手中使用了相当长的时间，我们和他们一起精心打磨。我对下周将要分享的许多内容感到非常兴奋。其中一个是我之前提到的收入与财务自动化套件。

我们已经花了不少时间精心打造其中的功能。这也是一个非常好的例子，说明与用户紧密合作确实有助于大规模构建产品。我们有一系列功能是与 Atlassian 和 CloudFlare 这样的公司合作开发的，帮助他们在 Stripe Billing 上运行业务。他们的模型相对复杂。比如，你可能签了一份第一年有折扣的合同，第二年又有一个新产品在使用，第三年又会出现其他情况。现在你可以在 Stripe Billing 中对所有这些进行建模，我们将在下周的 Stripe Sessions 上展示如何在控制台中实现。

这将面向所有 Stripe 用户正式发布（general availability）。它让我们的所有用户——从极小到极大——都拥有世界上最优秀的 SaaS 平台才具备的能力。对此我很兴奋。另外还有一件事我们在这通电话中没有谈到：Stripe Connect 是我们面向平台和市场（marketplace）的产品。请允许我花一点时间说说，这是一个非常好的例子，说明在一个领域聚焦用户需求如何把我们带入了一个对许多其他领域用户来说非常有价值的空间。

Stripe Connect 背后的想法源自与 Lyft 和 Shopify 等公司的合作。在早期，他们使用 Stripe 处理收款（pay-ins），但我们意识到：“这些公司在运营多边市场平台，要让这一切运转良好，有大量繁重的工作要做。“我们需要获得一系列监管牌照，而且还需要做很多事情才能真正让资金流动起来，并以正确的方式进行记账。Connect 就是我们面向平台和市场推出的产品。

Connect 的可嵌入组件与工程杠杆

David Singleton： 过去一年左右，我们做了一件事：把我们在 Stripe 控制台中构建的许多功能——比如帮助用户从他们的用户那里收集正确的文件、处理退款等等——做成了可嵌入的 UI 组件，而且完全可以定制。这些平台可以把它们放到自己的控制台里，这样就能向客户呈现 Stripe 所赋能的大量能力，而无需自己做大量工程工作。

为我们的客户创造工程杠杆，往往是我们能帮到他们业务的最重要的事。下周我们会展示一系列这样的东西，我很期待。最后，我们之前已经提到了，但能展示一下我们在 AI 和大语言模型方面的一些创新会很好。我认为，这些在未来几年将产生重大影响。

闪电问答环节

Lenny： 那么，我们进入非常令人兴奋的闪电问答环节。第一个问题：你向别人推荐最多的两三本书是什么？

David Singleton： “最多”意味着你要对曲线下面积做积分，所以我会说 Andy Grove 的《高产出管理》（High Output Management）绝对是我推荐最多的书。这本书在整个职业生涯中真正让我大开眼界，教会了我如何让团队发挥最大效能。如果你还没读过，一定要去看看。我们之前谈到在工艺上精益求精。我很喜欢 Tony Fadell 的《构建》（Build）。Tony 参与了 iPod 的开发，然后是 iPhone，之后创办了 Nest。他在用户方面倾注了大量思考，致力于打造真正精良的体验。我有幸在 Google 与他短暂共事过，我认为这本书在提供实用指导方面非常出色。然后，如果我不提 Claire Hughes Johnson 的书《选对人》（Skilling People），那就太失职了。虽然这本书才刚出版，但我已经推荐了很多次。书里其实有一些我分享的我们在 Stripe 使用的方法，所以你可能会喜欢。另外如果可以的话，我想再分享一本……

Lenny： 我这里有一本。

David Singleton： 你也有了。

Lenny： ……它可以当支架……

David Singleton： 太棒了。

Lenny： ……撑着我的笔记本电脑，然后……

David Singleton： 希望你读过。

Lenny： 我请她上过播客。我读了，能翻多少翻了多少。

David Singleton： 嗯。

Lenny： 我现在没有在创业。我看到她上了《华尔街日报》十大畅销书榜单。

David Singleton： 没错，没错。书里有大量非常实用的建议，所以我经常推荐这本书。

Lenny： 最近最喜欢的电影或电视节目是什么？

David Singleton： 好吧，我要在这里耍个花招，因为我打算把这个问题理解为：你最近看过的最好的视频内容是什么？

Lenny： 当然可以。

David Singleton： 我爱上了用 YouTube 来了解飞速发展的 AI 领域。这非常有价值。Andrej Karpathy 有一系列非常好的讲座，但不仅于此。在整个频谱上，如果你想如今学习一项新技能，YouTube 上有太多宝贵的内容。

Lenny： 你推荐的频道就是 Andrej Karpathy 的频道吗？

David Singleton： 如果你想了解 AI，他的频道非常棒。

Lenny： 他是前 Tesla 的 AI 负责人？

David Singleton： 没错。我相信他最近去了 OpenAI，但在此之前自己做了几个月，产出了大量优秀的 YouTube 内容。

Lenny： 好选择。大多数人都选《白莲花》之类的，你选了一个 AI YouTube 频道。我很喜欢。你最喜欢问的面试问题是什么？

最喜欢的面试问题

David Singleton： 好的，其实你会发现这本书里有我推荐的一些面试问题。有一个我真的很喜欢，因为听起来像是一个简单的问题，但其实不然。我经常问人们——尤其是在招聘管理层时——他们共事过的领导者中最欣赏谁，为什么。听起来像个简单的问题，但实际上能告诉你很多关于这个人真正在乎什么样的领导力。

有时候，我会追问：“这如何体现在你自己的领导风格中？“然后，我认为这一步非常能说明问题——我总是问候选人，我要剧透我的面试题了，我要在你的播客上公开了——我总是问候选人：“好的，假设你是那个人的经理。请告诉我你会给他们写什么样的绩效评估或发展反馈，来帮助他们更有效率。“我认为每个人总有可以改进的地方，当然也包括我自己。一个人能否对某个他们相当崇拜甚至神化的人进行批判性思考，以及思考这个人如何才能真正更有效率，我觉得这一点非常能说明问题。

Lenny： 最近发现的喜欢的产品有哪些？

喜欢的产品

David Singleton： 我最近发现并肯定喜欢的产品是 Midjourney，他们的业务端也搭建在 Stripe 上。不了解的人可能不知道，Midjourney 是一个用稳定扩散（stable diffusion）生成图像的 AI 工具，但确实相当出色。我经常和我女儿一起用它。我们会构思故事，用 Midjourney 生成漂亮的图像，然后她把图片放进书里，自己写文字。我觉得它很酷的原因是，一开始我对它的 UI 非常惊讶和怀疑，因为它的 UI 就是 Discord。他们把你放进 Discord，你进入一个频道，必须在那里给 AI 写提示词。一开始我觉得很困惑。心想：这不是这个工具该有的界面。但实际上，这非常聪明，因为你可以从 Discord 上其他人那里学到他们如何给 AI 写提示词来获得自己想要的效果。我发现这让我能从这个工具中获得更多的能力和价值。我肯定订阅了 Midjourney，用得很开心。

Lenny： 你创建的图像中，最喜欢的是哪一幅？如果有一幅浮现在脑海中的话。

David Singleton： 我们给我女儿正在写的书做了一个封面。顺便说一下，我女儿九岁，所以我们这里说的是优秀的儿童故事。她做了一张图：一只穿着紫色天鹅绒斗篷的狼，坐在篝火前，身后是森林里的一间小屋和一片星云。非常漂亮。我们实际上是结合了两张图像做出来的——狼和小屋。把狼从一张图中抠出来放到另一张上，我们用了 Apple 新的图像分割复制粘贴功能，效果很好。把这些 AI 工具组合起来也很有趣，但那一张算是比较满意的。

Lenny： 真是个奇妙的世界。最后两个问题。你在产品开发流程中做了什么相对较小的改变，却对团队执行力产生了巨大影响？

David Singleton： 我们之前聊过一些这个话题——自动部署和自动合并功能。但可能影响最深远的做法是，我们在 Stripe 的每一个开发者工具中都放了一个小按钮，是一个哭泣的章鱼 emoji。点击它之后，你就可以直接输入哪里出了问题。然后我们的开发者生产力团队会阅读所有这些反馈，并据此排列工作优先级。这种毫无摩擦的问题记录方式，结果证明非常有价值。我们称之为 paper cuts（纸割伤）。

Lenny： 哭泣的章鱼，我喜欢这个。

David Singleton： 是的。

Lenny： 最后一个闪电问答：还有哪些来自 Stripe 或前 Stripe 的人应该请到播客上来？

David Singleton： 我知道你的套路了。

Lenny： 这不是套路。

David Singleton： 我觉得你应该请两位 Stripes。第一位是 Emily Sands，她是我们的首席经济学家，负责我们的信息组织。我觉得这个组织包括数据科学团队，也包括构建我们很多内部工具的团队。我认为 Emily 有一套很好的思维框架，能把用户的真实体验转化为一套出色的指标体系，然后驱动正确的行动。正如我之前所说的，这非常重要。

第二位是 Michelle Boo。Michelle 在非常非常早期的阶段就以工程师身份加入了 Stripe，和我们在一起显然已经很长时间了。在 Stripe 用来建模用户业务的核心抽象层面，她可以说是我们的首席产品设计架构师。我认为她对如何把这些东西做对有非常深刻的洞察。我觉得你会很享受和她的对话。

Lenny： David，非常感谢你抽时间来参加这次对话，尤其是在 Sessions 前这么忙碌的时期。最后两个问题：如果大家想联系你，了解更多你正在做的事情，在哪里可以找到你？还有，听众怎样才能帮到你？

David Singleton： 好的。我在 Twitter 上是 @DPS，这绝对是联系我的最佳方式。你也可以看看我的个人博客 blog.singleton.io。说实话，最有用的事情是请给我发 Stripe 的反馈。你可以在 Twitter 上发给我，我的博客上也有我的邮箱地址。我非常希望能听到我们怎样才能更好地为你服务。

Lenny： David，再次感谢你来做客。

David Singleton： 谢谢你，Lenny。这很有趣。

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

术语表

原文中文
AjhjaAjhja（Stripe 工程师，保留原文）
AlphaAlpha（指 Alpha 测试阶段用户群体，保留原文）
Andrej KarpathyAndrej Karpathy（保留原文）
Andy Grove安迪·格鲁夫（Intel 前CEO，公认译名）
APIAPI（Application Programming Interface，保留原文）
AtlasAtlas（Stripe 旗下的创业服务产品 Stripe Atlas，保留原文）
AtlassianAtlassian（全球知名 SaaS 公司，保留原文）
basis points基点（basis points）
be meticulous in your craft在工艺上精益求精
Build《构建》（Build）
Charlie BellCharlie Bell（前 Amazon 运营高管，保留原文）
ChatGPT PlusChatGPT Plus（OpenAI 的付费订阅服务，保留原文）
Claire Hughes JohnsonClaire Hughes Johnson（前 Stripe 高管）
CloudFlareCloudFlare（全球知名云服务与网络安全公司，保留原文）
cohort同期群（cohort）
CopilotCopilot（GitHub 的 AI 编程助手，保留原文）
David SingletonDavid Singleton（Stripe 工程高管，保留原文）
DiscordDiscord（通讯平台，保留原文）
EekeEeke（前 Stripe 员工）
embeddings嵌入向量（embeddings）
Emily SandsEmily Sands（Stripe 首席经济学家，保留原文）
Employer Identification Number雇主识别号（Employer Identification Number）
engineer occasions工程师演讲
engineercationengineercation（engineer 与 vacation 的混成词，指管理者深入一线团队做工程实践的机制）
FigmaFigma（设计工具公司，保留原文）
Fortune five / Fortune one财富十强/财富榜首（Fortune 排名）
friction logging摩擦日志
general availability正式发布（general availability）
global payments and treasury network全球支付与资金网络（global payments and treasury network）
GPT-4GPT-4（OpenAI 的大语言模型，保留原文）
High Output Management《高产出管理》（High Output Management）
IC个人贡献者（IC，Individual Contributor）
IRS国税局（IRS）
Jeff WeinsteinJeff Weinstein（Stripe 产品经理，保留原文）
JohnJohn（Stripe 联合创始人 John Collison，保留原文）
LennyLenny（播客主持人）
LinkLink（Stripe 的一键结账产品，保留原文）
LyftLyft（美国网约车平台，保留原文）
maker schedule创客日程（maker schedule）
Michelle BooMichelle Boo（Stripe 工程师/首席产品设计架构师，保留原文）
MidjourneyMidjourney（AI 图像生成工具，保留原文）
NestNest（智能家居公司，保留原文）
OpenAIOpenAI（AI 研究公司，保留原文）
operating principles运营原则（operating principles）
paper cutspaper cuts（Stripe 内部对开发者工具中小摩擦问题的称呼，保留原文）
PatrickPatrick（Stripe 联合创始人 Patrick Collison，保留原文）
payment elementpayment element（Stripe 的支付 UI 组件，保留原文）
PRPR（Pull Request，保留原文）
presets预设（presets）
prompt提示词（prompt）
RadarRadar（Stripe 的支付欺诈检测产品，保留原文）
SaaSSaaS（Software as a Service 的缩写，保留原文）
SessionsSessions（Stripe 的大会，保留原文）
ShopifyShopify（全球知名电商平台，保留原文）
Shreyas DoshiShreyas Doshi（前 Stripe 高管）
SigmaSigma（Stripe 的数据查询产品，保留原文）
Skilling People《选对人》（Skilling People）
SlackSlack（企业通讯平台，保留原文）
SQLSQL（结构化查询语言，保留原文）
stable diffusion稳定扩散（stable diffusion）
StripeStripe（知名在线支付平台，保留原文）
Stripe BillingStripe Billing（Stripe 的订阅和发票产品，保留原文）
Stripe CheckoutStripe Checkout（Stripe 的托管结账服务，保留原文）
Stripe ConnectStripe Connect（Stripe 的平台与市场支付产品，保留原文）
StripesStripes（Stripe 内部对员工的称呼，保留原文）
Tony FadellTony Fadell（保留原文）
TransformersTransformer（一种深度学习架构，保留原文）
walking the store走访一线
White Lotus《白莲花》（美剧，公认译名）

此文档由 AI 分片翻译（translate_long_document）