How to Build a Company OS in Claude Code | Jiaona Zhang | Product Growth

频道: Aakash Gupta
视频: https://www.youtube.com/watch?v=qsDX0PMKcaE
原文语言: en
统计: 共 71 轮 · JZ 39 · Aakash 30

[0:00] JZ

You got these people who are these 1% AI users. They're highly AI pilled. And then you have the 90 to 99% of the rest of the organization who isn't sure what to use when.

公司里总有那么 1% 的人是重度 AI 用户，已经完全「AI 上头」了。但剩下 90% 到 99% 的组织成员，根本搞不清楚什么时候该用什么工具。

[0:09] Aakash

Meet Jay-Z. She's the chief product officer at Luro, the $100 AI time platform. She teaches PM at Stanford. Before Jay-Z, she was the CPO at Linktree, and she's led product at Airbnb, Webflow, Dropbox, and WeWork.

来认识一下 JZ。她是 Luro 的首席产品官——一家规模上亿美元的 AI 平台。她还在斯坦福教产品管理课。在此之前，她是 Linktree 的 CPO，也曾在 Airbnb、Webflow、Dropbox 和 WeWork 负责产品。

[0:24] Aakash

something pretty crazy in your interviews. Can you tell me how you interview people and really find these damn AI pale super IC PM?

你们的面试方式相当疯狂。能讲讲你是怎么面试候选人，真正找到那种「AI 上头」的超强 IC 型 PM 的吗？

[0:32] JZ

The fundamentals and the principles have never changed. In fact, they're even more important than ever before, but the tools and the way you operate, that's radically changed.

产品的基本功和底层原则从来没变过，甚至比以往任何时候都更重要。但工具和你的工作方式，已经发生了根本性的变化。

[0:42] Aakash

How should people be thinking about in an AI native organization? This is the role of a PM.

在一个 AI 原生的组织里，大家应该怎么理解 PM 这个角色？

[0:47] JZ

And so those are the four levels. Level one is you're talking to ChatGPT, you're talking to Claude. You're really using AI kind of in chat mode. Level two is where you start to automate a workflow. Level three is when you start building, you know, apps. And then level four I'd say is where you're actually building I call them shared apps.

所以就是这四个层级。第一层，你在跟 ChatGPT 或 Claude 聊天，基本是在用 AI 的对话模式。第二层，你开始把某个工作流自动化。第三层，你开始搭建应用（app）。第四层，我认为是你真正在构建我称之为「共享应用」的东西。

[1:02] Aakash

How does someone start from step one? What is the process somebody needs to go through in order to build up and create their own company operating system? Before we go any further, do me a favor and check that you are subscribed on YouTube and following on Apple and Spotify podcasts. And if you want to get access to amazing AI tools, check out my bundle. Where if you become an annual subscriber to my newsletter, you get a full year free of the paid plans of Maven, Arise, Relay App, Dovetail, Linear, Magic Patterns, Deep Sky, Reforge, Build, Descript, and Speechify. So be sure to check that out at bundle.akashg.com, and now into today's episode. Jay-Z, I've been teaching people a lot about how to use Claude code with personal operating systems, with team operating systems. You guys at Luro have taken it to a level I have not seen before. You guys have built out a company operating system. Can you show me what this is and what it does?

一个人该怎么从第一步起步？要一步步搭出属于自己的公司操作系统（Company OS），需要经历怎样的过程？在继续之前，帮我个忙：确认你已经在 YouTube 订阅了本频道，并在 Apple 和 Spotify 播客上关注了我们。如果你想获得一批超棒的 AI 工具，可以看看我的工具捆绑包：只要成为我 newsletter 的年费订阅者，就能免费获得一整年 Maven、Arise、Relay App、Dovetail、Linear、Magic Patterns、Deep Sky、Reforge、Build、Descript 和 Speechify 的付费版。地址是 bundle.akashg.com。现在进入今天的正题。JZ，我一直在教大家怎么用 Claude Code 搭建个人操作系统、团队操作系统。而你们 Luro 把这件事做到了我从没见过的高度——你们搭出了一整套公司级操作系统。能给我演示一下这是什么、能做什么吗？

[2:04] JZ

Of course. All right, let me screen share here. Okay, let's start here. Let's go to GitHub, our favorite place. And so you'll see here that we have in GitHub a company-wide operating system where for every single function in a company, customer success, data science, design, engineering, finance, imitation, legal, marketing, we have um essentially all these folders that share how do you think about each phase of work that that function does. So in customer success, you do account management. And within account management, you're thinking about, you know, renewals, upsells. Um you do a customer enablement. And within that, we essentially work with our customers, we do office hours. We help them with roll out. We do training and onboarding. Each of these folders have a skill. And I think uh for those of you who are less familiar with GitHub, we'll actually hop over here to something that is very familiar, which is essentially your file structure, your folder structure. And so going to customer success, you can see that each of these folders have a series of um you know, folders that are the are the activities that they do. And then within each of them, they have skills. So how do you actually think about creating the right assets for the negotiation support or the right references? I'll go back one more. Um for renewals, right? Um what is the skill file there to really think about how do you walk through a renewal correctly with a customer? And now you're like, okay, cool, you have some folders in GitHub, you have, you know, some some stuff that you can download. How does this all come to drive like real change? And the way I'll talk about this is, you know, at the end of the day, we all live in some form of email or Slack. And so what I'll do really quickly is I'll open up my Slack.

当然可以。好，我来共享一下屏幕。我们从这里开始，先去我们最爱的地方——GitHub。你可以看到，我们在 GitHub 上有一个覆盖全公司的操作系统：公司里的每一个职能——客户成功、数据科学、设计、工程、财务、实施（implementation）、法务、市场——我们都有对应的文件夹，沉淀了这个职能每个工作阶段该怎么思考。比如在客户成功里，你要做客户管理（account management），客户管理下面又包括续约、增购这些事。还有客户赋能（customer enablement），在这块我们会跟客户一起工作、开 office hours、帮他们做产品推广落地、做培训和 onboarding。这些文件夹里每一个都有一个 skill。对不太熟悉 GitHub 的朋友，我们切换到一个大家都熟悉的东西——其实就是你电脑上的文件结构、文件夹结构。进到客户成功这个目录，你会看到每个文件夹下面又是一系列子文件夹，对应这个职能实际做的各项活动，而每一项里面都放着 skills。比如：怎么为谈判支持（negotiation support）准备合适的材料，怎么找对参考案例？我再退回上一级——比如续约（renewals），这里的 skill 文件就是教你：怎么正确地和客户走完一次续约流程。看到这你可能会想：好吧，你们在 GitHub 上放了些文件夹，有些东西可以下载，但这一切到底是怎么带来真正的改变的？我想这么解释：说到底，我们每个人的日常都活在邮件或 Slack 里。所以我现在快速打开一下我的 Slack。

[3:55] JZ

And again, this is not real data in the sense that we do have very sensitive data that I'm not going to be be sharing. So, this is a little bit more mock, but it shows you exactly how our how our team operates. So, for example, every single morning every person on a lot of these customer-facing teams, right? They're highly repeatable motions, the more we can sing from one voice and say the same thing the way we can create consistency in the awesomeness of the customer experience, that makes your company, you know, much more unified and it's a big part of the brand. And so, when you think about that and you think about a customer success person waking up in their day and really seeing, let me go here. This is a example for customer success. Here's your calendar. Here are all the meetings that you have, the check-ins that you have, you know, the onboarding sessions you have. This is something that a lot of people are building. This is a example of a chief of staff light concept, but what we're now doing is we're integrating all the skills. So, for example, when we do a handoff, when we do a session prep, all of these are actual skills. And what happens is then when anyone is using Claude, for example, I'll just go into I'll go I'll go really quickly into the organization settings and I go into your skills. You can start to see that you can upload all of these skills into your company context. And as a result, when you're going through your day, you can essentially say, "Great. I'm going through my day. I'm doing all these things. My I will use these skills so that I no longer have to spend all the time creating that one deck or spend all that time creating an email. It is actually something You know exactly what skill to use when. And I think that's the biggest thing that companies struggle with, which is you got these people who are these 1% AI users. They're tinkering with their workflows. They're highly AI piled, and then you have the, you know, 90 to 99% of the rest of the organization who isn't sure what to use when. And so, as a result, you can actually integrate your skills, again, at a company level. So, across every single one of these functions, going back to files, each one of these functions and all the activity that they do in order to be able to understand what, um, skill should I should I be using when, and where should I be spending my time? Maybe the last thing I'll just show to kind of, uh, to really bring this to life is every single company, you can map every single function's work to what I call an ontology. So, in sales, you know, all of

再说明一下，这里不是真实数据——我们有非常敏感的数据是不会拿出来分享的，所以这是偏演示性质的 mock 数据，但它能准确展示我们团队的实际运作方式。举个例子：每天早上，这些面向客户的团队里的每一个人——他们做的都是高度可复用的动作。我们越能统一口径、说同样的话，就越能在客户体验的出色程度上做到一致，公司就越显得步调统一，这也是品牌的重要组成部分。带着这个思路，想象一个客户成功同事早上开始一天的工作，他看到的是——我点进来——这是客户成功的示例：这是你的日历，这是你今天所有的会议、客户 check-in、onboarding 环节。这类东西很多人都在做，算是一个轻量版「幕僚长（chief of staff）」的概念。但我们现在做的是把所有 skills 都集成进来。比如做交接（handoff）、做会前准备（session prep），这些全都是实实在在的 skills。接下来，当任何人在用 Claude 的时候——我快速进一下组织设置，打开 skills 页面——你可以看到，这些 skills 全部都能上传到你的公司上下文里。结果就是，你过一天的时候可以直接说：「好，我今天要做这些事，我会调用这些 skills」，你再也不用花大把时间去做那一份 deck、写那一封邮件了——系统清楚地知道什么时候该用哪个 skill。我认为这正是各家公司最头疼的地方：你有那 1% 的重度 AI 用户，天天折腾自己的工作流，完全「AI 上头」；但剩下 90% 到 99% 的组织成员，根本不知道什么时候该用什么。所以，你可以把 skills 集成到公司层面——回到文件目录，覆盖每一个职能、以及他们做的所有活动，让每个人都明白：我什么时候该用哪个 skill，我的时间该花在哪里。最后我再展示一个东西，把这一切真正串起来：每家公司都可以把每个职能的工作映射到我称之为「本体论（ontology）」的东西上。比如在销售这边，所有……

[6:24] JZ

the work in sales maps to these categories that they're supposed to be doing. And within each category, there are series of tasks that happen. And this is actually what has informed the ontology that I just showed you. We've done the really hard work of mapping out, okay, for every single function, again, I'll scroll through this. Marketing, sales, customer success, implementation, design, engineering, so on and so forth. These are the things that we believe that each function should be doing. How do we actually create, um, a set of skills to for for you to, um, do the things that we want you to be doing more, and to also automate the things that we don't want you to be doing anymore. So, I'll go to product, which is, you know, a lot of the audience here today. In product, what's really interesting is that, you know, you should be spending your time like an engineer in many ways. And we talk about this later where, you know, the ontology or the work map of a product manager is starting to look look a lot more like an engineer. But there are a lot of things that used to be in the, um, day-to-day of a product manager, doing competitive market analysis, doing these all these like, writing for stakeholder management, or, um, really mundane, tedious organization, um, getting people on a phone, synthesizing, um, feedback, etc. All of these things, as we all know, are starting to get automated. But again, it's automated in a really lumpy way, where one PM might be doing a really, really well and other p.m. I might not be doing it as well. So, what we can do here is when you onboard everyone with a company OS, again going back to this GitHub, and going to, let's say, product, right? Um you can start to say, "Hey, these are all the playbooks, all the skills that I want to give every single person on my team." And then, when they come in for their daily briefing, what ends up happening is that they are able to see their day at a glance, and we essentially tell you where you can automate your day. So, you take the thing that is a that is essentially designed by the 1% of of every any given function, the person who is playing around the most, and are able to spread those learnings throughout the entire rest of the organization.

……销售的全部工作都会映射到他们应该做的这些类别上，而每个类别下面又有一系列具体任务。这其实就是我刚才给你们看的那套 ontology 的底层依据。我们做了非常扎实的苦功夫，把每一个职能都梳理了一遍——我滚动给你看：市场、销售、客户成功、实施、设计、工程等等——这些就是我们认为每个职能应该在做的事。然后我们再去构建一整套 skills：让你把我们希望你多做的事做得更多，同时把我们不希望你再做的事自动化掉。我们来看产品（product）吧，毕竟今天的观众很多都是做产品的。产品这块特别有意思的一点是：在很多方面，你的时间应该花得越来越像一个工程师——我们后面还会聊到，产品经理的 ontology 或者说工作地图，正在变得越来越像工程师。但过去 PM 日常里的很多事情：做竞品和市场分析、写各种干系人管理的材料、那些特别琐碎乏味的组织协调工作、约人打电话、整合反馈等等——众所周知，这些都在被自动化。但问题是，这种自动化非常「不均匀」：某个 PM 可能做得特别好，另一个 PM 可能就做得很差。而我们在这里能做到的是：当你用公司 OS 给所有人做 onboarding 时——还是回到这个 GitHub，进到比如 product 这个目录——你可以说：「这些就是我想交给团队里每一个人的全部 playbook、全部 skills。」然后当他们每天打开自己的 daily briefing 时，就能一眼看清今天的安排，我们还会直接告诉你：你的一天里哪些环节可以自动化。相当于你把每个职能里那 1% 玩得最溜的人设计出来的东西，铺开传播到组织里其余所有人身上。

[8:25] Aakash

