AI 每周都在变，公司的产品节奏怎么跟上？

一个方案上个月还跑不通，这个月换个模型就能做。设想团队花了两周写需求，排了一个季度的开发，做出来时，用户已经在用另一种方式解决同一个问题。

这是 AI 产品团队很容易遇到的节奏问题。能力边界在移动，立项时的判断也需要跟着重做。只把开发速度提上去，团队依然可能更快地做出一个没人需要的东西。

Lenny 在 2026 年 10 月 11 日发布了一期与 Josh Woodward 的访谈，时长 62 分 11 秒。Josh 负责 Google Labs、Gemini 应用和 AI Studio，节目介绍提到的产品包括 NotebookLM、Project Genie 和 Flow。NotebookLM 已在 2026 年 7 月更名为 Gemini Notebook，讲历史案例时，本文沿用旧名。节目原页、Google 更名公告

读完节目方提供的完整逐字稿，我更关心一个问题：一家公司怎样持续发现新机会，又能及时停止无效投入？这期值得带回团队核对的，有五件事。

• 谁负责追踪新能力？
• 谁带着原型接触真实用户？
• 什么证据值得继续投入？
• 谁能提出停掉项目？
• 实验成功后，由谁接手？

节目标题里“每家公司都要像 Labs 一样运作”的命题由 Lenny 提出。Josh 的回答落到具体组织安排：要有人站在前沿，也要给他们动手的环境，并让实验成果进入公司的业务。这里有不少值得拆开的细节。

好点子来自长期动手的人

Josh 回顾自己的经历时说，好点子很少出现在专门排好的设计冲刺里，更多时候来自几个人不断折腾的小项目。管理者的工作包括给这些人留空间，以及及时发现他们已经做出来的东西。这是他对自己团队的观察，不能据此推导所有脑暴会议都无效。05:43 起

他举了 NotebookLM 的例子。两名团队成员拿来一段由 AI 主持人讨论英国议会辩论的音频，原本枯燥的材料突然变得能听进去，这让他意识到应该继续探索。Google 在 2024 年 9 月发布的介绍，把 Audio Overview 定义为围绕用户资料生成双主持人音频讨论的功能。13:27 起、Audio Overview 官方介绍

这个例子给我的提醒，是给团队留一条展示小样的通道。一个已经跑起来的演示，能让大家讨论具体发生了什么；一页只有愿景的汇报，很容易让讨论停在想象里。会后还在追问、愿意拿自己的材料试一试的人，通常比会上礼貌点头的人更值得继续聊。

“几乎能做”，值得单独记一份清单

Josh 团队有一份 almost possible 清单，追踪那些接近可行的体验。模型更新后，原先卡住的事可能跨过门槛，他们就围绕这个变化组队动手。但技术可行之后，还要对应具体用户问题，并寻找愿意为价值付费的人。07:43 起

我会把这份清单写成三个部分：用户要完成什么、今天卡在哪里、什么变化值得重新试。下面是本文设计的假设示例，具体能力是否达到产品要求，需要团队按自己的任务实测。

这种记录方式能减少两种浪费。一种是每次模型更新都从头猜它能干什么，另一种是沿用三个月前的失败结论，把刚出现的机会漏掉。保留旧方案为什么失败的记录，下次重试才能判断，变化来自模型、产品设计，还是测试条件。

Flow 和 Project Genie 可以帮助理解这种从能力到体验的转换。Google 在 2025 年 5 月把 Flow 定位为结合 Veo、Imagen 和 Gemini 的 AI 电影制作工具；2026 年 1 月的 Project Genie 公告则介绍了创建、探索和重混交互世界的体验，并明确它是研究原型，存在物理表现、控制延迟和生成时长等限制。两者适合用来观察新体验，也需要按各自的产品边界判断成熟度。Flow 官方介绍、Project Genie 官方介绍

产品市场契合：从用户反应走向行为证据

Josh 谈早期产品市场契合，也就是 PMF 时，给了一个很直观的观察方法：把原型带到用户面前，看对方是否眼睛亮起来、身体往前倾。他的语境是 0→1，产品还很早，很多常用的留存与活跃指标尚未提供足够信息。14:37 起

我把这种反应看作方向信号，稳定的 PMF 还需要后续证据。我会接着看三件事：用户会不会主动再来用，会不会愿意投入自己的时间或材料，会不会在演示者离开后依然完成任务。这些是本文补充的验证办法；一次惊艳的演示，能帮团队发现方向，后续使用才会逐步补齐需求证据。

Josh 在后半段把 Labs 分成 0→1、1→10、10→100 三个阶段。早期重视原型反应，到规模化阶段，他明确提到转化漏斗和 CPA，也就是行动或获客成本。不同阶段要看的证据不同，不能把早期观察方式一直沿用到增长阶段。46:26 起

这也解释了他为什么觉得模型榜单被讨论得太多。基准能帮助观察能力变化，用户要解决的却是自己的具体问题。对于做产品的人，值得继续问的是：这次提升究竟让哪个任务变得好做了，用户能否在实际使用中感受到差别？27:18 起

停掉项目，团队往往比老板更早知道

Josh 认为，长期动手的团队通常更早发现项目跑不下去。他描述了一个准备发布的 Gemini 功能：早期反馈不理想，产品经理提出不要上线，他在邮件里公开肯定了这个决定。这个案例来自他的讲述，访谈没有披露功能名称或完整数据。17:57 起