Wow. I think this is so powerful because we all have been working in different teams where there's that one person who's got their skills locked, but if they're just compounding in a bucket, then nobody can really benefit. This company OS, this is bringing that power to everybody. Now, you guys are an AI-native company. You guys are an AI company yourselves, and so you guys would have certain advantages in building this. How does someone start from step one? What is the process somebody needs to go through in order to build up and create their own company operating system?

哇，我觉得这太强了。我们都经历过这样的团队：总有那么一个人把自己的技能修炼得炉火纯青，但如果这些积累只沉淀在他一个人的桶里，其他人就完全受益不到。而这套 Company OS 是把那份能力带给了所有人。不过，你们本身是一家 AI 原生公司，你们自己就是做 AI 的，所以在搭这套东西上肯定有先天优势。那普通人该怎么从第一步开始？要搭建出自己的公司操作系统，具体需要走怎样一个过程？

[9:00] JZ

I like to think about it as three different steps. And so, let me screen share again, and I will um share how do I think about essentially um getting your steps in, going from most simple to most advanced. So, the first way to think about this is, how do you just start small? What is one workflow that you or your team does that is incredibly tedious that you shouldn't be doing again? So, typically, for many, many functions, it is, you know, I write this email, and I want this email to have a template that is automatically, you know, um kicked off for me when um XYZ things happen, or there's a sequence of things that happen. I don't want to input um my data into our CRM anymore. I want that to be automated. So, there's some degree of thinking about what is super mundane, takes a lot of time out of your day-to-day, and if that were to be automated away, you'd be thrilled about. And I'll give you one very product-oriented example, which is there are so many companies out there, so many PMs out there that spend a lot of their days responding to questions, escalations. So, the sales team comes into a channel

我喜欢把它拆成三个步骤。我再共享一下屏幕，讲讲我是怎么想的——怎么循序渐进，从最简单走到最高级。第一步的思路是：怎么从小处着手？找出你或你的团队正在做的、极其繁琐、根本不该再亲手做的某一个工作流。对很多职能来说，典型的例子是：我总在写这封邮件，我希望有个模板，在某某事件发生、或某个事件序列发生时自动帮我生成；或者，我不想再手动往 CRM 里录数据了，我希望这一步自动完成。总之就是想清楚：什么事情特别机械、特别占用你的日常时间，如果能被自动化掉你会开心得不得了。我举一个非常产品向的例子：外面有太多公司、太多 PM，每天花大量时间在回答各种问题和处理 escalation 上。比如销售团队跑到某个频道里来……

[10:05] Aakash

I'm notoriously bad at my inboxes. I guess there's a version of that where I seem cool and unavailable, but the reality is I miss sponsor emails, guest pitches, and stuff that my team actually needs me [music] for. So, I got an AI assistant, the sponsor of today's episode, Arise. Arise connects to my email, calendar, and [music] Slack. Then I just chat with it over Slack, and it helps me with everything. It builds workflows to respond to emails, resolve [music] customer issues, prep me for meetings. It actually comes to my meetings,

我处理收件箱的水平是出了名的差。往好了说，这显得我很酷、很高冷；但现实是，我会漏掉赞助商的邮件、嘉宾的自荐，还有团队真正需要我处理的事。所以我请了一个 AI 助理——也就是本期节目的赞助商 Arise。Arise 连接了我的邮箱、日历和 Slack，我只需要在 Slack 里跟它聊天，它就能帮我搞定一切：搭建工作流来回复邮件、解决客户问题、帮我做会前准备。它甚至会真的参加我的会议，

[10:33] Aakash

[music]

[音乐]

[10:33] Aakash

updates its own notes, and remembers context from past conversations. So, every time I talk to it, it already knows what I'm working on.

自己更新会议笔记，还能记住过往对话的上下文。所以每次我跟它对话，它都已经知道我手头在忙什么了。

[10:41]

[music]

[音乐]

[10:41] Aakash

I used to pay for Granola and Lindy separately. Arise replaced both. One tool does more, and it lives right in Slack where I already work. [music] Check it out at arise.ai/akash. That's a r i s o dot a i slash a a k a s h.

我以前是分别付费用 Granola 和 Lindy 两个工具的，现在 Arise 一个就把两者都替代了。一个工具能做的更多，而且它就直接住在 Slack 里——我本来就在那儿办公。[音乐] 去 arise.ai/aakash 看看吧，拼写是 a-r-i-s-e 点 a-i 斜杠 a-a-k-a-s-h。

[10:55] Aakash

Here's the dirty secret about prototyping. You spend two weeks building a prototype, you validate your assumptions, engineering loves the direction. Then what happens? You throw the whole thing away. Bolt changes this completely. When you prototype in Bolt, you're not building throwaway mock-up. You're building real front-end code that integrates with your existing design system. So, when you hand it to engineering, they don't throw it away, they ship on top of what you've built. I use Bolt every single day. I host my land PM job cohort on it, and honestly, I'm up till 2:00 a.m. some days just vibing in the tool, having fun, and building. That's when you know a product is good. When you're using it past midnight not because you need to, but because you want to. Check out bold at bold.new/akash. That's b o l d . n e w / a a k a s h. Link in the show notes. Today's podcast is brought to you by Pendo, the leading software experience management platform. McKinsey found that 78% of companies are using gen AI, but just as many have reported no bottom line improvements. So, how do you know if your AI agents are actually working? Are they giving users the wrong answers, creating more work instead of less, improving retention, or hurting it? When your software data and AI data are disconnected, you can't answer these questions. But, when you bring all your usage data together in one place, you can see what users do before, during, and after they use AI. Showing you an agent's work, how they help you grow, and when to prioritize on your road map. Pendo agent analytics is the only solution built to do this for product teams. Start measuring your AI's performance with agent analytics at pendo.io/akash. That's p e n d o . i o / a a k a s h.

关于做原型，有个不太光彩的秘密：你花两周做出一个原型，验证了假设，工程团队也很认可这个方向。然后呢？整个原型直接扔掉。Bolt 彻底改变了这一点。在 Bolt 里做原型，你做的不是用完即弃的 mock-up，而是真正的前端代码，能和你现有的设计系统集成。所以交给工程团队时，他们不会扔掉，而是直接在你搭好的基础上继续开发上线。我每天都在用 Bolt——我的 Land PM Job 训练营就跑在上面。说实话，有些天我会一直玩到凌晨两点，纯粹在工具里 vibe、找乐子、搭东西。一个产品好不好，就看这个：你半夜还在用它，不是因为不得不用，而是因为想用。去 bolt.new/aakash 看看，拼写是 b-o-l-t 点 n-e-w 斜杠 a-a-k-a-s-h，链接在节目备注里。今天的播客还由 Pendo 赞助——领先的软件体验管理平台。McKinsey 发现 78% 的公司在用生成式 AI，但同样多的公司报告说对利润毫无改善。那你怎么知道你的 AI agent 到底有没有在起作用？它们是不是在给用户错误答案、制造了更多工作而不是减少工作？是在提升留存还是在伤害留存？当你的软件数据和 AI 数据彼此割裂时，这些问题你都答不上来。但当你把所有使用数据汇聚到一个地方，你就能看到用户在使用 AI 之前、之中、之后都做了什么——让你看清 agent 的工作成效、它们如何帮你增长、以及路线图上该优先做什么。Pendo 的 agent analytics 是唯一为产品团队打造的这类解决方案。现在就去 pendo.io/aakash 用 agent analytics 开始度量你的 AI 表现，拼写是 p-e-n-d-o 点 i-o 斜杠 a-a-k-a-s-h。

[12:30] JZ

Okay, so let's move into Slack and see what this might look like. You know, a lot of companies, if you just go into any ask product channel or any channel, you see so many um success folks, um support folks, sales folks, um other teams hitting up that channel asking people, "Hey, I have a question. I have a feature request." And so, the very small workflow that we did, and I'll go all the way down, is we created a Slack automation that essentially said, "Look, when a feature request comes in, we typically spend a bunch of time going back and forth asking about how many times was this asked about, send me the gong recording where I could watch what the customer's actually saying, um what is the impact of this for your customer, which requires some degree of judgment from the person managing the account, um what is actually going on here, give me some more details." All of those things usually require back and forth. So, again, if I go back to this this system of how do you think about a place to start? What is something that you do over and over again that you could really easily automate. And that automation for us was as simple as, "Hey, let's just automate what we ask someone to fill in. And then what often happens is you then have to triage it. You say, 'Hey, you know, is it for this team or that team? Is it for this PM or that PM? And what's the SLA to getting back to the requester on what we're doing about this feature request?'" And so all of that you can build into something as simple as Slack. So again, a lot of people have Slack, Teams, whatever it is you're using to chat with your teams. You can do something very simple where you essentially say, "Okay, great. I come in here. I'm going to automatically ask for all of this information. So, you know, what is it?

好，那我们进到 Slack 里，看看这在实际中长什么样。你知道，很多公司只要点进任何一个 ask-product 频道或者随便哪个频道，都会看到一大堆客户成功、客服支持、销售等其他团队的人在里面刷屏提问："嘿，我有个问题""我有个功能需求"。所以我们做的第一个很小的工作流——我往下拉给你看——就是建了一个 Slack 自动化。逻辑是这样的：一条功能需求进来后，我们通常要花大量时间来回拉扯地问：这个需求被问过多少次了？把 Gong 的录音发给我，我要听听客户到底是怎么说的；这对你的客户影响有多大？——这需要管理这个客户的人做一定的判断；到底发生了什么，再给我一些细节。所有这些通常都得靠来回沟通。所以再回到我说的那套体系：怎么找切入点？就是找那件你反反复复在做、又很容易自动化的事。对我们来说，这个自动化简单到就是："把我们要求别人填写的信息自动化掉。"接下来通常还要做分诊（triage）：你得判断"这归这个团队还是那个团队？归这个 PM 还是那个 PM？我们答复需求方、告诉他们打算怎么处理这条功能需求的 SLA 是多少？"——所有这些，都可以搭在 Slack 这么简单的东西上。再说一遍，大多数人都有 Slack、Teams 或者别的团队沟通工具。你可以做一件非常简单的事："好，需求进来，我自动把这些信息全问一遍——这是个什么需求？

[14:07] JZ

Who is it coming from? What's going on here?" It automatically assigns it to the person that makes the most sense to go look at this. And then it automatically creates some kind of ticket so that we can track it. And so all of that, again, this is 101, I would say, right? It's just like a very small step in in creating your operating system. So, I start there. The next step is this idea of how do you start to really automate based on a bunch of things that your team is doing. And so the example here I have is, you know, again, a team that usually has a lot of people, a lot of humans. At Laurel, we have a large, you know, GTM team. And within GTM, go-to-market, we have really awesome success folks who are essentially, you know, what I call like time consultants. They're getting kind of forward deployed into these organizations, helping them use Laurel as a as a product. And so what we've done is we've essentially created a playbook. And again, this is very, very long. I think anyone who's ever created a playbook before, this is 50 pages. It covers everything from implementation to onboarding to user onboarding. And and depending on who you are, is it the admin, is it the actual timekeeper, etc. You know, different onboarding. These things, by the way, are very fast now with Claude. You can actually create this from a lot of sources and have it be written really quickly. But what the struggle most companies has is now that I've created a playbook, how do I actually get people to do the playbook? And how much of the playbook is actually done by the human versus actually done by, you know, agents or workflow automations, right? And so this is where, again, going back to this concept of of the playbook um model, this is where you can say, "Okay, well, I've created a playbook. I've went through and I've audited the things that, again, it requires a human to do.

是谁提的？具体什么情况？"然后它会自动把需求分配给最合适去跟进的人，再自动创建一个工单方便追踪。这些说白了都是入门级的，对吧？只是搭建你的 operating system 的很小一步。我就从这里起步。下一步，就是如何基于团队正在做的一大堆事情，开始真正深度地自动化。我这里的例子是这样的：一个通常有很多人的团队。在 Laurel，我们有一个很大的 GTM（go-to-market）团队，其中有一批非常出色的客户成功同事，他们本质上是我所说的"时间顾问"，相当于被前置部署（forward deployed）到客户组织里，帮助客户用好 Laurel 这个产品。我们做的事情，就是给他们创建了一份 playbook。再说一次，这份东西非常非常长——做过 playbook 的人都懂——足足 50 页，从实施、上线到用户 onboarding 全都覆盖，而且根据你的角色不同——是管理员、还是实际记录时间的人等等——onboarding 内容也不同。顺带说一句，这类东西现在用 Claude 做非常快，你可以从大量素材里快速把它写出来。但大多数公司卡住的地方在于：playbook 建好了，怎么让人真的去执行？playbook 里有多少是真的该由人来做，又有多少其实可以交给 agent 或工作流自动化？所以这就回到 playbook 模型这个概念：你可以说，"好，playbook 我建好了，我逐条审过一遍，标出哪些确实需要人来做——

[15:51] JZ

It requires a human to get on the phone with someone. It requires a human to go fly on site. Um but here are the things that we think we can automate." This is either um something we can productize or this is something that we can create an agent to do. And so that is, I would say, the the next step that you graduate to, where you essentially create a playbook and then off of the playbook you decide on a set of skills. And And that's, by the way, where we um we started to to get the first version of the OS I showed you earlier. When we went into customer success and we said, "What are all the things that someone might be doing?" These large buckets. It was largely off of playbooks. The playbooks for implementation, the playbooks for um activating a customer, the playbooks for really um talking to them the right way to make sure that they're set up for success. And so that is really the the second way to think about it. And um maybe I'll share one thing here, which is there are a lot of um agent builders out there today in the world. So you could use, you know, Claude itself. They've launched, obviously, a lot of um agents. You can use um uh a lot of things from Open AI as well. You can use a Glean. You can use a Dust. We at Laurel use Dust. And so I'll take a moment to see if this loads.

比如需要人去打电话，需要人飞到客户现场。但这些是我们认为可以自动化的部分"——要么把它产品化，要么建一个 agent 去做。所以我会说，这就是你进阶到的下一步：先建一份 playbook，然后基于 playbook 决定出一组 skill。顺便说，这也正是我们最初做出前面给你看的那版 OS 的起点。我们当时走进客户成功团队问："一个人可能在做的所有事情有哪些？"那些大的分类桶，很大程度上就是从 playbook 里来的——实施的 playbook、激活客户的 playbook、以及如何用正确的方式与客户沟通、确保他们走向成功的 playbook。这就是第二种思考方式。这里我再分享一点：如今世面上有很多 agent 构建工具。你可以直接用 Claude 本身——他们显然已经推出了很多 agent 能力；也可以用 OpenAI 的很多东西；可以用 Glean，可以用 Dust。我们 Laurel 用的是 Dust。我等一下看看这个页面能不能加载出来。

[16:59] Aakash

So if somebody hasn't heard of Dust, yeah, this is an agent building tool?

如果有人没听说过 Dust——这是一个 agent 构建工具，对吧？

[17:03] JZ

This is an agent building tool. And what we find is often a lot of the um things that someone does can be turned into a series of repeatable steps that gets automatically triggered. And so a great example, and I'll just go scroll down here really quickly. All of these are agents that we have built. So, going back to the the playbook concept, if you say, "Hey, I have a playbook of all the things that you need to be doing here." And again, 55 pages worth, I don't think anyone's going to read anything here. What we can start to do is go into an agent builder and say, "I'm going to create an agent for each of these steps." If I have to draft emails a lot as a customer success manager, if I have to actually scrape LinkedIn a lot as a salesperson, if I have to look at the market as a salesperson, or think about prospecting questions, each of these can be you can build an agent for each of the um parts of the workflow here. And then going back to really thinking about how does everyone engage with your operating system thoughtfully? No one's going to remember that they're going to call the specific agent that's going to do the email, and the specific agent that's going to do the RFP. The the big learning that we've had is how do you create a wrap like a like a mega agent, something like the like a a go-to-market agent that can be called by the sales team at any point, by the success team at any point, and then that agent is able to route the ask, the the need, or the help to whatever one of these sub-agents that is actually useful. And then going back to like it really the delivery piece is so important. Even the friction of coming to something like a different interface, coming to a desk and asking it questions, is is really low. In- instead, actually going into your um your Slacks, your emails, and delivering people um just-in-time playbooks and automations is really the way to go to get to the point where you're you're actually getting people to use the agents and the workflows that you've built.

对，这是个 agent 构建工具。我们发现，一个人日常做的很多事情，往往都能拆成一系列可重复的步骤，并且能被自动触发。举个很好的例子——我快速往下滚动一下——这些全都是我们已经搭好的 agent。回到 playbook 那个概念：如果你说"嘿，这份 playbook 涵盖了你在这里要做的所有事"，而且它有 55 页，我不觉得有人会真的去读。那我们可以做的是，进到 agent 构建工具里说："我要为其中的每一个步骤建一个 agent。"如果我作为客户成功经理经常要起草邮件，如果我作为销售经常要抓取 LinkedIn、要看市场行情、要想 prospecting 的问题——工作流里的每一个环节，你都可以为它建一个 agent。然后再回到那个问题：怎么让所有人都能顺畅地使用你的 operating system？没有人会记得：写邮件要调用这个特定的 agent，做 RFP 要调用那个特定的 agent。我们最大的一个心得是：怎么做一个包装层，一个"超级 agent"——比如一个 go-to-market agent——销售团队随时可以调用它，客户成功团队也随时可以调用它，然后由这个 agent 把请求、需求或者求助路由到底下真正有用的某个子 agent 上。然后再回到交付这一环，它真的太重要了。哪怕只是让人切换到另一个界面、跑到一个工作台前去提问，这点摩擦（门槛其实很低）都会挡住人。相反，直接进到大家的 Slack、邮箱里，把 just-in-time 的 playbook 和自动化送到他们面前，才是真正让人用起来你搭建的这些 agent 和工作流的正确路径。

[19:01] Aakash

So, help me understand this part. Why use Dust instead of just all Claude or Claude code?

那帮我理解一下这部分：为什么要用 Dust，而不是全部用 Claude 或者 Claude Code？

[19:07] JZ

Yeah, that's a great uh question. We started using Dust back in fall of last year. And so I think there was just a maturity of the tools. Um back then, it was just much easier to use something that specialize in agent building like a Glean or a Dust. I do think today there's um that gap is shrinking quite rapidly. And so as a result, I don't think you need to go out there and buy a specialized tool that does these. And in fact, you can just build them in Claude. Um and and this is actually a little bit where we're going, which is um if I go back to the operating system that I was showing you earlier. And all of these no longer have to go through a Dust or a Claude. Um instead, what we're able to do, make this much larger, is we can we can take all of these skill files and go into Claude itself and put them in as skill files. And so as a result, you could um now you can literally just say, "Hey, I'm inside whatever it is I'm doing, and I can just call the, you know, that skill /morning briefing product." And as a result, it gives me my briefing right there as opposed to me having to go and call an agent builder.

嗯，这是个好问题。我们是去年秋天开始用 Dust 的。我觉得当时主要是工具成熟度的问题——那时候，用 Glean、Dust 这类专门做 agent 构建的工具要容易得多。但我认为今天这个差距正在迅速缩小。所以现在你其实不需要专门去买一个做这些事的专用工具，完全可以直接在 Claude 里搭建。而且这其实也正是我们的走向：回到我刚才给你看的那个 operating system——这些东西都不再需要经过 Dust 或者某个中间层了。我们能做的——我把它放大一点——是把所有这些 skill 文件直接放进 Claude 本身，作为 skill 文件装进去。这样一来，你就可以在做任何事的过程中直接说："嘿，我调用一下那个 skill——/morning-briefing-product"，它当场就把简报给我，而不用我再跑去调用一个 agent 构建工具。

[20:13] Aakash

Mhm. And then should people be setting up like Claude automations on top of these to be running these as your daily morning like running on a schedule or something like that?

嗯哼。那大家应该在这些 skill 之上再设置 Claude 的自动化吗？比如让它们按日程定时跑，作为你每天的晨间简报之类的？

[20:23] JZ

Yeah, that's a great question. It's so funny. Um I'll go I'll share a little bit of my personal experience. So I set up a bunch of these scheduled things. And even if I just go to scheduled, um I'll go right here. You can see that I have a lot of these scheduled tasks. And you only see a couple of these pinned. And what I found was that um I it was almost overkill. It was like I sat there. I was like, "Oh, I might automate this." And so I built it. I was like, "Oh, I might automate that." And so I built it. I was like, "That might be interesting information." I built it. And actually I think we're in a world where we are we have information overload. And so this is why we took the time as a company to be like, "We can't just assume that people, first of all, that they're going to do this for themselves. And second of all, that they're not going to be overwhelmed by the number of like automations and you know schedule things that happen. And as a result, that's how we consolidated it all into what I was showing you earlier, which is this this idea of actually having all in one place, because the chances that you're going to come back and say, "Okay." And again, this is this is this is also to to make sure that the information or like the adoption of AI is actually consistent across the org. And that's the main thing. I think that you see a lot of let's say PMs be super AI native, a lot of engineers be super AI native. You don't see the same across all the functions and potentially sometimes they go to market functions. And so, as a result, we really think hard about how do we deliver that to you in the form of something that you can look at on a daily basis and really be integrated with your workflow. And the last thing I'll share at Laurel is we think a lot about how do we surface it even more just in time. And what we're able to do in terms of our product is we're able to detect what it is you're working on when.

对，这是个好问题。说来好笑，我分享一点我的个人经历。我自己设置了一大堆这种定时任务。你看，我点进 scheduled 这里——就在这——能看到我有非常多的定时任务，但真正置顶的只有那么几个。我后来发现，这几乎是过度了。我当时就坐在那儿："哦，这个可以自动化"，于是建了一个；"哦，那个也可以自动化"，又建了一个；"这信息可能有点意思"，又建了一个。而实际上我认为我们正处在一个信息过载的世界里。这也是为什么我们作为一家公司专门花时间去想清楚：第一，不能假设每个人都会自己去搭这些东西；第二，不能假设他们不会被海量的自动化和定时任务淹没。于是我们才把这一切整合成了我之前给你看的那个东西——就是"全部集中在一个地方"的理念，因为指望大家自己回头一个个去看的概率很低。而且再说一次，这也是为了确保信息——或者说 AI 的采用度——在整个组织里是均匀一致的。这是最核心的一点。你会看到很多 PM 非常 AI native，很多工程师非常 AI native，但并不是所有职能都这样，有时候 GTM 职能就未必。所以我们认真思考的是：如何把这些以一种你每天都会看、并且深度融入你工作流的形态交付给你。最后再分享一点 Laurel 的做法：我们花很多心思研究如何把它做得更加 just-in-time。就我们产品的能力而言，我们能检测出你在什么时间正在做什么工作。

[22:04] Aakash

Okay, so I think I get it, right? The thing that you are encoding that's most important is not the scheduled tasks or this particular interface in Dust, it is the actual skills and you are enabling the least AI proficient people at your company to operate at a similar level to those AI native people. What is the right company culture? How do you really get people to take advantage of a company OS like this?

好，我想我明白了，对吧？你们真正沉淀下来的最重要的东西，不是那些定时任务，也不是 Dust 里的这个特定界面，而是那些实实在在的 skill——你们让公司里最不擅长 AI 的人，也能达到接近那些 AI native 员工的水平。那什么样的公司文化才是对的？你到底怎么让大家真正用起来这样一套 company OS？

[22:29] JZ

Yeah, absolutely. I think it really starts with culture. I just have a few photos from our offsite about 3 months ago. And it's really important to for it to start from the top, from leadership to say, "This is so important to us. It is not just an engineering thing. It is a cross-company thing." And what we did at this offsite is we did a company-wide hackathon. And I do know of a lot of companies that do this on a regular basis. How do we do a company-wide hackathon every quarter, every 6 weeks, right? Or how do we even get the just the go-to-market teams to do a company do a hackathon and show what it is that they're building. So, that the expectation that, you know, everyone is a builder is is true everywhere in the company, not just in engineering. So, with this, um what we did is we did two things. One, we did um training. And so, what we did is we actually did a lot of training around like how do you actually ship to production, even if you're not technical. Uh so, we created this um enablement guide for how to ship features with Devon. And so, you know, Devon essentially is like an agentic engineer. Um you can give it tasks. It It It started off, I would say, a year ago, 2 years ago, when we first started using this as almost like intern-level engineer. And today, I think it it's actually, you know, a decent software engineer. It's not a staff-level software engineer, but it does a lot of things. And as a result, you know, um my team is able to ship. And I'll just give go through a couple examples. Here is um a feature, an end-to-end feature, which includes front end changes and back end changes, where um you know, we enable people to to delete temporary initiatives. So, when you're keeping your time, sometimes you don't know um what matter or what project you're working on yet, but you know that you're doing some amount of work that should be grouped together and submitted at the end of the day. And so, that's where temporary initiatives is really powerful. Now, that again is a front end and back end feature. It is not just a front end um like almost like cosmetic change. It's actually pretty deeply rooted in how does it interact with PMSs and other systems and when does it release versus not? There There's a lot of complexity in something like um temporary initiatives. And so, this, by the way, you know, if you look at the person actually um knocking down those tickets and committing these PRs, this is actually a PM on my team. And I'll just go to their LinkedIn briefly. Um Nick, who's awesome, has been at Laurel for some time. If I go back to his educational

嗯，没错。我认为这真的要从文化开始。我这里有几张大约三个月前我们 offsite 团建的照片。非常重要的一点是，这必须自上而下，由领导层来说："这件事对我们至关重要。它不只是工程团队的事，而是全公司的事。"我们在那次 offsite 上做的，是一场全公司范围的 hackathon。我知道很多公司都在定期做这件事——怎么每个季度、每六周办一次全公司 hackathon？或者哪怕只是让 GTM 团队也办一场 hackathon，展示他们在做的东西。这样，"人人都是 builder"这个预期就会在全公司成立，而不只是在工程部门。基于此，我们做了两件事。第一件是培训。我们围绕"即使你不懂技术，如何真正把东西发布到生产环境"做了大量培训，为此创建了一份用 Devon 发布功能的赋能指南。Devon 本质上就是一个 agent 化的工程师，你可以给它派任务。我想说，一两年前我们刚开始用它的时候，它差不多是实习生水平的工程师；而今天，它已经是一个还不错的软件工程师了——不是 staff 级别，但能做很多事。结果就是，我的团队能自己发布功能。我举几个例子。这是一个端到端的功能，包含前端和后端改动：我们让用户可以删除"临时事项"（temporary initiatives）。记录时间的时候，有时你还不知道自己在为哪个案件或哪个项目工作，但你知道自己做的这些工作应该归成一组，在一天结束时提交——这就是临时事项强大的地方。再强调一次，这是一个前后端兼有的功能，不是那种纯前端的、近乎装饰性的改动，它实际上深深牵涉到与 PMS 等其他系统的交互、什么时候释放什么时候不释放——像临时事项这样的东西里有大量复杂度。而且你看，真正消掉这些工单、提交这些 PR 的人，其实是我团队里的一位 PM。我简单打开一下他的 LinkedIn——Nick，非常棒的一位同事，在 Laurel 已经有些年头了。如果我看他的教育

[24:55] JZ