我更关心这个故事里的反馈通道。团队发现了问题，是否敢把坏消息说出来？如果停掉项目意味着承认个人失败，大家就容易继续修饰进度，把“再试一次”变成没有期限的等待。

当然，一轮失败也可能只是方案不合适。Josh 提到，产品常常需要三到五次转向，团队要持续围绕问题寻找办法。对一个内部实验，我会提前约定下轮验证要回答什么，以及到什么时间重新决定是否投入；转向几次的经验数字，不能直接当成所有项目的配额。16:09 起

专业能力还在，三种能力更稀缺

Josh 特别关注三种能力：unlearning rate，即根据新证据放下旧方法的速度；explosive endurance，即能冲刺也能长期维持状态；以及快速建立人与人之间信任的能力。他把协作放在很高的位置，因为项目的执行成本下降之后，人可能更频繁地换搭档、组成新团队。31:36 起

这让我想到一个常见场景。团队用了一周搭出流程，又花了几周修补；新模型发布后，同样的任务已经可以用更简单的方法完成。此时需要有人愿意重做取舍，也需要同事相信，这个改变有证据、有交代，之前的工作留下的经验仍然有用。

他对“人人都是 builder”的说法也保留了警惕。产品、工程、设计，甚至策略和运营的人都可能做出好东西，但组队时仍要看专业所长。他用大学里的主修和辅修打比方，建议年轻产品经理把写原型的能力用于提高自己的产品判断。35:45 起

我的理解是，跨角色动手能降低沟通成本，专业能力决定团队看得见哪些问题。产品经理可以把原型拿给用户，工程师能发现可靠性和成本障碍，设计师能看到交互里的摩擦。大家都能做一点以后，更需要明确谁对哪类判断负责。

内部 Labs，要有独立性，也要有交接通道

Josh 给搭建内部 Labs 的建议可以归成三件事：留出足够独立的探索空间，明确成果要进入现有产品还是成为新产品线，以及允许团队试验公司的工作方式。组织上要有足够的决策距离，在一些公司可能需要直接向 CEO 汇报；他也提到 Google Labs 曾试点新的 builder 职业发展序列，把实验范围扩展到组织制度。47:37 起

这里最难做的是独立性与业务连接同时成立。实验组需要容纳短期看起来奇怪的东西，也要能把结果交给业务团队。Josh 根据自己对 Labs 历史的阅读提醒，研发出新东西之后，公司能不能把它变成产品，常常是另一道难关。这是他的经验判断。43:37 起

如果拿回一家公司执行，我会在启动时就明确谁能试用、谁判断结果、谁负责接手。这些角色可以由少数人兼任，但职责要能说清。否则，实验组做完演示，业务组还要重新理解需求、核对成本、确定承诺，交接很容易重新变成一次立项。

成功标准也可以分开写。

这张表是本文的执行建议。Josh 提供的提醒是别过早扩编，也别急着把所有探索小组收进一张整齐的组织图；他讲过自己曾为项目有了 30 名工程师而高兴，团队却还没有 PMF。人数增长只能说明投入增加。52:27 起

节目尾声还有个细节：他们用小耙子和奖金奖励节省 TPU 资源的人，用金色创可贴奖励修复细小体验问题的人。创新团队也公开表扬节约资源、修补小问题的工作。这些被持续奖励的行为，能让团队看见管理者具体重视什么。58:16 起

路线图缩短，团队节奏拉长

Josh 谈到，团队保留多年愿景，具体路线图通常围绕滚动的六个月展开，优秀的 Labs 小组能在 50–100 天内从想法走到一个有意义的里程碑。这里的里程碑可能是重要验证结果，访谈也没有承诺每个想法都在百天内成为成熟产品。41:31 起

我更愿意把这种安排理解为给判断设置更新时间。方向可以稳定，近期怎么走要允许证据改变。每次重新规划，都应该说清这段时间学到了什么、哪些假设已经过期，以及下一笔投入准备换来什么答案。

团队也要有不同强度的季节。他举例说，I/O 前一些团队会集中冲刺，之后会安排重新探索、动手做新东西的时间。管理者需要讲明什么时候处于冲刺模式，什么时候已经结束，让人能持续做几年。38:59 起

对普通公司，六个月和一百天都需要按自己的资源与反馈速度调整。如果客户只能每季度试用一次，就得把验证周期写进计划。缩短路线图的价值，在于让变化及时进入决策；人员长期处于应急状态，会削弱团队发现新问题的余量。

从一个问题开始

访谈也聊到消费 AI、个人助手，以及未来产品会走向聚合还是大量分散的体验。Josh 对这些方向保留了开放判断，提到团队会用实验检验不同可能性。我喜欢这种态度：手里有对未来的看法，也愿意让具体反馈改变它。22:21 起、54:00 起

如果一个团队准备从这期节目里带走一件事，我会建议先建一份很小的清单。选一个用户已经在反复处理的问题，记录今天的失败原因，约定什么变化值得再试。等原型做出来，把它交给会用这件东西的人，再决定继续、转向或停止。

一家公司有了这种安排，Labs 的价值才会落到具体工作上：有人持续追踪新能力，有人愿意说出无效的投入，也有人把已经验证的结果接过去，让用户用得起来。