history, right? Like um we we didn't grow up. Many of us didn't grow up as engineers. And yet Nick, um, I would say he probably identifies self-identifies more on the design side than on the engineering side, is able to take this feature end-to-end, which I think is just so cool. Um, similar to similarly, um, within, you know, many parts of our product, I'll just go through another example here. This is, um, the empty state for when someone comes in. So, really think about new user onboarding. What is it that they see? How do How do we make that experience super delightful? All of this is done by, um, by Jessica, who is, again, a PM on my team, not an engineer, and also not a PM who necessarily started their career in, um, in engineering or studied computer science. And so, I think this is just such a great example of people being able to ship even when they're not technical. And maybe the last thing I'll show you, cuz I think this is even cooler, is, uh, this little picture here, um, which is this is someone on our customer success team. Ashley's amazing. She deeply understands our customers and their needs. And by working with the PMs on the team to really create this enablement guide for Devon, they worked on this together. So, that, again, if if you are even less technical than a PM, right? If you're on the success team, how might you use this guide to be able to really ship the way, um, you know, in a safe way, in in a reliable way. And then all of these pieces we then broke down to say, "Well, should we start building skill files, you know, agents to help you?" So, that when you're trying to do this thing that typically is a playbook. And again, this is not 55 pages, but it's still eight pages. You are able to get the help and the support you need. And so, that is really, again, the the crux of it all is understanding what is the work that you're doing, how do you start to document that down, and then really clearly define these are the parts that remain human-centric versus these are the parts that should be automated away.

背景，对吧？我们很多人都不是工程师出身。而 Nick——我觉得他大概更认同自己偏设计而非偏工程——却能把这个功能端到端地做完，我觉得这真的太酷了。类似地，在我们产品的很多部分——我再举一个例子——这是用户刚进来时看到的空状态页面。认真想想新用户 onboarding：他们看到的是什么？我们怎么把那个体验做得特别令人愉悦？这些全是 Jessica 做的——她同样是我团队里的一位 PM，不是工程师，也不是那种职业生涯从工程起步或学计算机出身的 PM。所以我觉得这是"不懂技术的人也能发布产品"的绝佳例子。最后再给你看一个我觉得更酷的东西：这张小照片里的人来自我们的客户成功团队。Ashley 非常出色，她对我们的客户和他们的需求理解得极深。她和团队里的 PM 一起协作打造了这份 Devon 赋能指南——他们是一起做的。这样一来，哪怕你比 PM 还要不懂技术——比如你在客户成功团队——你也可以用这份指南，以一种安全、可靠的方式去发布功能。然后我们把所有这些环节再拆解，问："我们是不是该开始建 skill 文件、建 agent 来帮你？"这样当你要做的这件事通常对应一份 playbook 时——这份不是 55 页，但也有 8 页——你能得到你需要的帮助和支持。所以归根结底，核心就是：搞清楚你在做的工作是什么，开始把它文档化沉淀下来，然后非常清晰地界定哪些部分应该保留以人为中心，哪些部分应该被自动化掉。

[26:57] JZ

I'll pause there, but I think it's also really cool to look at this ontology, which is essentially, you know, for every single function in the company, what are all the buckets of work that they're doing? And And what we do is actually we we actually spend cycles saying, "You know what? We believe that, like I said earlier, a product person should be operating like an engineer." So, all of the the things that we expect an engineer to do, we expect them to be doing feature work. We expect them to be testing. You know, we're we expect them to actually like crank through the backlog. The exact same things show up in what we want PMs to do. Um it is it is not a um an error where, you know, here in the ontology, we really have things like we want you to be, you know, doing feature work with agents. We want you to be um, you know, actually QAing your your product and fixing the bugs, not just like QAing in in the ways that people were doing before. And what we don't want you to be doing is things that were really tedious, like synthesizing competitive market, you know, intelligence, um actually writing these like detailed briefs, doing research planning, doing reach out for the the research, synthesizing the research. Like all of that, um you know, competitive analysis is a great example. It should You should be spending time building the agent to pull the competitive data, and you should just be moderating it, but you shouldn't actually be doing the deep work every single day. And like set up the system instead. And so, when we actually create this ontology, we're able to say, "Well, we want these numbers to go up. We want everything in green, the time spent doing that to go up. I want to see Nick doing this. I want to see Jess, you know, shipping this this this feature end-to-end. But what I want you to stop doing is I want you to stop doing these things that are really tedious, or the very least be calling an agent every single time that you want to do that."

我先在这里停一下，不过我觉得看这个 ontology（职能本体图）也特别有意思——它本质上是把公司里每一个职能的全部工作都归成几大类：他们到底在做哪几桶事？我们实际上真的花了不少精力去定义，比如我前面说过的，我们认为产品人应该像工程师一样工作。所以我们期望工程师做的所有事情——做 feature、做测试、把 backlog 一个个啃掉——这些一模一样的条目也会出现在我们对 PM 的期望里。这不是写错了：在这个 ontology 里，我们确实明确写着，希望你用 agent 去做 feature 开发，希望你亲自去 QA 自己的产品、去修 bug，而不是像以前那样只做走过场式的 QA。而我们不希望你做的，是那些真正繁琐的事，比如手工去综合竞争市场情报、亲手写那种事无巨细的 brief、做调研规划、为调研做外联邀约、再把调研结果汇总——所有这些。竞品分析就是个绝佳的例子：你的时间应该花在搭建一个能自动拉取竞品数据的 agent 上，然后你只需要审核把关，而不是每天亲自去做那些深挖的苦活——应该把系统搭起来。所以当我们真正建好这个 ontology 之后，我们就能说：我们希望这些数字往上走，希望绿色部分（该做的事）的时间占比上升。我想看到 Nick 在做这个，想看到 Jess 端到端地把某个 feature 发布出去。而我希望你停止做的，是那些真正繁琐的事情——或者至少，每次要做那种事的时候，先去调用一个 agent。

[28:44] JZ

And And then again, going back to how do we make that true? By building the skill files, by building the agent agentic workflows where necessary, and making sure that we're surfacing for surfacing them where people work. And that's ultimately the the key pieces of the system.

然后再回到那个问题：怎么让这一切真正落地？靠的就是构建 skill 文件、在需要的地方搭建 agentic workflow，并且确保把它们呈现在大家日常工作的场景里。这些说到底就是整套系统的关键组成部分。

[29:01] Aakash

Wow, there is so much gold buried in the various parts of your answer there. The first part I want to double click on first is PMs shipping to production. Okay, people have heard about that. But PMs not just shipping, okay, here's this little growth experiment where we change the text in a button, which is a front-end only change, but a front-end plus back-end core feature, this temporary initiatives feature for instance that we looked at. That's crazy. So, talk to me a little bit about what is the scope of what PMs do ship to production, and how should people be thinking about in an AI-native organization, this is the role of a PM today.

哇，你刚才那段回答里埋了太多干货了。我想先深挖的第一点是「PM 直接发布到生产环境」。这个概念大家多少听过，但你们的 PM 不只是发布那种小打小闹的东西——比如改个按钮文案的增长实验，那只是纯前端改动——而是前端加后端的核心功能，比如我们刚才看的那个「临时事项（temporary initiatives）」功能。这太疯狂了。所以跟我聊聊：PM 能发布到生产环境的范围到底有多大？在一个 AI-native 的组织里，大家应该怎么理解今天 PM 这个角色？

[29:44] JZ

We talk a lot about this in terms of what is engineering anyways, what is product anyways, what is design anyways, and we really landed on this concept of um we want there always to be a captain of any given initiative, and the captain is the person where that skill set is the most important. And so, there are lots of features, um let's say we need to overhaul a system in order to make it much easier for, let's say, PMs to ship agents to work in that codebase. Usually, the captain is an engineering captain because that's an architectural change. If we have a feature where um like the interaction is really king, you know, we're doing this really cool stuff on mobile to make it so easy and delightful to kind of like look at how you spend your time in a given day and get insights from that.

我们内部经常讨论这个问题：工程到底是什么？产品到底是什么？设计到底是什么？最后我们落在了一个概念上——任何一个项目都要有一个 captain（队长），而 captain 就是那个「其技能组合对这件事最关键」的人。所以有很多不同类型的 feature：比如说我们需要重构某个系统，让 PM 更容易把 agent 派进那个代码库里干活，那通常 captain 就是工程 captain，因为这是架构层面的改动。而如果某个 feature 里交互体验才是王道——比如我们在移动端做的一个很酷的东西，让你能非常轻松愉悦地查看自己一天的时间都花在哪儿了，并从中获得洞察……

[30:34] Aakash

I hope you're enjoying today's episode. Are you interested in becoming an AI product manager making hundreds of thousands of dollars more joining OpenAI and Anthropic, then you might want to do a course that I've taken myself, the AIPM certificate ran by OpenAI product leader Mickdad Jaffer. If you use my code and my link, you get a special discount on this course. It is a course that I highly recommend. We have done a lot of collaborations together on things like AI product strategy. So, check out our newsletter articles if you want to see the quality of the type of thinking you'll get. One of my frequent collaborators, Pavel Hearn, is the build labs leader, so you're going to live build an AI product with Pavel's feedback if you take this AIPM certificate. So, be sure to check that out. Be sure to use my code and my link in order to get a special discount. And now back into today's episode. I used to think I had a retention problem. Turns out I had a messaging problem. I was sending the same onboarding emails to every new user, whether they activated on day one or never logged in again. I had no [music] idea who was slipping or why. Customer.io changed that. Every message I send is now based [music] on what users actually do in the product. Someone hits a key activation moment, they get nudged to the next one. Someone goes quiet, [music] they get a different path entirely. Their AI agent makes it fast. I describe the campaign I [music] want and it builds the full journey for me. Triggers, timing, copy, even branching logic. And when I want to know how something is performing, [music] I just ask the agent directly and it tells me what to do next. They also have an MCP server, [music] which means AI tools like Claude can see directly what's happening in your Customer.io workspace.

希望你喜欢今天这期节目。如果你有兴趣成为 AI 产品经理、多赚几十万美元、加入 OpenAI 和 Anthropic，那你可以考虑上一门我自己也上过的课——由 OpenAI 产品负责人 Mickdad Jaffer 开设的 AIPM 证书课程。用我的折扣码和链接可以享受专属优惠。这门课我强烈推荐，我们在 AI 产品战略等话题上做过很多合作，想了解课程思考质量的话可以去看我们的 newsletter 文章。我的常驻合作伙伴之一 Pavel Hearn 是 build labs 的负责人，如果你参加这个 AIPM 证书课程，你将在 Pavel 的反馈下现场动手构建一个 AI 产品。记得去看看，记得用我的折扣码和链接拿专属优惠。现在回到今天的节目。我以前以为自己有留存问题，后来发现其实是消息触达问题。我给每个新用户发的都是同一套 onboarding 邮件，不管他们是第一天就激活了，还是再也没登录过。我完全不知道谁在流失、为什么流失。Customer.io 改变了这一点。现在我发的每条消息都基于用户在产品里的真实行为：有人到达关键激活节点，就会被推向下一个节点；有人沉默了，就会走一条完全不同的路径。他们的 AI agent 让这一切变得很快——我描述我想要的 campaign，它就帮我搭好完整的用户旅程：触发条件、时机、文案、甚至分支逻辑。当我想知道某个东西效果如何时，我直接问 agent，它会告诉我下一步该做什么。他们还有一个 MCP server，这意味着像 Claude 这样的 AI 工具可以直接看到你 Customer.io 工作区里发生的一切。

[32:05]

[music] Your segments, your customer data, your attribution, all of it. So, instead of explaining your business [music] context every time you need help, Claude already knows it. Notion used Customer.io to personalize their onboarding and hit nearly 50% open rate, improved conversion by 6 to 7% with localized campaigns, and pushed open rates up another 20% through AB testing. [music] The idea is simple. Customer.io helps you deliver more impact from every message you send. If you're a PM or founder and your onboarding is still one size fits all, try Customer.io at Customer.io. That is more so than anything, it's it's a data problem. So, we have, you know, data science really plugged in there. But, really um the interaction is the most important thing to really sweat and make sure it's delightful. And as a result, a designer is a captain of that work stream. And then something like what I just showed you, something like temporary initiatives, something like the empty states, really having deep customer understanding, but also business context is really important. How do I know what people want to do with temporary initiatives? How do I know what the user wants to do, but also how do I know what the firm really wants to get out of it and or not? And so, what we spend a lot of time now thinking about is what is the what is the most critical piece to nail for the outcome that we're looking for and therefore the feature that we're building? And as a result, how do we appoint a captain that is skilled in that particular area? And so, that that's generally how we think about um the model evolving. And so, going back to a feature that might touch the front end and the back end, if we believe that the back end is in a good enough spot, and by the way, you can ask GitHub uh sorry, Devin um or even, you know, you like anything that's connected to your GitHub account to to look at the code and say, you know, in what state is this, right? And and it actually gives you a pretty good answer. Hey, you know, this this is this is what I would be careful of. Um uh and then you can actually pull in engineering um to to on the parts where you're like, this is probably the most contentious or this is where it gets the most risky. And again, you don't do this by yourself because you happen to be the most technical person. We're not. Um you do this through the help of asking, you know, Claude code to look at your code base, cursor, what I mean, whatever tool of choice you choose to use, you can ask it to really give you answers the same way that a marketer would say, "Look, I'm

你的用户分群、客户数据、归因数据，全都能看到。所以你不用每次求助时都重新解释一遍业务背景，Claude 已经了然于胸。Notion 用 Customer.io 做个性化 onboarding，打开率接近 50%，本地化 campaign 让转化率提升了 6% 到 7%，AB 测试又把打开率再推高 20%。道理很简单：Customer.io 帮你让发出的每条消息都产生更大影响。如果你是 PM 或创始人，而你的 onboarding 还是千人一面，去 Customer.io 试试吧。（回到访谈）……那件事说到底更多是个数据问题，所以我们让数据科学深度参与其中。但真正需要死磕、确保做到令人愉悦的，是交互本身，因此那条工作线的 captain 是设计师。再比如我刚才展示的那些——临时事项、空状态（empty states）这类功能，需要对客户有深刻理解，同时业务背景也非常重要：我怎么知道人们想用临时事项做什么？我怎么既知道用户想要什么，又知道公司（律所）到底想从中得到什么、不想要什么？所以我们现在花大量时间思考的是：为了达成我们想要的结果、做好我们要做的功能，最关键要搞定的那一环是什么？然后据此任命一位在那个领域最有专长的 captain。这大体上就是我们对协作模式演进的思考。回到一个同时涉及前端和后端的 feature：如果我们认为后端已经处于足够好的状态——顺便说一句，你可以让 GitHub……抱歉，是 Devin，或者任何接入了你 GitHub 账号的工具去看代码，问它「这块代码现在什么状态」，它真的能给你一个相当不错的答案：「嘿，这部分我建议你小心。」然后在你觉得最有争议、风险最高的部分，你可以把工程师拉进来。而且再强调一遍，你不是靠自己碰巧是最懂技术的人来做这件事——我们都不是。你是借助工具来做：让 Claude Code 去看你的代码库，或者 Cursor，随便你选什么工具，你都可以让它认真给你答案，就像一个营销人员会说：「我给你一段文案，

[34:25] JZ

giving you some copy. Now, battle test this and go back and forth." It's the same concept. And and then going back to if you are clear on again, what is the hardest thing to to get right in a particular feature? Um for example, empty state. The empty state that we're working on here, it's the hardest part to get right is definitely not the engineering. The hardest part to get right is not even the design, it's the content. And again, the content has to do with the user and the business and the firm, and that is a very classic PM thing. And so it makes sense for the PM to be the captain of that. And so that's really the model we think about. Captains, you know, using um um you know, LLMs essentially like ask how hard something can be. Obviously, we still, you know, have code review, um and we make sure that um engineers are code reviewing the things that are risky. Um and so all of those pieces together makes it so that we can all ship, including, you know, customer success, which is again really wild. And and like go-to-market sales.

现在你来把它反复打磨、来回过招。」是同一个道理。然后再回到刚才说的：如果你清楚一个 feature 里最难做对的是什么——比如空状态，我们正在做的这个 empty state，最难搞定的绝对不是工程，甚至也不是设计，而是内容。而内容又和用户、业务、公司（律所）息息相关，这是非常经典的 PM 工作。所以由 PM 来当这件事的 captain 就顺理成章。这就是我们的思考模型：captain 制，用 LLM 去评估一件事到底有多难。当然，我们仍然有 code review，我们会确保有风险的代码都由工程师来审。把所有这些环节拼在一起，我们所有人就都能发布上线了——包括客户成功团队，这真的很疯狂——还有 go-to-market 和销售。

[35:22] Aakash

And I think we can all immediately see how that allows engineers to work on the highest leverage back-end tasks, PMs to work on higher leverage features if CSM and go-to-market are enabled. What is the right set of checks and balances you need to put in place in your organization? How do you You mentioned code reviews. Where Where do those come in? How do you CSMs or uh go-to-market, for instance, make sure that what they're building isn't in conflict with something the product team is building over here, in contact conflict with somebody else's metrics? Usually, that's where the PM came in and did a lot of the glue work. How do you handle that in this new way of working?

我想大家立刻就能看出来，这让工程师可以专注在杠杆最高的后端任务上，而如果 CSM 和 go-to-market 团队都被赋能了，PM 也能去做杠杆更高的功能。那么组织里需要建立什么样的制衡机制？你提到了 code review，它在哪个环节介入？比如 CSM 或 go-to-market 团队，怎么确保他们做的东西不会和产品团队正在做的东西冲突、不会和别人的指标打架？以前这正是 PM 出面做大量粘合工作的地方。在这种新的工作方式下你们怎么处理？

[36:01] JZ

Yeah, that's a great question. Um so we again, I believe in the power of humans. So something as simple as, you know, creating a channel like ask Devin reviewers, and being able to go through here, um and making sure that there's visibility around all of the Devin um all the ways we're using Devin to ship, and then tagging in the right person, tagging in, you know, um a front-end engineer to really look at something, tagging a designer to look at something else, really going through and um making it visible. I think the first advice I'd give is transparency is everything. Um the second piece of advice is you do need to set some ground rules, right? So again, going back to our enablement guide, we've set some ground rules here as part of even the way Devon works. We often we we actually used to do this quick check where whenever someone, let's say someone on support had an idea. They essentially could go into this channel and post their idea and get a really quick check on is this something that makes sense? And again, I'll just let me zoom in here. Like I'm proposing a change to this experience. Um getting some some feedback, right? And and being able to say, "Hey, play around with the first version of it." And and getting you know, people to chime in and say, "Hey, this makes sense. This doesn't make sense. I'm I'm on the engineering team and let me give you some feedback. I'm on the success team. Let me give you some feedback." What you're really doing is you're taking what used to be a product review that used to take time to schedule and time to get all the stakeholders in the same room and you're just compressing it.

这是个好问题。我依然相信人的力量。所以做法可以很简单，比如建一个「ask Devin reviewers」这样的频道，大家可以在里面浏览，确保我们用 Devin 发布的所有内容都有可见性，然后 @ 到对的人：@ 一位前端工程师认真看某个东西，@ 一位设计师看另一个东西，一条条过、让一切透明可见。所以我给的第一条建议是：透明度就是一切。第二条建议是，你确实需要定一些基本规则。回到我们的 enablement guide（赋能指南），我们在里面定了一些基本规则，甚至融入到 Devin 的使用方式里。我们以前经常做一种快速检查：比如支持团队的某个人有了想法，他可以直接进这个频道发出来，快速得到一个「这事靠不靠谱」的反馈。我放大给你看——比如「我提议对这个体验做一个改动」，然后收集反馈，大家可以说「嘿，先玩玩第一版」，各方陆续进来发言：「这个合理」「这个不合理」「我是工程团队的，给你点反馈」「我是客户成功团队的，给你点反馈」。你实际上是把过去那种需要专门排期、把所有干系人凑进同一间会议室的产品评审，直接压缩掉了。

[37:36] Aakash

Double click on product reviews for me. You guys have a really interesting process for when you do and don't do product reviews. What is the right balance so that you enable people to move fast but you're building the right level of collaboration on bigger features?

帮我深挖一下产品评审这件事。你们有一套很有意思的机制来决定什么时候做、什么时候不做产品评审。怎么把握这个平衡，既让大家跑得快，又能在更大的功能上建立起恰当程度的协作？

[37:50] JZ

Yeah, the same way we have this captain's model, I think about a framework what we call two tracks. So there's one track which is much smaller. If you have something that even some of the features I just showed you, like they're they're small enough where again, a PM, um somebody, a product captain or a product builder, right, can take it end-to-end. Those don't go through the same degree of rigorous review but they do go through things like that ask Devon channel. They go through things, you know, like a like someone looking at the PR, making sure things are good. Um, you, by the way, you are responsible for end-to-end testing of your features. I think that's actually really positive. The number of times where in a waterfall model, you would PM throws over to the designer and the designer throws over to the engineer and then engineer throws back to the designer, do design, QA, and the designer's like, this is not what [laughter] I designed. Um, that is just I think it's just such a It's like it's almost a meme cuz it happens so often. And so, I think that's actually really empowering to say, I am the end-to-end product builder and I take something from beginning to end and I own and I'm responsible for the quality and impact of this thing. And so, first of all, I just think that's a much more empowered way to work. Um, so, but but then going back to the two tracks, you have things that, you know, can really take the product life cycle and compress it down to a day, an hour, you know, like and that's how you get the velocity. But, there are some things where you're like, look, I think that the way that this product is going to behave, what I'm suggesting is a change, the feature that I want to do, it requires more much more alignment. So, a great example is, um, within Laurel, if you're going to change the complete way that activities are displayed, that's a that's a pretty radical change.

对，就像我们有 captain 模型一样，我脑子里还有一个框架，我们叫「双轨制（two tracks）」。第一条轨道针对小得多的事情。如果某个东西——包括我刚才展示的一些功能——小到一个 PM、一个产品 captain 或者产品 builder 可以端到端搞定，那它们就不走那种严格程度的评审，但它们会走「ask Devin」频道那类流程，会有人看 PR、确保没问题。顺便说，你要对自己功能的端到端测试负责，我觉得这其实非常好。想想在瀑布模式里发生过多少次：PM 扔给设计师，设计师扔给工程师，工程师再扔回给设计师做 design QA，设计师说「这根本不是我设计的东西」——这几乎都成梗了，因为太常见了。所以我觉得这种方式其实很赋能：我是端到端的产品 builder，我把一件事从头做到尾，我对它的质量和影响负全责。首先我就认为这是一种更有主人翁感的工作方式。然后回到双轨制：有些事情你可以把整个产品生命周期压缩到一天、一小时，速度就是这么来的。但有些事情你会说：等等，我提议的这个改动、我想做的这个功能，它需要的对齐程度要高得多。举个很好的例子：在 Laurel 里，如果你要彻底改变活动（activities）的展示方式，那是相当激进的改动。

[39:29] JZ

Um, and how might someone a user go zoom in and out of their day? That is not a small thing. It require It touches, um, it's the whole like user interaction. And as a result, we say, look, we do want to do a product review for that. Want to make sure that, um, we talk about, well, how do we think about the entire product as a system so that we're not adding some random thing over there and a random thing over there. Um, but a lot of I think the first step is to actually even say, what is in what bucket? So that the things that could be running really fast are, but also, I really don't believe in this. I think a lot of quote-unquote AI-native companies are just like, roadmaps are gone, planning is a gone, everything is gone. Um, and what I say is, well, if everyone's running in different directions, even if you're running incredibly fast, you're not really going to get anywhere. And I see a lot of, um, great like local maximizations, but sometimes it's really hard to get to the global max, you know, a whole new set function change in your product in your market positioning without real rigorous thought around what is our strategy, what is our plan, why are we differentiated? And those are the things that require much more of what I call a true product review process, where to me it's more like product strategy review, and then there's architectural review, right? Making sure that the system actually will support all the changes that you want and that you can get to a next level of running fast.

还有比如用户如何在自己的一天里放大缩小视角——这不是小事，它牵动整个用户交互。所以我们会说：这种事我们确实要做产品评审，要确保我们把整个产品当作一个系统来讨论，而不是这儿随手加一个东西、那儿随手加一个东西。但我认为第一步其实是先分清：什么事情归哪个桶？这样该跑得飞快的事情就能飞快地跑。同时我真的不认同另一种论调——很多所谓的 AI-native 公司说什么「roadmap 不要了、规划不要了、什么都不要了」。我的回应是：如果每个人都朝不同方向狂奔，就算你跑得再快，你也到不了任何地方。我见过很多很棒的局部最优（local maximization），但如果没有真正严谨的思考——我们的战略是什么、我们的计划是什么、我们的差异化在哪——你很难达到全局最优（global max），很难实现产品在市场定位上那种全新的阶跃式变化。这些才是需要我所说的「真正的产品评审流程」的事情。对我来说它更像是产品战略评审，此外还有架构评审——确保系统真的能支撑你想要的所有变化，让你能跑进下一个速度档位。

[40:49] Aakash

Mhm. So, did temporary initiatives go through a product review?

嗯。那「临时事项」这个功能走过产品评审吗？

[40:52] JZ

It did not.

没有走。

[40:53] Aakash

Wow. Okay. So, what would be the like the right aperture? What have been some of your recent product strategy reviews?

哇，好。那什么样的事情才够格？你们最近做过哪些产品战略评审？

[41:00] JZ

Yeah, so um today Laurel is beloved in a lot of firms that think about billable hours. And we're starting to find that there are a lot of firms, even if they don't have billable hours, um they really think they still need to think about the concept of time. Um I would say it even applies to tech. I think about the concept of time all the time. What are my PMs doing? Going back to this ontology um and and this work map of every single function. I mean, all of us should be thinking about the concept of time. What should sales people be doing today versus what should not be human anymore. And this is I want to be very clear, this is not a therefore we do not hire humans. It is a put the humans on the most important things. And I'll give you some great examples in here. Relationship building. You just will never replace a real check-in, a real moment of you know, true hospitality and delight, an actual on-site, taking a champion out to dinner. That cannot be replaced by agents. But what will make it so much easier to operate and and no one actually wants to do these things. What if the scheduling for the on-site and making sure that all of the back and forth and logistics is taken care of. You know, again, in marketing we do a lot of events. What if all the logistics of event planning were gone? Even this idea of unreasonable hospitality, and I I think this is such a a great example. It is such a core value of us of ours here at Laurel, where we really want to delight our customers all the time. We want to delight each other, want to delight our customers, and so we really have codified unreasonable hospitality as as almost like a like a cultural principle that we have, a company value. A lot of companies do this, by the way. They're like, this is a cultural company value, and then it's in a doc somewhere.

对，今天 Laurel 在很多按计费工时（billable hours）运作的律所里非常受欢迎。而且我们开始发现，很多公司即使没有计费工时，也真的需要认真思考「时间」这个概念。我甚至觉得这同样适用于科技行业——我自己就无时无刻不在思考时间这个概念：我的 PM 们都在做什么？这又回到我说的那个 ontology（本体），以及覆盖每一个职能的工作地图（work map）。说真的，我们所有人都应该思考时间这个概念：销售今天应该做什么，哪些事不应该再由人来做了。我想说得非常清楚，这不是说「所以我们不招人了」，而是把人放到最重要的事情上。我在这里给你举几个很好的例子。比如关系建设——真正的当面拜访、真正体现待客之道和惊喜感的那个瞬间、实打实的现场拜访、带客户内部的支持者（champion）出去吃饭，这些永远无法被替代，agent 做不了这些。但有什么能让运营变得轻松得多呢？而且说实话，那些琐事根本没人想干。如果现场拜访的日程安排、所有来回沟通和后勤事务都被自动搞定了呢？再比如市场部，我们办很多活动，如果活动策划的所有后勤工作都消失了呢？还有「不合理的好客之道」（unreasonable hospitality）这个理念——我觉得这是个特别好的例子。它是我们 Laurel 的核心价值观，我们真心希望时刻取悦客户，我们想取悦彼此、取悦客户，所以我们把 unreasonable hospitality 明文化成了一条文化原则，一条公司价值观。顺便说一句，很多公司都会这么做——他们说「这是我们公司的文化价值观」，然后它就躺在某个文档里。

[42:41] JZ

People read it and then they forget about it. And what we do instead is we say, "Well, what does it actually mean?" We actually want to make sure that no matter who you are, even if you're the most thoughtful person in the world, or you're not the most thoughtful person in the world, even if you're 4 years into your time at Laurel, or you're 4 days into your time at Laurel, you understand that unreasonable hospitality is a requirement of how we operate. And especially if you're on the customer success team, we expect that you do this with our customers. How do we systematize that? And and and that's a real real question. You know, again, there are people on our team who just from who they are as humans, they're the kind of people who's like, "Someone told me that they're going to Mexico." And so, and it's the first time, by the way, that they're traveling outside of the country. And so, I bought them an engraved passport holder. That is, by the way, a lot of people on the Laurel team, but if I were to scale that to like a lot a lot of people and make sure that everyone's doing it every point in time, even when they're really busy with other stuff, it's pretty unlikely that's going to happen. Instead, we say, "Well, we actually want to make sure that unreasonable hospitality is a check that we put in." And so, again, going back to the OS I was showing you, "Hey, if you have a check-in with someone, and you know, you haven't actually done anything like this in a while, you haven't had an in-person touchpoint, how might you surprise and delight them?" And here's some ideas that we've already pulled for you. We pulled from your Gong transcripts that these are things that they love. And we pulled um, from the fact that they love these things, instead of making you do all the work of figuring out, is it a passport holder?

大家读一遍，然后就忘了。而我们的做法是问：「这条价值观到底意味着什么？」我们要确保的是，不管你是谁——哪怕你是世界上最贴心的人，或者你并不是那种特别贴心的人；不管你在 Laurel 已经待了四年，还是才来四天——你都明白 unreasonable hospitality 是我们运营方式的一项硬性要求。尤其如果你在客户成功团队，我们期望你对客户就是这么做的。那怎么把它系统化？这是个实实在在的问题。我们团队里确实有人天生就是那种人：听说某个客户要去墨西哥——而且顺便说，那是对方第一次出国——于是就给人家买了一个刻字的护照夹。Laurel 团队里其实有很多这样的人，但如果我要把这件事扩展到非常多的人身上，还要确保每个人在任何时点都能做到，哪怕他们正忙着别的事情，那基本上是不可能的。所以我们换一种做法：我们要确保 unreasonable hospitality 变成一个内置的检查项。回到我刚才给你演示的那个 OS——「嘿，你马上要和某人做 check-in，而你最近没做过类似的事，也很久没有线下接触了，你可以怎么给对方制造惊喜和愉悦？」然后系统会说：这里有一些我们已经帮你准备好的点子。我们从你的 Gong 通话转录里提取出了对方喜欢的东西。基于「他们喜欢这些」这个事实，系统直接给出建议，而不是让你自己去琢磨：到底该不该送护照夹？

[44:12] JZ

How do I even get a passport holder engraved? We are going to we're going to systematize that. And so, that's this real idea of like deeply understanding your your your company's work, your team's work. What are the things that makes you special? Where do you put the humans on the things that make you special? And then, where do you even in those moments, like unreasonable hospitality, make it so it's easier to do that job and to deliver that particular feeling.

护照夹要怎么刻字？这些我们都会系统化。所以这就是那个核心思想：深入理解你公司的工作、你团队的工作。哪些事情让你与众不同？在那些让你特别的事情上，把人放在哪里？然后即使是在那些时刻——比如 unreasonable hospitality——也要想办法让这份工作更容易完成，让那种特定的感受更容易被传递出去。

[44:37] Aakash

So, you This isn't your first rodeo. You've been in product for a really long time. If we rewind back to some of those experiences, those formative experiences, let's say like Airbnb in 2015 or Dropbox in 2013 or WeWork in 2019, you've been in these large organizations that most people listening to this podcast have been in where the PM traditionally never had access to get let alone like the amount we're showing here where they have a dev and agent that is shipping front end and back end features. And you'd be surprised, even at companies like Adobe, PMs are still living in that world that you and I were in back then. They still don't have access. They're looking at what we've just showed them and they're saying, "Gosh, this is too far away from my reality. Is it true that like this just won't work in certain type of companies or will they eventually get there? It is just a matter of time."

你可不是第一次做产品了，你在产品这行干了很久。如果我们回放一下你那些塑造你的早期经历——比如 2015 年的 Airbnb，2013 年的 Dropbox，或者 2019 年的 WeWork——你待过的那些大组织，也是听这档播客的大多数人待过的那种组织：在那里，PM 传统上根本没有权限，更别提像我们刚才展示的那样，PM 手里有一个能同时交付前端和后端功能的开发 agent。你可能会惊讶，即使在 Adobe 这样的公司，PM 们仍然活在你我当年的那个世界里，他们依然没有权限。他们看着我们刚才展示的东西，会说：「天哪，这离我的现实太遥远了。」是不是在某些类型的公司里这套东西就是行不通？还是说他们最终都会走到这一步，只是时间问题？

[45:34] JZ

I'll start with the end, which is I do think it is a matter of time that every company is going to have to get there. You can't keep doing the same thing if everyone else, including all your competitors, are moving at 10 times the speed. So, I do think that there will be pressure to ultimately get there for everyone. Now, what you want to be for the company and for the individual is you want to be, um, as far, uh, you know, as as advanced as it's right, in that curve as opposed to just waiting for it to happen to you. And this is where I go back to, you know, the first step is just start small. Start with one workflow that you are doing. Um and or I really I really push on this. I think this is really uh a great way to to get your feet wet and and start to think about this. Go find another team in your company somewhere. And even if you're like, "I I'm not quite ready to ship to production for whatever reason." And usually the reasons are not that you can't like you're not physically able to. It's usually something about the the system or the process that it's not quite there yet. But but let's just say that you you don't feel like you can in the next month. Go somewhere else where there's always somewhere in the org that is hungry for product thinking and hungry for a tool to make their life better. And I would start with let's just go build a tool for somebody in a different org to make their life better. And simultaneously pick up one part of your workflow that is taking you a lot of time and there's really no reason that you should be doing that. Again, great examples. I'm getting into a customer call. I would love to be pre I would love to be prepped for that in a way that, you know, an agent is serving me that information as opposed to me having to pull from multiple different sources, right? That's a very simple example. I write the same um same email over and over again. It should be auto-populated. Again, these are just small small little automations.

我先说结论：我确实认为每家公司最终都必须走到这一步，只是时间问题。当所有人——包括你所有的竞争对手——都在以十倍速度前进时，你不可能还在原地做同样的事。所以我认为最终每个人都会面临这种压力。那么无论对公司还是对个人，你要做的是在这条曲线上尽可能走在合理的前沿位置，而不是干等着变化砸到你头上。这里我又要回到那句话：第一步就是从小处着手。从你自己正在做的一个工作流开始。另外我特别想强调一点，我觉得这是入门、开始思考这件事的绝佳方式：去公司里找另一个团队。哪怕你觉得「出于种种原因，我还没准备好把东西发到生产环境」——而且通常这些原因并不是你能力上做不到，往往是系统或流程还没到位。但就算你觉得下个月之内做不到，你也可以去别的地方——组织里总有某个角落，那里的人渴望产品思维，渴望有个工具能让他们的日子好过一点。我会建议你从「给另一个部门的某个人做一个让他生活变好的工具」开始。与此同时，挑出你自己工作流里一个特别耗时、而且你根本没理由亲自做的环节。还是举几个好例子：我马上要进一个客户电话会，我希望有 agent 把准备材料直接端到我面前，而不是我自己去好几个来源里扒信息，对吧？这是个非常简单的例子。再比如我反复写同一封邮件——它就应该被自动填充。这些都只是些小小的自动化。

[47:25] JZ

Or you can call them templates. Whatever it is that you that um makes sense to you. Start there. And then I would say if you're ready to take on something bigger, this idea of like, "What does a function do? Or what is an end-to-end um operational journey look like?" And there I would start to say map out your ontology or take your playbook and really, you know, write that down. And again, what I what I find really fun is like these playbooks, I think if someone was tasked to write a playbook back in the day, they'd be like, okay, I'll do it. It'll take me a couple weeks. These playbooks can be written in an hour. Actually, the first draft can be written in sub a minute, but to make it actually right and and you know, really reflective of your business, yeah, it will take a little bit more time, but we're talking hours here, maybe days max. We're not talking weeks. And so, I think when you get a feel for how much you can enable yourself and you can enable others, you're going to create a culture, again, even just going back to culture change. You're going to create a culture where um it's celebrated and it's fun. And and again, if you're leadership, what I'd really encourage you to do is make that the culture. Celebrate those wins. Take the people who are your 1% and take their workflows and figure out how to scale that workflow to every single person on the team. When you create that um expectation and you celebrate those wins, you'll get more and more of that behavior.

或者你也可以叫它们模板，随便你怎么称呼，只要对你来说说得通。就从那里开始。然后如果你准备好接手更大的东西，就去想「一个职能到底在做什么？一段端到端的运营旅程长什么样？」到了这一步，我会建议你把你的 ontology 画出来，或者把你的 playbook 认真写下来。而且我觉得特别有意思的是：这些 playbook，放在过去，如果有人被指派去写一份 playbook，他会说「好吧我来写，得花我几周时间」。而现在这些 playbook 一个小时就能写出来。实际上初稿不到一分钟就能生成，但要把它真正写对、真正反映你的业务，确实还需要多花点时间——不过我们说的是几个小时，最多几天，绝不是几周。所以我认为，当你切身感受到自己能赋能自己、也能赋能别人到什么程度时，你就会创造出一种文化——再回到文化变革这个话题——一种这类事情会被庆祝、而且很有乐趣的文化。而且我再说一遍，如果你是管理层，我真心鼓励你把这变成公司文化：庆祝这些胜利。找到你团队里那 1% 的顶尖者，把他们的工作流拿出来，想办法把那个工作流规模化到团队里的每一个人身上。当你建立起这种期望并庆祝这些胜利时，你就会得到越来越多这样的行为。

[48:51] Aakash

For you guys, did it happen as a transformation? Were you guys always this way? Did it start with the CEO and the founder? How did it come about so that now you guys do feel the confidence that you have this enablement playbook of Devin where anyone can ship to production?

对你们来说，这是一场转型吗？你们从一开始就是这样吗？是从 CEO、从创始人开始的吗？这一切是怎么发生的，才让你们现在有信心说，有了 Devin 这套赋能 playbook，任何人都能把东西发到生产环境？

[49:05] JZ

Yeah. Um I think there were a lot of pieces, but I'll highlight the pieces that I think are most relevant that someone listening to this could take and and replicate. Um the first piece I've already shared, which is the idea of just doing a hackathon. And in the hackathon um making everyone participate cuz it changes this idea of you have to be technical to build something. But and and and again, I think most people have done that. Um so, I would expect that, you know, 90% of the people listening have participated in some kind of hackathon. If you have not, that's the first step. Um the second step is to really think about all the different ways you can again, automate the workflow. I think that a structural thing that I would really recommend is actually making this idea of playing with AI tooling, creating workflows, automating, you know, large swaths of somebody's day in a way that makes them much more productive, make that the actual charter and mandate of a full of a person full-time. And what I really find is a lot of times when you say it's everyone's responsibility, it's no one's responsibility. And so what we have at Laurel is we actually have an AI operations team. And to me AI ops is a new biz ops. Before biz ops, they were doing I'm really meaningful things, but often it was it was very high-level, all the different hats, a lot of like market level stuff. Now if you repurpose this idea of having biz ops, which is really again a Swiss Army knife in many ways, to finding people who are insanely curious, tinkering with the latest technology, and relentless about finding efficiencies, that's the DNA I really look for. And so we've actually built out an AI operations team. We started with Sasha, who has built out a lot of the things that I've I've shown today.

嗯，我觉得有很多因素，但我挑几个我认为最有价值、听众可以拿去照着做的讲。第一点我已经分享过了，就是办 hackathon，而且在 hackathon 里让所有人都参加，因为这会打破「你必须懂技术才能做出东西」的固有观念。不过我想大多数人都参加过——我估计 90% 的听众都参加过某种形式的 hackathon。如果你还没有，那这就是第一步。第二步，是认真思考自动化工作流的各种方式。我特别推荐的一个结构性做法是：把「玩转 AI 工具、搭建工作流、把某人一天中大块的工作自动化、让人变得高效得多」这件事，变成一个人的全职章程和使命。我发现的规律是，当你说「这是每个人的责任」时，它就成了没有人的责任。所以我们在 Laurel 实际上设了一个 AI 运营团队（AI operations）。在我看来，AI ops 就是新时代的 biz ops。以前的 biz ops 也在做很有意义的事，但往往非常高层、什么帽子都戴、做很多市场层面的东西。现在如果你把 biz ops 这个「瑞士军刀」式的角色重新定位——去找那些好奇心爆棚、痴迷于折腾最新技术、对挖掘效率毫不松懈的人——那就是我真正要找的 DNA。所以我们组建了 AI 运营团队。最开始是 Sasha，我今天展示的很多东西都是他搭出来的。

[50:54] JZ

And what he did is basically was like, I'm going to demonstrate value in having AI operations. And very soon when you when you have one person who's doing an excellent job, every single other function is like, I want my Sasha. I want my own AI Sasha. And that is how you then get the buy-in to say, okay, well maybe we have an AI person AI operations person just doing go-to-market, and a separate AI operations person just doing product, and a separate AI operations person just doing finance. Because all of these functions, by the way, finance, rev ops, product ops, research ops, you name it, all of them are changing so dramatically. And so being able to retool your the way that your company works with someone who's really dedicated to pushing that forward really really accelerates the the journey.

他的做法基本上就是：我要证明 AI 运营的价值。很快，当你有一个人把这件事做得极其出色时，其他每一个职能都会说：「我也要我自己的 Sasha，我要一个我专属的 AI Sasha。」这就是你获得支持的方式——接下来你就可以说：好，也许我们该配一个专门做 go-to-market 的 AI 运营，一个专门做产品的 AI 运营，再来一个专门做财务的 AI 运营。因为顺便说一句，所有这些职能——财务、rev ops、产品运营、研究运营，随你举——全都在发生剧变。所以，有一个真正专职推动这件事的人来帮你重塑公司的运作方式，会极大地加速这段旅程。

[51:40] Aakash

Mhm. That's really interesting. And you guys were founded before the AI revolution. So I guess like for other companies that were founded before then, I think you were 2018, like where who is like the right driver? It feels to me like it probably has to start like literally with the CEO, right?

嗯，这真的很有意思。你们公司是在 AI 革命之前创立的。所以对于其他同样创立于那之前的公司——我记得你们是 2018 年——合适的推动者应该是谁？在我看来，这大概真的得从 CEO 本人开始，对吧？

[51:58] JZ

Yeah, I was going to say I want to give a ton of credit to Ryan. So, yes, um Laurel um was founded actually I would say Time by Ping, this is what Laurel was called uh previously, was founded in 2018. Um but Ryan actually had the the foresight and and the the courage really to say, you know what? When I think about what time looks like in a world of AI and LLMs, it's very different. And when I think about um at the time our core product um timekeeping, right? Like what does timekeeping look like in a world that um where you have to kind of enter it manually or just do it through call it what I call integrations um versus a world where you can actually start to really see everything that's happening on your computer and synthesize that and run that through an LLM. Like he basically had the foresight and again courage to say, I'm going to re-architect my entire product, my entire company to be AI native. And so it's it's really interesting. Like I really believe that um and I experience this day to day. Um I wouldn't you know, like I I I was like I I I want to be building at the cutting edge. Um Laurel is AI native. Although it was founded like more than 3 years ago. Um and so that it does start with the CEO. Um but even if it if uh people don't have that degree of change um and and conviction, I think you can still do it at every single level where, you know, if you are not the CEO, but you're uh an executive, you can say, well, this is how I expect my function to really operate. Here in my function, I am a marketing leader. I fully expect that this is what we are doing and let me go color code everything in here that should be AI enabled, right? Like when you think about copywriting today, you should not be writing copy by hand. You should be editing when you're doing videos. Like if you're not using um a lot of the AI tooling out there, you're spending a lot of money on studio, on video in a way that you don't need to anymore. So, being able to go line by line in terms of your again your your work map. What is it that all my humans do and how do I really think about where do I need to keep that person versus where can I actually really AI charge supercharge them?

对，我正想说，这里我要把很大的功劳归于 Ryan。是的，Laurel——它之前叫 Time by Ping——确实创立于 2018 年。但 Ryan 当时真的有那份远见，说实话还有那份勇气，他说：当我思考「时间」在一个 AI 和 LLM 的世界里会是什么样子时，答案是截然不同的。当我思考我们当时的核心产品——计时（timekeeping）——在两种世界里的样子：一种是你得手动录入，或者靠我所说的「集成」来完成；另一种是你真的能看到电脑上发生的一切，把它们综合起来跑一遍 LLM。他基本上就是凭着这份远见和勇气说：我要把我的整个产品、整个公司重新架构成 AI native。这真的很有意思——我是真心相信这一点的，而且我每天都在亲身体验。我当时就想：我要在最前沿做产品。Laurel 是 AI native 的，尽管它三年多前就创立了。所以，这件事确实要从 CEO 开始。但即使你的公司没有那种程度的变革和信念，我认为你在每一个层级上都还是可以做这件事：如果你不是 CEO，但你是一名高管，你可以说，这就是我期望我的职能运转的方式。比如在我的职能里——假设我是市场负责人——我完全可以要求我们就这么干，然后把这里面所有应该 AI 化的环节逐一标注出来，对吧？比如今天做文案，你就不应该再手写文案了，你应该做的是编辑修改；做视频的时候，如果你还没用上市面上那些 AI 工具，你就是在棚拍和视频制作上花着如今根本不必花的大钱。所以要能逐行过一遍你的工作地图：我的人都在做什么？我要认真想清楚，哪里需要保留这个人，哪里其实可以用 AI 给他们超级加持（supercharge）？

[54:08] Aakash

Amazing. So, I think that's the key point for a lot of people that I talk to at least is that they have they don't have any access to the stuff we're showing and probably it needs to start like all the way at the CEO level and then it can work its way down where like you need really amazing CPO like yourself who is also AI filled in order to make this happen and that's kind of the next layer I want to talk about is as an AI filled CPO, what is your take on the types of product teams we're going to see in the future? What types of product managers are you hiring and what is the shape of their role today?

太棒了。我觉得这正是关键——至少对我聊过的很多人来说，他们完全接触不到我们展示的这些东西，而这大概需要从 CEO 层面一路启动，然后再往下渗透。你还需要一位像你这样既顶尖又对 AI 充分投入（AI-pilled）的 CPO 才能让它发生。这也正是我接下来想聊的一层：作为一位 AI-pilled 的 CPO，你怎么看未来的产品团队会长什么样？你现在在招什么样的产品经理？他们今天的角色是什么形态？

[54:45] JZ

I think for many people, um I'm sure this is dialogue that's happening everywhere. This idea of are you a product manager or you're just a product builder? And how many people are product builders? Meaning is it just the product person themselves by functional title or is it also the designer? Is it also the engineer? Um I'm a big believer of the fact that I think everyone should be a product builder. It goes back to my um uh how we operate the team today with captains and taking features end to end. Um what I do look for specifically in in product uh builders who are product managers by training, um I look for a couple of things. Um I found that uh if you're incredibly senior in the sense that you have the judgment, you've gone through the hellfire, you've shipped things that haven't worked and I think for all of us that have shipped things, most of the time it doesn't work in the first go around. If you have if you kind of have that battle-tested judgment, I'm finding that the combination of that experience plus this intense curiosity, this desire to be hands-on, I think you see a little bit of a bifurcation. There are a lot of people who are very experienced and almost scared that their job is changing and um they're feeling more fear than I would say excitement. And I would say that there's another group of people who are very experienced and they've been they've never been more excited. Like I I've never been more excited by the way to not be doing all these things I used to do in the past that took me forever that there was no part of me that wanted to be doing that. Instead, I love, you know, actually like shaping a product, really getting hands-on. Um and then so so being able to find those people who are excited, who are curious, but yet have the the judgment and the reps is really really important. And so again, um this is not necessarily by design, but what I found really interesting was you know, there are a number of people who previously were, you know, CPOs, VP of products, head of products. They've come in and they they're the ones building end-to-end. They're the ones shipping end-to-end. Um and again, they've never been more excited. They've never been more excited to not have a team to have to manage because they realize that a lot of that is just overhead. A lot of that is just coord- coordinate coordination cost. They've realized that a lot of it is just coordination cost and instead they can just be um enabled to get right in there and drive the change they want to see.

我想对很多人来说——我相信这个对话现在到处都在发生——问题是：你是一个 product manager，还是一个 product builder？以及有多少人算 product builder？意思是，这只是职能头衔上的产品人自己吗？还是也包括设计师？也包括工程师？我坚定地相信每个人都应该是 product builder。这又回到我们今天团队的运作方式：设 captain（队长），把功能端到端负责到底。至于我在那些科班出身是 PM 的 product builder 身上具体看什么，我看几样东西。我发现，如果你资历足够深——深到你有判断力，你穿越过炼狱，你发布过没成功的东西——我想我们所有发布过产品的人都知道，大多数时候第一次是不会成功的——如果你有那种千锤百炼的判断力，我发现这种经验加上强烈的好奇心、想亲自动手的渴望，这个组合非常难得。你会看到一点分化：有一大批经验丰富的人，几乎是在害怕自己的工作正在改变，他们感受到的恐惧多于兴奋；而另一批同样经验丰富的人，从来没有这么兴奋过。我自己就是——说真的，我从来没有这么兴奋过：终于不用再做过去那些耗时无穷、我内心没有一丝一毫想做的事了。相反，我热爱的是真正去塑造一个产品，真正亲自动手。所以，能找到那些既兴奋、又好奇，同时还有判断力和实战积累的人，真的非常非常重要。再说一点——这不一定是刻意设计的，但我发现特别有意思：我们有好几个人，之前是 CPO、VP of Product、产品负责人，他们进来之后，正是他们在端到端地构建、端到端地交付。而且他们从来没有这么兴奋过——从来没有因为「不用再管一个团队」而这么兴奋过，因为他们意识到那里面很多都只是管理开销，很多都只是协调成本。他们意识到很大一部分就是协调成本，而现在他们可以被赋能，直接扎进去，亲手推动他们想看到的改变。

[57:07] Aakash

That's crazy. So you have embraced the super senior ICPM. I think you said something pretty crazy actually when we were talking before which was the more senior you get, the longer you've been in product, the smaller your orgs have become. Is that the trend of the future, smaller and smaller product orgs?

这太疯狂了。所以你们全面拥抱了超级资深的 IC PM。我记得我们之前聊的时候你说过一句挺震撼的话：你越资深、在产品这行干得越久，你的组织反而变得越小。这就是未来的趋势吗——产品组织越来越小？

[57:25] JZ

I think so. Yeah, I mean I've had hundreds of people and today I have five PMs and four designers and um there isn't a real reason to grow that um because again, like when you add more people, you add more coordination costs. You actually um it have a harder time making making people feel like they are absolutely responsible for taking something end-to-end. And so, I do think of that as the future. I think that um the best teams are going to be lean, but not so lean that they're starved. And so, it's really important to find that line.

我认为是的。我曾经管过几百人，而今天我手下只有五个 PM 和四个设计师，而且真的没有理由再扩张。因为还是那句话，你每加一个人，就多一份协调成本，而且会更难让每个人感到自己对某件事的端到端交付负有绝对责任。所以我确实认为这就是未来。我认为最好的团队会是精简的，但不能精简到饥饿的程度——找到那条线真的很重要。

[57:59] Aakash

So, you said you do something pretty crazy in your interviews. Can you tell me how you interview people um and really find these gem AI pilled super senior ICPMs?

你说过你在面试里会做一件挺疯狂的事。能讲讲你是怎么面试的吗？怎么真正找到那些懂 AI（AI pilled）的、超级资深的宝藏 IC PM？

[58:10] JZ

I think a lot of people are talking about. Of course, you know, you do a session where people have to build with AI. Um I I think that's all fine and um uh I think it makes a lot of sense to do that. Um it it takes cycles, by the way, to even have a standardized interview loop. Um some companies it makes sense because they're large enough where they're hiring, you know, enough PMs. But again, I I do think many people are saying, "Hey, let's actually get a little bit more um particular about who we hire and make sure that they're really seasoned. And we'd rather pay a few really seasoned people, you know, a lot more than having just an army of people." And so, um what I've been doing, and I I do this, by the way, for every function, not just product or designer, so you know, so and so forth, um is I I do ask people to screen share. And what I found is it is so easy to say, "Hey, we are, you know, I'm AI pilled, we're AI pilled, we do a bunch of stuff with AI." But as soon as you get into um like if you really peek under the hood, you're like, "Actually, I think you're what I call like level one." And maybe I'll just take a moment and talk about the levels for me. Level one is you're talking to, you know, you're talking to ChatGPT, you're talking to Claude. You're really using um AI kind of in a chat mode. Almost like like search mode, right? Like I ask a question, you give me an answer. Level two is where you start to automate a workflow, right? And this is what I was showing earlier around just the first step is like start small. An OS does not start necessarily as an OS, but it starts with a first um automation. Right? A first little piece of workflow that everyone's going to start doing. And so that's level two. Um level three is when you start building, you know, apps. Right? You say, "Hey, you know, it's really important that I um I'm I'm doing this thing. It's really tedious.

我觉得很多人都在聊这个话题。当然，你可以安排一个环节，让候选人现场用 AI 做东西。我觉得这没问题，也确实很有道理。不过顺便说一句，光是搭一套标准化的面试流程就要花不少精力。对有些公司来说这是值得的，因为它们规模够大、招的 PM 够多。但话说回来，我确实觉得现在很多人都在说："我们要对招谁更挑剔一点，确保招进来的人是真正身经百战的。我们宁愿花大价钱请几个非常资深的人，也不要养一大帮普通人。"所以我一直在做的一件事——顺便说，我对每个职能都这么做，不只是产品或设计师，其他岗位也一样——就是我会让候选人共享屏幕。我发现，嘴上说"我很懂 AI，我们团队都在用 AI，我们用 AI 做了一堆事"太容易了。但只要你真的掀开引擎盖看一眼，你就会发现："其实你只处在我说的第一层。"我干脆花点时间讲讲我划分的这几个层级。第一层是你在跟 ChatGPT、跟 Claude 聊天，基本是把 AI 当聊天工具用，几乎就像搜索模式——我问一个问题，你给我一个答案。第二层是你开始把某个工作流自动化，对吧？这就是我之前演示的：第一步就是从小处着手。一个 OS 一开始未必就是一个 OS，它是从第一个自动化开始的，从一小段大家都会开始用的工作流开始的。这就是第二层。第三层是你开始构建应用（app）了。你会说："嘿，我一直在做这件事，它真的很繁琐。

[59:50] JZ

I'm going to build an app to make it like less tedious." And then level four I'd say is where you're actually building I call it shared apps and or um if you really think about the product life cycle, you're you're really shipping to your customers. And so those are the the maybe the four levels um that you can assess yourself on. You can assess a given company on like which of those four levels is the majority of the organization um operating at. And so um what I find is when you actually ask someone to screen share and show them how and show you how they AI, you're very you can very quickly get a sense of are you at level one? Are you basically just talking to chat GPT? Um or have you actually created um like a a some way to really like scale yourself, some kind of workflow, some kind of agent? Or are you starting to build like apps? And or, you know, what are you shipping? Like truly truly shipping? And so really getting to see that um live on screen is really really interesting because otherwise it's really easy just be like, "This is what I do." And it's you know, pulled from LinkedIn or pulled from the latest thing you saw on the internet. Um but actually peeling it back and be like, "What is on your screen?" is is really fascinating.

我要做个 app 让它没那么繁琐。"然后第四层，我会说是你真正在构建我称之为"共享应用"的东西，或者说，如果你从完整的产品生命周期来看，你是真正在向客户交付产品。这大概就是四个层级，你可以用它来评估自己，也可以评估一家公司——这个组织的大多数人处在这四层中的哪一层。我发现，当你真的让一个人共享屏幕、给你演示他是怎么用 AI 的时候，你很快就能看出来：你是在第一层吗？你基本上只是在跟 ChatGPT 聊天？还是你真的搭建了某种能规模化放大自己的东西——某种工作流、某种 agent？还是你已经开始构建 app 了？又或者，你到底在交付什么？真正意义上的交付？所以能在屏幕上现场看到这些真的非常有意思，因为不然的话，别人很容易只是说"我平时就是这么做的"——而那些说法可能是从 LinkedIn 上抄来的，或者是从网上最新看到的东西搬来的。但真正掀开来问一句"你屏幕上到底有什么"，那才真的精彩。

[1:00:58] Aakash

Wow. People don't believe me when I keep saying this is the new interview. This is what I'm hearing. You've heard it from a CPO herself. So, a lot of people are feeling pretty bad about this whole transition. Like there there's a lot of FUD going around in the PM field. If you check out Reddit or something, people are feeling a lot very nervous about this change. They're saying, "Hey, we're compressing out the juniors." You had a really interesting take on this, which is that the best PMs are actually getting more roles and the rest are feeling fear and destruction. Can you unpack that for us?

哇。我一直说这就是新时代的面试方式，大家都不信我。现在你们听到了，这可是一位 CPO 亲口说的。那么，很多人对这整个转型感到相当焦虑。PM 圈里现在弥漫着大量 FUD（恐惧、不确定和怀疑）。你去 Reddit 上看看，大家对这个变化非常紧张，他们说："初级岗位正在被压缩掉。"你对此有个很有意思的观点：最优秀的 PM 其实拿到了更多机会，而其余的人只感受到恐惧和毁灭。能给我们展开讲讲吗？

[1:01:32] JZ

I think it's because one PM can do so much more than ever before, but there aren't that many of them who are that skilled, that have that judgment, who are AI pilled, um who fearlessly are going through all of these pieces and by the way know that one of the most important things forever and will never change about the PM role is that they have to stay close to their customers. Right? So like the the Venn diagram of all of those traits is not large in terms of the actual number of people that fall into that and that's what every company's going to want. And and around the edges it's like why do I why would I go hire someone who is not all of those things? I'm going to have to supplement them in some way and it's going to create overhead. And then when when in in many ways I can take that piece that is not excellent and I can build like, you know, again a workflow and agent around that. So I I think it's really finding who I call the orchestrators, right? The people who are big picture in terms of their thinking, but you know, down to the detail in terms of terms of their execution. Those are the people who are worth their weight in gold and I think that a lot of people who need to be complemented by a designer or complemented by an engineer or like you know, complemented by many many many other people, it just doesn't make sense anymore because why go hire all these people when again one person can be the end-end builder.

我觉得原因在于：一个 PM 现在能做的事比以往任何时候都多得多，但真正具备那种技能、那种判断力、真正懂 AI、能无所畏惧地把这些环节全部打通的人并没有那么多——顺便说，他们还得明白 PM 这个角色永远不变的最重要一点：必须贴近客户。对吧？把所有这些特质画成韦恩图，真正落在交集里的人数并不多，而每家公司都想要这样的人。至于边缘地带，逻辑就是：我为什么要去招一个不具备所有这些特质的人？我还得想办法给他补位，这会产生额外的管理开销。而且在很多情况下，那块不够出色的部分，我完全可以围绕它搭一个工作流、一个 agent 来解决。所以我认为关键是找到我所说的"编排者"（orchestrators）——那些思考上有大局观、执行上又能落到细节的人。这些人才是价值千金的。而那些需要设计师来补位、需要工程师来补位、需要很多很多其他人来补位的人，现在已经说不通了——既然一个人就能成为端到端的 builder，为什么还要招那么多人呢？

[1:02:48] Aakash

It's not me saying it's guys, it's her. I've been preaching this for months and months. This is the future of product management. We just gave you the entire playbook. She just screen shared literally everything, the company OS, how their PMs are knocking down linear tickets. If you want a really amazing job, apply to Laurel. Julie is not just doing this though, right? You actually have so much cool stuff going on. You teach product management at Stanford. I think you had at some point have been involved with Reforge. Can you catch us up outside of Laurel? What's the world of JZ? What's going on?

各位，这不是我在说，是她说的。我已经布道了好几个月了：这就是产品管理的未来。我们刚刚把整套 playbook 都给你们了。她刚才真的是把所有东西都共享屏幕演示了一遍——公司 OS、他们的 PM 是怎么一个个干掉 Linear ticket 的。如果你想要一份真正了不起的工作，去申请 Laurel 吧。不过 JZ 不只在做这些，对吧？你手上还有好多很酷的事情。你在 Stanford 教产品管理，我记得你还参与过 Reforge。能跟我们聊聊 Laurel 之外的事吗？JZ 的世界里都在发生什么？

[1:03:28] JZ

Um I do teach every year at Stanford. Um I do it for the love of um really just getting to meet the next generation of of builders. Um I also get the really awesome benefit of meeting people like the Sasha's of the world who, you know, once took my class, then TA'd for me, and now is at Laurel. Um and uh you know, teaching for me has been a combination of of passion and honestly uh of pipeline. Um so I teach at Stanford, um I teach at Yale, and I teach at Reforge. Um and it's it's just how I think that when you teach something, you have to know it like the back of your hand in order to actually share that with someone else. Um so I I again I just find this really funny. A lot of times I'll teach and then I'll be like, "Ah, good reminder, JZ. Like uh were you doing that today in your day-to-day? Uh were you customer-centric enough? Were you problem-space first and not solution first enough?" And so I just find it both um so gratifying personally, but also um such a great reminder of of what product really is. And I'll I'll say one last thing, which is what's funny is that um so I I I teach AI leadership through Reforge, and that curriculum changes literally by the month. Um you know, we teach it every 6 months, and the amount of change between the 6 months is massive. But when you actually teach the fundamentals, when you teach the what I call like PM 101, those core principles have not changed. You should still always never jump to the solution. And now that you can build faster than ever before, it doesn't mean you just build everything. Like what actually is important is to know why and for whom you're building for, and what is it that you're trying to solve for, and what success looks like, and therefore you actually know you've hit your target. And so what's really ironic is that through teaching all these different levels of of product people over the years, I find that the the fundamentals and the principles have never changed.

我每年都在 Stanford 教课。我做这件事纯粹是出于热爱——能认识下一代 builder。我还有一个特别棒的额外收获，就是能遇到像 Sasha 这样的人：她当年上过我的课，后来给我做助教，现在就在 Laurel。对我来说，教学一直是热情和人才管道（pipeline）的结合。我在 Stanford 教课，在 Yale 教课，也在 Reforge 教课。我的想法是：当你要教一样东西的时候，你必须对它了如指掌，才能真正把它传递给别人。所以我总觉得这事很有意思——很多时候我讲完课会想："啊，JZ，这是个好提醒。你今天的日常工作里做到这一点了吗？你够以客户为中心吗？你有没有做到先看问题空间、而不是先跳到解决方案？"所以教学对我来说，既在个人层面上非常有满足感，也是对"产品到底是什么"的绝佳提醒。最后我再说一点，很有意思的是：我在 Reforge 教 AI 领导力，那套课程内容真的是按月在变。我们每六个月教一轮，两轮之间的变化量是巨大的。但当你去教那些基本功——我称之为 PM 101 的东西——那些核心原则一直没变。你仍然永远不该直接跳到解决方案。现在你能以前所未有的速度构建东西，但这不意味着你什么都要去做。真正重要的是：搞清楚你为什么而构建、为谁而构建，你要解决的到底是什么问题，成功长什么样，这样你才能知道自己是否命中了目标。所以特别讽刺的是，这些年教过各种层级的产品人之后，我发现基本功和核心原则从来没有变过。

[1:05:20] JZ

In fact, they're even more important than ever before, but the tools and the way you operate and the way you can blast through the bureaucracy and feel empowered, that's radically changed. And so as a as a leader, the way you empower your team is very different. Do you have the right culture? Do you have the right team? Do you have the right space for people to even build? Do you have the right operating system? Do you have the right knowledge of what people are doing day-to-day? Do you have all of those pieces? That is changing dramatically, but in your actual, you know, one on one on one basics around what it is that a product person is supposed to be doing, um the speed has changed dramatically, but what you're supposed to be doing at the heart of it, that has not changed.

事实上，它们比以往任何时候都更重要。但工具、你的运作方式、你冲破官僚体系并获得赋能的方式，这些已经发生了翻天覆地的变化。所以作为一个领导者，你赋能团队的方式也变得非常不一样。你有没有对的文化？有没有对的团队？有没有给人们留出可以去构建的空间？有没有对的 operating system？你是否清楚大家每天日常都在做什么？这些要素齐不齐？这一切正在剧烈变化。但回到最基本的层面——一个产品人到底应该做什么——速度确实变了很多，可核心该做的事情，那是没有变的。

[1:06:06] Aakash

What a way to end it. All right, guys, we have hit a crazy milestone when we crossed 40,000 YouTube subscribers. We have also crossed 565,000 average views per listen per episode. When I started this podcast 2 years ago, I wouldn't have believed it. I want all 565,000 of you to flood Laurel's PM applications. For my money, this is like the coolest PM job you could possibly have. And I would say if you are in a PM job where everything we were just talking about feels really foreign and like 10 steps away from what you are, find a job like this with an AI PM CPO like JZ. You are going to learn so much more than if you get to this 4 years from now and then you learn it. Apply to Laurel, get her the best AI PMs in the world. Check out her class at Stanford if you are in the Bay Area so you can really learn AI PM. And if you are a leader, check out her course at Reforge. This is just me saying this. You can see how much value I got out of this episode. You can see I'll be writing about a company OS soon in my newsletter. Jazy has absolutely killed it. Thank you so much, Jazy.

多好的收尾。好了各位，我们达成了一个疯狂的里程碑：YouTube 订阅数突破了 4 万，每期节目的平均收看/收听量也突破了 56.5 万。两年前我开始做这档播客的时候，根本不敢相信会有今天。我希望你们这 56.5 万人都去挤爆 Laurel 的 PM 申请通道。要我说，这可能是你能找到的最酷的 PM 工作。而且我想说：如果你现在的 PM 工作让你觉得我们刚才聊的这一切都很陌生、离你有十万八千里，那就去找一份这样的工作，跟着像 JZ 这样懂 AI 的 PM 出身的 CPO 干。你学到的东西，会远远多于四年后才被迫补课。去申请 Laurel，把全世界最好的 AI PM 送到她那儿。如果你在湾区，去看看她在 Stanford 的课，真正学学 AI PM。如果你是管理者，去看看她在 Reforge 的课程。这纯粹是我的真心话，你们也看到我从这期节目里收获了多少——我很快会在我的 newsletter 里写一篇关于公司 OS 的文章。JZ 表现太出色了。非常感谢你，JZ。

[1:07:12] JZ

Thanks for having me.

谢谢你的邀请。

[1:07:13] Aakash

I hope you enjoyed that episode. If you could take a moment to double-check that you have followed on Apple and Spotify podcasts, subscribed on YouTube, left a rating or review on Apple or Spotify, and commented on YouTube, all these things will help the algorithm distribute the show to more and more people. As we distribute the show to more people, we can grow the show, improve the quality of the content and the production to get you better insights to stay ahead in your career. Finally, do check out my bundle at bundle.akashsharma.com to get access to nine AI products for an entire year for free. This includes Dovetail, Mobbin, Linear, Reforge, Build, Descript, and many other amazing tools that will help you as an AI product manager or builder succeed. I'll see you in the next episode.

希望你喜欢这期节目。请花一点时间确认你已经在 Apple 和 Spotify 播客上关注了本节目、在 YouTube 上订阅了频道、在 Apple 或 Spotify 上留下了评分或评论、并在 YouTube 下面留了言。这些都会帮助算法把节目分发给更多人。节目触达的人越多，我们就越能把节目做大，提升内容和制作质量，给你带来更好的洞见，让你在职业生涯中保持领先。最后，记得去 bundle.aakashg.com 看看我的工具包，可以免费获得 9 款 AI 产品整整一年的使用权，包括 Dovetail、Mobbin、Linear、Reforge、Build、Descript 等许多出色的工具，它们会帮助你作为 AI 产品经理或 builder 取得成功。我们下期节目见。