Ex-Yahoo CPO Albers Mandates Kill Rates as AI Cuts Prototyping Cost

AI降低原型开发成本，前雅虎CPO Albers主张强制设定淘汰率 软件生产成本的骤降要求产品管理者在前期严格执行淘汰率，以免不受限制的AI原型开发让平台背负难以承受的运维债务。 Michael Albers回顾了其职业生涯轨迹，从McAfee和Netscape早期的技术支持，到Inktomi、Xobni和Yahoo的工程与产品管理岗位；在雅虎任职期间，他曾统筹关键的“Project Dakar”可靠性重构，并妥善处理了大型遗留平台的下线。他指出，随着现代AI工具大幅削减构建软件的边际成本，产品管理中最具决定性的技能已从交付速度转向严谨的判断力、前期评估基准，以及对低影响力想法的高淘汰率。如今，作为独立兼职CPO经营Albers Advisory的他，详细介绍了自己如何依托一套分布式、零信任的三实例智能体架构驱动自主的“单人团队”——该架构结合了严格的Token配额管理、跨Claude层级的动态模型路由以及定期的周五构建冲刺。 随着自动化AI工具让原型交付变得廉价而快速，高管层面的产品判断力——特别是决定“不造什么”的定力——已成为组织中最稀缺且最关键的资产。 (19:05) Michael Albers以自主“单人团队”的形式运营其咨询业务，通过MCP和Syncbox队列，协调部署在两台本地设备以及芬兰一台常开远程服务器上的三实例Claude架构。 (28:44) 为防止Token耗尽，Albers推行了分层模型路由机制（Opus负责幕僚长式的规划，Sonnet处理中层任务，Haiku负责基础文件操作），每周保留30%的额度盈余专门用于周五的编程冲刺。 (0:00) 在负责Yahoo Mail期间，Albers冻结了所有面向消费端的新功能开发，启动了历时数月的“Project Dakar”攻坚冲刺，全力解决技术债务、提高可靠性及推进后端迁移。 (14:01)

Former Yahoo Chief Product Officer Michael Albers argues that as agentic AI drastically lowers the cost of software production, strategic judgment and disciplined filtering have become the defining skills of product leadership. Drawing from enterprise turnarounds and his independent advisory practice, Albers combines structured discovery frameworks with a multi-tiered, secure agentic architecture to amplify executive execution. Product Judgment and Upfront Discovery Frameworks (19:23) Albers contends that when automated tools make software prototyping cheap and abundant, deciding what not to build becomes a leadership team's most critical responsibility. Drawing on past turnarounds at Yahoo—such as freezing feature development under Project Dakar to resolve compounding technical debt, and sunsetting heritage platforms like AIM and Yahoo Groups—he stresses that shipping speed without filtering merely creates operational liability. To counter this, Albers and collaborator Felix Kwinhard propose an upfront discovery model defined by three pillars: explicit success criteria, objective evaluation sets, and a predetermined 'kill rate' (such as committing in advance that only two of ten concepts will advance). He anchors product strategy in three fundamental inquiries: defining the exact customer, isolating the core problem, and explaining why a specific solution is uniquely positioned to win. Forcing teams to articulate these parameters and kill rates in writing creates organizational memory and provides early-career product managers with an explicit framework for learning strategic trade-offs. Three-Instance Agentic Architecture and Security Controls (28:44) Transitioning from leading enterprise organizations to operating as an autonomous solo advisor, Albers constructed an agentic infrastructure powered by Claude Code across three environments: a local desktop, a laptop, and an always-on remote Ubuntu server hosted with Hetzner in Finland. These nodes coordinate through a custom Model Context Protocol (MCP) interface and a shared task-queue directory termed 'Syncbox,' allowing background operations—such as autonomous market research, transcription, and prototype drafting—to execute asynchronously. Having experienced rogue agent behavior and unexpected API expenses during early experiments with OpenClaw, Albers established strict zero-trust operational boundaries. All sensitive tokens and personally identifiable information (PII) are scrubbed locally before requests leave his infrastructure. Permissions are compartmentalized by device; for instance, only his local desktop holds authentication tokens for personal email, and agents operate under restricted scopes permitting read, draft, and archive actions while categorically barring message deletion. Hierarchical Model Routing and Token Economics (0:00) To prevent premature exhaustion of his monthly Anthropic Max quota, Albers routes tasks dynamically based on computational complexity. Claude Opus acts as the primary 'chief of staff brain' for strategic context and orchestration. For routine tasks, the system delegates work to lower-cost models: Claude Haiku manages direct file operations and basic data sorting, while Claude Sonnet executes intermediate reasoning tasks with configurable low, medium, or high effort parameters. Operational context is maintained entirely in hierarchical Markdown files mirrored locally across all three machines. This disciplined model rationing creates a distinct weekly cadence. By Friday morning, Albers typically retains approximately 30% of his weekly token allowance. Because his allocation refreshes every Saturday, he designates Friday as a dedicated 24-hour 'build day' sprint, burning the remaining token surplus on experimental software prototypes, automation scripts, and infrastructure improvements. Organizational Consolidation and Human Cognitive Boundaries (23:49) Albers observes that modern technology organizations are flattening functional divisions, accelerating the adoption of unified Chief Product and Technology Officer (CPTO) roles to eliminate friction between engineering backlogs and product roadmaps—a dynamic he previously managed across a 750-person, $3.5 billion P&L division at Yahoo. In early-stage startups, he notes founders are delaying administrative executive hires, instead allocating early capital toward compute, model tokens, and shared design component systems. While Albers leverages AI for everyday problem-solving—such as utilizing Google Gemini to identify and adjust a replacement bicycle derailleur and Strava AI for post-workout telemetry analysis—he strictly avoids audio assistants or AI tools while mountain biking in Truckee, California. He maintains that unassisted physical exertion provides necessary, uninterrupted cognitive space to cultivate the independent creativity and judgment that strategic leadership requires. Albers illustrates how rigorous model orchestration can expand an individual operator's leverage, yet he underscores that coordinating human teams in an AI-native paradigm remains an unresolved organizational challenge. While generative tools automate production tasks, enduring product success continues to depend on human restraint, explicit evaluation criteria, and the discipline to discard weak ideas early.

## Background 该视频由 YouTube 频道 @Scale 于 2026 年 10 月 9 日发布。内容记录了曾掌管雅虎 75 亿美元产品线的前高级副总裁兼首席产品官 Michael Albers 的深度访谈，重点探讨在 AI 降低研发成本的时代，产品判断力为何变得前所未有地稀缺，以及如何借助智能体架构打造 AI 原生的“一人团队”。 ## TL;DR Michael Albers 回顾了其在网景、Inktomi 期间推动雅虎搜索自研切换，以及在雅虎重构邮件可靠性与关停 Yahoo Groups 等经典产品的过往经历。他指出在 AI 极大降低代码与原型构建门槛的当下，“判断力”已成为核心稀缺资源，产品管理者必须在前端明确成功定义、预设消杀率并坚守 3W 原则。结合当前独立顾问的实践，他深度拆解了以 Claude Opus 为“幕僚长”并结合零信任权限与三实例隔离的智能体协作系统，以及如何通过模型分级调度管理 Token 预算。最后，他分享了利用多模态 AI 维修老自行车的趣事，并强调在户外骑行锻炼时主动屏蔽 AI，以保持专注沉思与思维留白。 ## Atmosphere & style 对话录制于圣克鲁斯披萨店的技术聚会现场，两位相识多年的老同事在轻松松弛的寒暄中拉开序幕，充满了真实自然的极客叙旧氛围。Albers 的表达既有历经多轮互联网周期、统领亿级体量业务高管的深沉与克制，又带着亲手编写脚本与调试 Agent 架构时的纯粹热情。整场对话既像是一场下班后的披萨桌夜谈，又如同一堂兼具宏大商业取舍与微观技术实操的实战复盘课。 ## Bulletin - [19:23](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1163s) 前雅虎首席产品官 Michael Albers 提出“构建变便宜，判断力便成了稀缺品”，主张在 AI 时代探索产品时必须预设“消杀率”（如 10 个原型仅允许存活 2 个），以防止低成本产出的功能拖垮架构。 - [30:18](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1818s) 作为独立顾问，Albers 依托由台式机、笔记本和云端服务器构成的三实例 Claude 分布式架构打造“一人团队”，结合零信任权限与本地知识库完成高阶交付。 - [00:00](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=0s) 通过在幕僚长智能体（Claude Opus）与子智能体（Sonnet / Haiku）间动态分派任务，Albers 实现了 Token 预算优化，并将每周六额度刷新前的周五固定为消耗剩余配额的“构建日”。 - [16:54](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1014s) 回顾雅虎时期，Albers 主导了关停 AIM、Yahoo Answers 以及拥有一亿多注册用户的 Yahoo Groups 等艰难决策，强调维护陈旧架构的隐性成本会严重蚕食组织战斗力。 ## Key takeaways - [06:32](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=392s) 在早期 Inktomi 和雅虎搜索技术（YST）研发中，团队建立的黄金测试集（Golden Sets）和双盲对照评测方法，与当前微调与评测大语言模型（LLM）的底层逻辑一脉相承。 - [13:14](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=794s) 面对 Yahoo Mail 服务宕机与严重技术债务，团队通过全员暂停新业务交付并推行“达喀尔项目”（Project Dakar），彻底扭转并奠定了数亿级用户的系统稳定性。 - [16:54](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1014s) 淘汰拥有 1.15 亿用户的 Yahoo Groups 等老牌产品并非因其彻底失败，而是因为维持陈旧架构的安全合规与工程牵绊成本过高，产品领袖必须果断学会说“不”。 - [19:23](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1163s) 当 AI 将软件原型开发边际成本降至极低时，团队最大的危险是缺乏约束；必须在前端确立评估基准并强制设定消杀率（Kill Rate），过滤掉 80% 的无效原型。 - [21:54](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1314s) 初级产品经理建立商业判断力的核心在于高频试错迭代，并在前端决策中始终穿透“3W 原则”（服务谁、解决什么痛点、为何选择该方案）。 - [23:49](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1429s) 统领 35 亿美元 P&L 的 GM 经验表明，将产品、工程研发与运维收拢至单一领导者（如 CPTO）能有效消弭组织拉锯，推动优先级高度一致。 - [28:44](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1724s) 早期开源 Agent 框架存在隔夜账单爆炸与失控的安全隐患，促使 Albers 转向基于 Claude Code 深度自研数字“幕僚长”系统。 - [30:18](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1818s) AI 系统的权限设计应遵循“零信任”原则，剥夺 Agent 对个人收件箱等核心数据的物理删除权限，并在本地严格执行 PII 信息脱敏与网络隔离。 - [32:34](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1954s) 分级模型路由策略可兼顾智能深度与开销：Opus 负责中枢策略思考，Sonnet 处理常规业务，低阶文件处理自动降级委派给 Haiku。 - [25:42](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1542s) 初创企业可利用 AI 工具推迟设置 CFO 或法务等全职岗位，将宝贵的人力预算直接转化为算力与 Token 投入。 - [38:10](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=2290s) 在日常生活中，多模态 AI 适于处理如自行车故障零件识别等现实问题，但在户外运动锻炼时应主动屏蔽技术干扰，保留大脑独立思考与构建判断力的留白空间。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=0s) 智能体模型分级与 Token 预算管理 在节目的开篇片段中，Michael Albers 分享了他如今作为“一人团队”所搭建的 AI 原生工作流。他将自己的默认中枢——即负责总协调的“幕僚长”（Chief of Staff）智能体的大脑——配置为 Anthropic 的 Claude Opus 模型，以获取最顶级的推理与决策能力。幕僚长智能体会全局掌握所有联系人和知识库，这些知识以结构化的 Markdown 文件层级存储在本地，并在他的三台设备之间实时同步。 在具体分派任务时，系统会根据任务性质动态调度子智能体以节省成本： - **基础任务与文件操作**：幕僚长会自动提示并建议降级调用成本更低的 Haiku 模型； - **进阶推理任务**：系统则切换至 Sonnet 模型，并微调思考强度（Effort 参数，可设置为低、中、高）； - **Token 预算与周五构建日**：这套调度机制直接影响他的工作节奏。通常到周五时，他发现自己还能剩下大约 30% 的 Token 配额。由于配额在每周六早晨刷新，周五便自然演变为了他的“构建日”（Build Day）——在 24 小时内尽情把剩余的 30% Token 消耗在实验和构建新系统上。 ```mermaid flowchart TD accTitle: AI 智能体模型调度与层级架构 accDescr: 展示幕僚长智能体如何根据任务复杂度分发给不同模型，并连接本地 Markdown 知识库。 subgraph Core["中枢调度"] A["幕僚长智能体<br/>(Claude Opus)"] KB[("本地知识库<br/>Markdown 层级<br/>三设备同步")] A <--> KB end subgraph SubAgents["子智能体分发"] direction TB B["简单任务 / 文件操作<br/>(Claude Haiku)"] C["复杂推理任务<br/>(Claude Sonnet + 调节 Effort)"] end A -->|"分派基础任务"| B A -->|"分派进阶任务"| C ``` ### [01:11](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=71s) 节目开场：从雅虎 CPO 到 AI 原生顾问 主持人正式引出本期播客的背景。录音地点位于加利福尼亚州圣克鲁斯（Santa Cruz）的 Leisure Pizza，当时正值一场工程技术聚会。嘉宾 Michael Albers 是一位拥有深厚技术积累与创业背景的产品高管，曾担任雅虎（Yahoo!）的高级副总裁兼首席产品官（CPO），掌管着拥有 750 多名员工、服务全球超过 10 亿用户的庞大产品线。 主持人与 Michael 是相识多年的老同事，话题从双方的叙旧迅速延伸到 Michael 的职业生涯跨越——他见证了互联网技术的多次技术迭代，而如今则凭借一整套高度自动化的 AI 智能体团队，为各类科技公司提供灵活的高管顾问（Fractional / Interim Leadership）服务。 ### [02:38](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=158s) 从阿姆斯特丹到硅谷：结缘硬件与迈克菲早期岁月 回顾早年经历，Michael 出生并成长于荷兰阿姆斯特丹，十岁时随家人搬迁至乌得勒支（Utrecht）郊区。他在大学攻读电气工程专业。主持人提到自己当年也是电气工程专业出身，原因是当时几乎没有独立的计算机科学（CS）项目，Michael 对此深表赞同：当时的荷兰高校并不盛行计算机科学，而电气工程允许他亲手焊接电路板、制作硬件，满足了他对“动手实操”（hands-on）的热爱。 1990 年，Michael 决定前往美国，直奔硅谷圣克拉拉（Santa Clara）。他的第一份工作是在劳伦斯快速路（Lawrence Expressway）旁的一栋简陋小楼里，加入了仅有约 20 名员工的 McAfee Associates（迈克菲）。他在那里与创始人 John McAfee 本人共事，亲历了早期防病毒软件行业从零起步的摸索阶段。 ### [03:45](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=225s) 网景技术支持与互联网基础设施的奠基期 在迈克菲之后，Michael 辗转过几家小型数据库咨询公司，随后于 1995 至 1996 年间加入了正处于互联网浪潮中心的网景（Netscape）。与大众熟知的 Netscape Navigator 浏览器部门不同，Michael 扎根于企业服务器端，担任技术支持工程师，专门负责企业 Web 服务器（Enterprise Server）、代理服务器（Proxy Server）、LDAP 目录服务以及 SSL 证书服务器等。这段经历让他深入接触到了现代互联网的底层支柱——安全通信协议与高可用架构。 面对企业级大客户的高压支持经历，对 Michael 日后的产品思维产生了深远影响： - **一线运维与可用性洗礼**：他长期通过 Unix 终端排查系统故障，管理后台界面。支持像富国银行（Wells Fargo）这样依赖网景安全证书进行在线交易与金融结算的核心机构，一旦服务宕机或出现不稳定，他就必须随时待命并直接应对电话那头怒气冲冲的客户。 - **技术黄金时代的极客氛围**：网景汇聚了顶尖的技术先驱，包括 Apache 服务器的核心作者，以及从瑞士远道而来撰写代理协议规范的专家。 - **网景与微软的图腾之战**：两家巨头在竞争中充满戏剧性的极客恶作剧——网景团队曾把代表自家形象的 Mozilla 绿色恐龙玩偶放在微软园区，而微软也针锋相对地将巨大的蓝色 Internet Explorer“e”字雕塑运送到了网景园区草坪上。 ### [06:32](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=392s) Inktomi 经历与雅虎搜索自研迁移战役 离开网景后，Michael 加入了当时知名的 OEM 搜索与 CDN 基础设施提供商 Inktomi，负责其核心的搜索引擎业务。不久后，雅虎整体收购了 Inktomi。 当时雅虎的前端搜索虽然规模巨大，底层却一直依赖 Google 驱动。收购 Inktomi 的核心战略诉求，正是要在内部重建一套能够与 Google 平起平坐甚至完成替代的自有搜索引擎，该项目在内部被称为 **YST（Yahoo Search Technology，雅虎搜索技术）**。Michael 担任了这场庞大系统迁移工程的产品经理（PM）负责人： - **搜索算法与早期机器学习实操**：项目涉及海量数据的索引与排序，Michael 深入参与了搜索相关性（Relevance）调优、黄金测试集（Golden Sets）构建以及训练数据的标注与评估，这成为他职业生涯最早接触机器学习（ML）的契机； - **编辑团队充当质量守门人**：雅虎拥有顶尖的人工编辑团队，他们通过严格的双盲对照评测（Side-by-Side Comparison），将新算法结果与原有供应商（Google）进行逐项对比。“如果效果达不到基准，就绝不允许上线”，直到团队在相关性指标上全面赶超，雅虎才正式完成底层引擎的彻底切换； - **历史与当下的映射**：Michael 指出，当年为搜索算法建立 Golden Sets 和 Eval（评测集）的方法论，与今天评估与微调大语言模型（LLM）的逻辑如出一辙，核心依然是确立严苛的评估基准与反馈闭环。 ### [08:38](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=518s) 职业转折：从技术支持破局成为搜索产品经理 在探讨职业路径时，Michael 直言产品管理是一门非常特殊的工种，缺乏传统意义上的线性晋升路径，当时甚至几乎没有大学开设专门的 PM 课程。他由技术支持转型为产品经理，源于服务大客户时的主动破局： 在 Inktomi 期间，主要客户之一是微软，对方对搜索结果中的拼写纠错（Spelling Correction）提出了极其严苛的标准。面对复杂的客诉，Michael 没有仅仅停留在被动排查 bug，而是主动跨界与相关性算法团队、工程研发团队坐到一起，主导制定了拼写准确率的定义、验收规范以及衡量“优秀”的具体指标体系。最终，他不仅接管了该功能的端到端交付管理，也顺理成章地转型为全职搜索产品经理，由此拉开了他长达二十余年的产品领袖生涯。 ### [09:41](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=581s) 从初创公司巡礼到“回旋镖”重返雅虎 主持人与 Michael 探讨起早期技术人员的成长轨迹。两人惊奇地发现彼此有着极其相似的开局：主持人最早是作为语音识别研究人员的“写代码助手”入行，随后逐步聚焦于如何将系统推上线、如何长期维护以及处理周边的配套工程代码。在那个年代，产品工程化与产品经理相关的体系并没有正规的学院教学，全凭在实战中“边做边学”（learn on the job），随着时间推移才逐渐形成个人专长。 谈及职业生涯的第二阶段，Michael 回忆起自己离开雅虎后的一系列初创公司经历。他先是加入了 LiveOps，参与构建远程呼叫中心基础设施，并主导研发了一款类似 Mechanical Turk 的平台产品——LiveWork，专门由居家办公的远程团队承接文案审核、图像分析等众包任务。随后，他跳槽至由 Jeff Bonforte 创办的 Xobni 担任产品副总裁，主持人也恰好在此处与 Michael 成为同事。Xobni（即“inbox”倒写拼写）致力于基于用户的收件箱构建底层“人物图谱”（People Graph）。Michael 形象地指出，电子邮件收件箱本身就是一座未经充分挖掘的商业金矿，里面沉淀了庞大的人脉网络、联络方式、往来文档、订单以及历史记录。 离开 Xobni 后，Michael 加入了 CardSpring，投身信用卡绑定优惠（card-linked offers）的开发，帮助商家将优惠券与定向广告直接挂载在消费者的信用卡支付流程中。正是在此期间，Xobni 前 CEO Jeff Bonforte 亲自致电 Michael，邀请他重返雅虎出任 Yahoo Mail 产品负责人。雅虎内部对这种出走后又重新回归的员工有一个广为人知的代称——“回旋镖”（Boomerang）。主持人深情回忆起两人 16 年前初遇的场景：当时 Xobni 团队正处在巨大的动荡与混乱中，原本基于本地 Outlook 插件（DLL）的架构急需整体重构为跨移动端与 Gmail 网页版的服务端云架构，而 Michael 正是在旧金山办公室中统领战局、建立每周 Sprint 节奏的关键管理者。 ```mermaid flowchart LR accTitle: Michael Albers Career Trajectory accDescr: A flow chart showing Michael Albers' journey across early tech roles, startups, and his return to Yahoo. subgraph Early["早期探索"] Y1["Yahoo 早期业务"] LO["LiveOps / LiveWork<br/>众包任务与机械众包"] end subgraph Startups["初创公司淬炼"] XB["Xobni (VP of Product)<br/>收件箱人物图谱与服务端重构"] CS["CardSpring<br/>信用卡挂钩广告与优惠"] end subgraph Return["回旋镖重返雅虎"] YM["Yahoo Mail (产品负责人)<br/>2.25 亿 MAU / 平台可靠性重塑"] end Y1 --> LO LO --> XB XB --> CS CS -->|"Jeff Bonforte 邀约"| YM ``` --- ### [13:14](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=794s) “达喀尔项目”：2.25 亿规模下的可靠性重置 当 Michael 以“回旋镖”身份回到雅虎掌管 Yahoo Mail 时，面对的是一个体量呈数量级膨胀的庞然大物。不同于服务几千或几万名客户的初创团队，此时的 Yahoo Mail 坐拥 2.25 亿活跃用户。然而，重返雅虎的开局绝非一片坦途，产品正深陷极其严峻的稳定性危机与长久积累的运维技术债，频繁遭遇全线宕机与容量规划失误。 其中一次极具破坏性的恶性故障彻底打破了团队的侥幸心理：数台关键邮件服务器宕机，由于未能及时检测拦截，导致大批用户在相当长的一段时间内完全无法访问收件箱，甚至出现部分用户数据丢失的险情。时任产品负责人的 Michael 与通用总经理（GM）Jeff Bonforte 当机立断，做出了一个震撼全团队的铁腕决定：**全员暂停所有新功能开发，启动为期数月的“达喀尔项目”（Project Dakar）**。 正如“达喀尔拉力赛”象征的严苛与耐力，该项目以最高优先级拉齐了产品与工程团队的目标。所有团队按 Scrum 编制被重新编排，全情投入到可靠性加固、客诉排查、容量弹性重构与前端系统修复中，彻底放弃任何业务新特性的交付。 - **组织动员与仪式感**：为了在漫长且高压的危机攻坚中凝聚士气，各个跨职能工作流（workstream）都被赋予了专属代号（例如“忍者团队”Ninja Team）并设计了独立队标 Logo，每周下班后定期举行全员进度汇报（readout）。 - **攻克历史债务**：借由这场全线停摆的契机，工程团队将过去数年中停留在“半半拉拉”状态的旧系统向新系统的数据迁移彻底收尾，拔除了埋藏多年的架构隐患。 - **战略价值与反思**：这场持续数月的战役在身处其中时曾让不少人困惑“为何要付出如此高昂的代价”，但事后证明，如果不果断刹车清障，建立在摇摇欲坠架构之上的任何产品演进都只是空中楼阁。“达喀尔项目”不仅彻底扭转了 Yahoo Mail 的技术底色，更为其后续多年的长期增长夯实了地基。 --- ### [16:54](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1014s) 艰难决断：淘汰经典产品的决断力 随着职责范围从 Yahoo Mail 产品负责人、邮件与通信业务通用总经理（GM）一路晋升至雅虎首席产品官（Chief Product Officer），Michael 迎来了职业生涯中最艰难的挑战——为曾经辉煌但已不符合战略重心的产品实施“安乐死”（End-of-life）。 在这一阶段，Michael 亲自主导关停了一系列承载着几代网民记忆的标志性应用，包括： 1. **AOL Instant Messenger (AIM)**：早期互联网时代最具统治力的即时通讯工具之一； 2. **Yahoo Messenger**：雅虎旗下的老牌通信巨头； 3. **Yahoo Answers（雅虎知识堂）**：Michael 曾与其团队共同孵化过将 Q&A 问答与维基百科融合的原型产品 Answerpedia，对该业务感情深厚； 4. **Yahoo Groups（雅虎群组）**：关停决定中阻力最大、也是体量最为惊人的产品，其在关闭时依然保有 **1.15 亿注册用户和 1,000 万个活跃社群**。 Michael 强调，淘汰这些体量庞大的产品并不是因为它们已经彻底“失败”，而是因为**继续运行与维护它们的隐性代价实在太高**。服务陈旧架构所需的合规成本、安全投入、服务器维护以及关键工程人力的牵绊，严重蚕食了企业的核心战斗力。在商业竞争的现实考量中，产品领导者最重要的使命并不是满足所有人的怀旧情结，而是敢于在资源有限的约束下做出极其痛苦的取舍：“在当下这个时代，学会说‘不’、决定‘不做什么’，比盲目扩张更关键。” 关闭这类上亿用户级别产品的决策绝非一人在真空中做出的独断孤行。它源自与一线工程团队反复深入的成本测算、多方业务指标的信号捕获，以及对整体战略聚焦的深度推演。在外人看来，按下关停键可能只是一纸简单的公告，但其背后是对战略取舍极其深厚的业务判断力（Judgment）。此时主持人指出，这恰恰映射了当今世界的剧烈变化：在生成式 AI 与先进研发工具的驱动下，代码编写的速度前所未有地加快甚至近乎零边际成本，这让判断“到底该造什么、该杀什么”的战略决断力显得前所未有地稀缺。 ### [19:23](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1163s) 生产力泛滥下的判断力：定义消杀率与成功标准 当工程开发与写代码的成本大幅降低后，团队面临的核心问题不再是“我们能造出什么”，而是“我们究竟该把精力聚焦在哪里，什么才能真正为用户和产品带来实质改变”。Michael Albers 指出，产品管理的核心精髓正在于学会喊停与拒绝。正如他近期在一篇文章中所写到的核心论点：“制造变便宜了，判断力便成了稀缺品（Building got cheap, judgment became scarce）。”在过去，领导者需要拿出判断力去关停像 Yahoo Groups 这样庞大却老化的项目；而在 AI 时代，当一个团队一周内能轻松产出上百个原型时，决定“不做什么”的难度呈指数级上升。 为了避免团队把所有随意做出的原型一股脑塞进生产环境并背上沉重的系统运维包袱，Albers 强调必须在产品探索周期的最前端完成三件事：首先明确定义“何为成功”，其次设定强制的“消杀率（Kill Rate）”，最后制定严谨的评估基准（Eval Criteria）。Albers 曾与好友 Felix Khunhardt 共同撰写了一套探索指南，其核心原则就是：如果摆在面前有 10 个方向，必须预先定好指标，确保只让其中 2 个存活下来，其余 8 个必须果断淘汰。Albers 感叹道，大多数组织最致命的问题在于从不将“判断力”落诸笔端，评判好坏的标准永远只存在于某些资深骨干的脑袋里，导致组织缺乏长久记忆；而通过在前端公开讨论并确立评估集，不仅能保护系统架构免于臃肿，也是培养初级产品经理判断力的最佳试验场。 ```mermaid flowchart TD accTitle: Product Discovery and Evaluation Framework accDescr: A process showing upfront success definition, kill rate filtering, and eval sets leading to production. subgraph Upfront["前端定义阶段 (Upfront Discovery)"] A["明确成功标准<br/>(Define Success)"] --> B["预设消杀率<br/>(Set Kill Rate, 如10选2)"] B --> C["制定评估基准<br/>(Eval Sets)"] end subgraph Execution["执行与生产阶段"] D["快速生成大量原型<br/>(100+ Prototypes/周)"] C --> E{"严格过滤评估"} D --> E E -->|"淘汰 80%"| F["果断弃用 (Kill)"] E -->|"仅存活 20%"| G["进入生产环境<br/>(Production)"] end ``` ### [21:54](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1314s) 新一代产品经理如何磨炼判断力与“3W 原则” 面对主持关于年轻产品经理如何建立商业与产品判断力的提问，Albers 直言，高频使用软件工具固然是基础，但真正的加速器是“极速迭代”。以往的老一代产品人可能需要数月甚至更长时间才能把一个构想落地并验证好坏；而现在借助新型开发工具，年轻人几天之内就能搭建并测试多个原型，快速体会到“这个行不通、那个也没戏、唯独这个好像切中痛点”。这种高频的失败与验证，极大地缩短了积累直觉与商业判断所需的周期。 除了亲手试错以及通过网络、播客和经验分享吸收前人认知外，Albers 认为年轻 PM 建立判断力最扎实的抓手，就是深度参与前端决策的讨论，牢牢把握住产品世界中最质朴的“3W 原则”： - **Who（你的客户是谁）：** 必须极其具象地描摹出到底是在为谁服务。 - **What（你在解决什么问题）：** 脱离花哨的功能堆叠，直击用户最真实、最急迫的痛点。 - **Why（为什么选择你的方案）：** 为什么你提供的方法是正确的答案？为什么是由你（或你的团队）来做这件事？ ### [23:49](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1429s) 从产品负责人到 GM：统领 35 亿美元 P&L 与职能融合 随着职业生涯推进，Albers 在雅虎由负责通讯与邮箱业务的产品高管逐步晋升为总经理（General Manager）。这一跃迁带来了职责维度的剧变：他不再仅仅负责产品功能规划，而是将产品、DevOps 运维、工程研发以及设计团队全数收入统管范围，直接肩负起 750 人团队的运作以及高达 35 亿美元的全面损益表（P&L）。这种单一领导人全权负责的架构，彻底铲除了大公司常见的内耗根源——即产品团队与工程团队各自怀揣一套优先级指标、反复扯皮拉锯的常态。这与当年 Project Dakar 战役如出一辙，所有人都在同一张优先级清单下朝同一个目标迈进。 Albers 敏锐地指出，整个科技行业目前正在向这种高度统一的方向回归，甚至出现了越来越多的 CPTO（首席产品与技术官）角色。企业越来越倾向于寻找“兼具深刻产品品味的工程领袖”，让技术与业务在最高层决策中完成合并。因为在快节奏的当下，核心问题永远是“我们是否在造正确的东西”；只有消弭产品战略与工程落地之间的鸿沟，才能确保成功指标、交付成果与战略方向真正焊死在一起。 ### [25:42](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1542s) 初创团队的组织重塑与“一人+Agent”咨询模式 在探讨初创企业该如何架构团队以规避产研摩擦时，Albers 直言传统那种“PM 画完原型转给设计、设计画完界面移交工程”的线性流水线已经过时。现代小团队必须保持高度流动性。他提到，现在许多聪明的初创创始人甚至会主动推迟招募首席财务官（CFO）或法务负责人，因为 AI 工具已经能够提供足够应付初期的专业建议；创始人宁可把省下来的昂贵人力预算投入到基础设施和“Token（模型调用代币）”上。 在具体的协作层面，Albers 建议各职能应在最前端共享上下文，而不是事后打补丁： - **设计前置规范：** 设计师提前提供统一的风格指南与感官规范，使产品经理即使用工具随手搭出的原型也具备成熟的外观质感。 - **工程前置约束：** 工程师在启动前就讲清系统底层限制、基础设施架构以及所选用的数据库特性，避免 PM 费尽心力设计出方案后，工程师只能泼冷水说“我们数据库根本跑不动这种查询”。 - **汇报线收敛：** 若初创团队拥有一位懂技术的产品负责人，工程与产品职能完全可以直接合并向其汇报，从体制上杜绝站队博弈。 Albers 自己的职业选择也印证了这一敏捷趋势。2021 年离开雅虎后，他告别了管理庞大组织与数十亿美元盘子的职业生涯，成立了顾问公司 Albers Advisory。他以“一人公司（Team of One）”的形式运作，背后由一组高度专业化的 AI Agent（智能体系统）协同支撑。他以兼职（Fractional）或过渡期（Interim）高管的身份深入各家企业，专门负责在组织发生重组、高管离职或出现产品战略断档时迅速补位，提供即时而老练的产品领导力。 ### [28:44](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1724s) 打造“一人团队”与 AI 幕僚长：架构演进与安全教训 在告别雅虎转为独立顾问后，Michael Albers 主要以兼职首席产品官（Fractional CPO）或临时产品主管的身份协助企业理顺产品团队、推动产品落地。对于这种“一人团队（team of one）”的工作模式，主持人感叹这既像是某种理想国，也充满了挑战。Michael 坦言自己喜欢掌控感，“一人团队”能将控制权发挥到极致。在探索 AI 赋能工作流的早期，他先后尝试了 Lovable 和 Bolt 等生成式工具，随着 Claude 模型的崛起，他开始深入探索 Agent 系统的构建。 作为曾在大型组织管理数十亿美元业务的高管，Michael 过去表现最出色的时候往往得益于一位顶尖的“幕僚长（Chief of Staff）”——她能时刻督促他保持诚实、紧盯各项进度条、确保所有项目轨道齐头并进。因此，他打造 AI 系统的首要目标就是构建一个数字化幕僚长。他曾开玩笑想直接用前任幕僚长的名字为系统命名，但随即打消了念头，“觉得这未免有点太让人毛骨悚然了”，后来这个系统给自己取了一个名字。然而，在最初基于开源 Agent 框架（如 OpenClaw）尝试时，他迅速踩了两个大坑：第一是安全态势令人严重不安，缺乏足够的信任与防护机制；第二是有几次 Agent 在半夜失控“跑偏（went rogue）”，一夜之间烧掉了巨额 API 费用。这让他意识到现成框架尚不成熟，必须重新设计底层架构，从而转向了基于 Claude Code 的深度定制。 - **早起探索路径**：从最初的快速成型工具 Lovable、Bolt，逐步过渡到 Claude Code。 - **失控与教训**：早期开源 Agent 方案存在严重安全隐患且缺乏熔断机制，曾导致隔夜算力账单爆炸。 - **命名趣事**：AI 幕僚长最初拟用现实中优秀前下属的名字，后因“略显诡异”作罢，最终由系统自主命名。 --- ### [30:18](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1818s) 三实例分布式架构与“零信任”权限安全策略 吸取了早期的安全与失控教训后，Michael 构建了一套由三个 Claude 实例组成的分布式协同网络，通过物理隔离与作用域界定来实现精细化访问控制。这三套实例各司其职，并通过一套自建的 MCP（Model Context Protocol）接口与名为“Syncbox”的任务收件箱机制进行跨实例调度： ```mermaid flowchart TD accTitle: 三实例 Claude 分布式协同架构 accDescr: 本地台式机、笔记本与芬兰 Hetzner 云端服务器通过 MCP 接口与 Syncbox 任务收件箱互相协同与隔离。 subgraph Endpoints["终端层（按安全信任隔离）"] DT["本地台式机 (Desktop)<br/>• 唯一保留个人邮箱 Token<br/>• 核心安全中枢"] LT["移动笔记本 (Laptop)<br/>• 便携办公<br/>• 按需动态接入"] SRV["云端 Ubuntu 服务器 (Finland)<br/>• 托管于德国 Hetzner 机房<br/>• 7x24 小时常驻运行"] end subgraph CoreHub["调度与协同中枢"] MCP["MCP 协议接口<br/>(Model Context Protocol)"] SYNC["Syncbox 任务收件箱<br/>(跨实例投递与分发任务)"] end subgraph Tasks["云端常驻任务集群"] T1["调研分析 / 数据监控"] T2["待办机器人 (Todo Bot)"] T3["Telegram 录音转录"] T4["Team in a Box 软件构建"] end DT <--> MCP LT <--> MCP SRV <--> MCP MCP --- SYNC SRV --> T1 SRV --> T2 SRV --> T3 SRV --> T4 ``` 在权限控制上，Michael 奉行“零信任”理念：“从安全防护的角度出发，最开始我对它是‘完全不信任’的。AI 必须自己去争取信任，我会一点一点、循序渐进地向它开放访问权限。”他为个人系统建立了一套严格的信任与安全策略： 1. **网络与凭证隔离**：本地台式机是唯一拥有个人邮箱访问 Token 的机器，云端服务器绝不允许直接访问个人核心通讯。 2. **敏感信息脱敏**：在数据离开本地环境流向外部大模型厂商之前，严格执行本地 PII（个人身份信息）过滤与 Token 掩码处理。 3. **彻底剥夺删除权限**：系统对个人收件箱拥有全局读取、草稿生成、邮件归档权限，但一律“严禁赋予删除权限（No deletion rights）”，从底层规避数据被抹除的毁灭性风险。 4. **云端常驻枢纽**：芬兰 Hetzner 服务器全天候在线，运行 Telegram 音视频转录机器人、全网调研监控，并挂载他称之为“盒装团队（Team in a box）”的 Agent 矩阵，承载从需求文档（PRD）到代码原型落地的自动化开发。 --- ### [32:34](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1954s) 咨询赋能与巧妙的 Token 预算管理 这套 AI 幕僚长与 Agent 体系极大地放大了 Michael 作为兼职 CPO 的交付能力。在实际咨询工作中，系统能自动化执行行业趋势对比研究、深度竞品分析，并能直接连接 Google Drive 账号，自动生成调研问卷、统计处理反馈结果，甚至向受访者自动发送跟进邮件。凭借这套在后台默默运行的高效管线，他即便只拿着一部智能手机远程移动办公，也足以支撑起对多个客户的高质量交付。 随着 Agent 规模化运行，Token 成本与额度管理成为了业界关注的痛点。Michael 订阅了每月 100 美元的 Anthropic 顶格方案，在早期摸索时，他也曾吃过“刚到周二就把整周额度彻底烧光”的苦头。为了实现性价比与智能密度的平衡，他总结出了一套精妙的模型分级路由策略： | 层级 / 角色 | 采用模型 | 适用任务场景 | 成本与推理力度配置 | |:--- |:--- |:--- |:--- | | **幕僚长大脑** (Brain) | Claude Opus | 核心逻辑仲裁、复杂策略思考、上下文深度理解 | 默认最高智能级别，负责决策分流 | | **日常中枢** (Delegation) | Claude Sonnet | 兼顾逻辑与代码生成的标准业务，中等难度分析 | 手动或动态调整 Effort 参数（Low / Medium / High） | | **子任务执行** (Sub-agents) | Claude Haiku | 批量文件读写、简单数据提取、低阶机械化操作 | 极低成本快速执行，由幕僚长自动降级派发 | 在这个体系中，所有的个人上下文与企业知识库都以分层 Markdown 文件的形式保存在本地，并在三台实例之间实现同步。当 Michael 与幕僚长对话派发任务时，幕僚长会评估复杂度并主动提议：“我正准备委派一个子 Agent 处理文件，建议切换为 Haiku 模型以节约成本。” 更有趣的是他利用额度重置机制制定的“周五黑客日”节奏：由于账户的 Token 使用限额会在每周六早晨清零重置，每到周五早晨，他若发现本周业务相对平稳、账户里还富余 30% 的 Token，便会在接下来的 24 小时内全马力“狂飙”。他把周五固定为自己的原型构建日（Build Day），将这些即将过期的算力挥霍在有趣的侧边项目、独立 App 原型或是底层自动化基础设施的迭代上，“绝不白白浪费算力”。 --- ### [35:42](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=2142s) AI 范式转移下的领导力：好奇心、团队协同与闪电问答 回顾自己跨越数十年的职业生涯，Michael 见证了科技行业的数次关键技术拐点：从早期互联网的爆发，到雅虎引领的搜索引擎演进、网络门户媒体化，再到移动互联网大潮，直至当下的 AI 革命。他直言：“这又是一个历史性的转折点，而且我认为这个拐点可能与以往任何一次都截然不同。” 面对眼下许多产品经理因为忙于繁重日常工作而产生的普遍“错失恐惧症（FOMO）”，Michael 建议从业者不必恐慌，而应保持强烈的好奇心。他指出，拥抱 AI 并不是为了让自己“失业”，而是为了给自身装上“超级超能力（Superpowers）”，去完成过去单枪匹马不可能做到的事。不过，从技术领导力的视角来看，真正的挑战往往在于组织层面： - **个体提效不等于团队协同**：单兵作战借助 AI 变得更强相对容易，但如何让整个产品与工程团队协同进化，是一套截然不同的难题。 - **构建极其低廉，判断愈发稀缺**：“如果现在你能随心所欲快速造出任何原型，这绝不意味着你应该把造出来的所有东西都推向生产环境。”决定“不做什么”的判断力比以往任何时候都更加致命。 在访谈尾声的闪电快问快答环节中，主持人询问他近期最惊艳的 AI 新工具有哪些。除了日常重度依赖的 Claude 之外，Michael 特别提到了 Manus。他表示自己最近深度使用了 Manus 并且对其交付的工作流产物印象深刻。无论是其引导用户逐步推进任务的体验（handholding）、清晰结构化的输出能力，还是能够原生引入并调用外部 SDK 的机制，都展现出了极高水准的工程与产品构思。 ### [38:10](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=2290s) 生活中的 AI 实践与运动时的思维留白 在结束关于工作端 AI 工具的探讨后，话题转向了日常生活中的 AI 应用。迈克尔·阿尔伯斯（Michael Albers）分享了他最近利用多模态 AI 解决机械故障的经历：他的一辆已有近十年车龄的自行车后变速器（derailleur）坏了，需要更换配件。他直接使用 Google Gemini 对损坏的变速器拍了张照片，AI 准确识别出了对应的具体老旧型号。迈克尔顺利下单采购，拿到零件并安装完毕后，在做精密调试时，他又拍了张照片让 AI 指导调整。整套通过拍照、识别、采购到调校的闭环体验极为顺畅。 然而，在硬币的另一面，迈克尔明确表示自己在运动锻炼时绝对不需要 AI。“当我骑车时，我不需要 AI 在我耳边喋喋不休，”他笑着解释道。对他来说，户外骑行是一段完全独处的专属时间，大脑可以自由放空和沉思全局。他戏称这正是自己“磨砺判断力”并激发创意的时刻，只需要依靠自己的大脑，而绝不希望被技术侵扰。 ```mermaid flowchart TD accTitle: 现实生活中的 AI 边界：机械辅助与思维留白 accDescr: 对比 Michael Albers 在自行车维修中使用 Gemini 与在实际骑行锻炼中屏蔽 AI 的场景。 subgraph Repair["现实生活维修：多模态 AI 介入"] A["后变速器损坏（近十年老车）"] --> B["拍照上传至 Google Gemini"] B --> C["精准识别匹配具体型号"] C --> D["下单配件并自主安装"] D --> E["再次拍照借助 AI 完成调校"] end subgraph Riding["户外运动锻炼：纯粹思维留白"] F["独处骑行锻炼"] --> G["完全隔绝 AI 声音与提示"] G --> H["放空沉思、构建判断力与激发创意"] end ``` ### [39:16](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=2356s) 电动山地车（e-MTB）与传统自行车的平衡之道 谈及山地骑行，主持人询问如果在今天添置新车，会选择电动助力山地车（e-bike）还是传统的无助力山地车。迈克尔透露自己两样都有，并且会交替使用。他在加州的特拉基（Truckee）有一处住所，那里是他常年进行山地骑行的大本营。在特拉基骑车极具挑战性，不仅地处高海拔，而且面临大量陡峭的山路爬坡。 迈克尔的策略是交错进行：某一天他会骑上传统的普通山地车，依靠纯体力“硬啃”爬坡，挑战体能极限；而如果第二天依然想进山畅游，他便会换上电动山地车（e-mountain bike）。他提到自己有些骑行朋友是极端的传统派，坚决抵触任何电动山地车，但在迈克尔看来，这种执念完全让他们错失了乐趣。电动助力能让人“骑得更远、更久、更尽兴”，对于探索未知的路线地形而言堪称绝妙利器。因此他强烈建议两类车结合并用。 - **骑行基地**：加州特拉基（Truckee），具备高海拔和高强度爬坡等极限越野环境。 - **骑行哲学**：交替骑行。传统山地车用于高强度体能磨炼；电动山地车（e-MTB）用于长距离地形探索，二者优势互补。 ### [40:06](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=2406s) 借助 Strava 进行骑行数据洞察与尾声 在骑行结束后的复盘环节，迈克尔是个十足的“数据派”。他平时重度依赖 Strava，每次骑行一回到家，他就会坐下来细致研读各项指标：心率区间分布如何、爬升高度是否达标、整体功率输出是否合理等。 Strava 最近引入的 AI 智能分析功能也深得他的喜爱。系统会自动提炼出亮眼表现并生成反馈，例如提醒“这是你近段时间以来骑行距离最长的一次”，或者分析“你大部分时间都处于特定的训练区间内”。迈克尔认为 Strava 将这项智能分析整合得恰到好处，虽然在骑行过程中他拒绝 AI 的声音打扰，但在骑行结束后的静态数据分析中，AI 提供了极佳的辅助价值。 播客最后，主持人感谢了迈克尔的真诚分享，并向听众预告了即将于 10 月 28 日在门洛帕克（Menlo Park）举办的 `@Scale: Product 2026` 线下峰会。届时，来自 Meta、Nvidia、Microsoft、Intel 以及 Pindrop 等顶尖科技公司的专家将齐聚一堂，共同探讨 AI 技术创新的最新前沿。 ## Notable quotes > [06:32](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=392s) 如果效果达不到基准，就绝不允许上线 — Michael Albers > [16:54](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1014s) 在当下这个时代，学会说‘不’、决定‘不做什么’，比盲目扩张更关键。 — Michael Albers > [19:23](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1163s) 制造变便宜了，判断力便成了稀缺品（Building got cheap, judgment became scarce） — Michael Albers > [19:23](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1163s) 如果摆在面前有 10 个方向，必须预先定好指标，确保只让其中 2 个存活下来，其余 8 个必须果断淘汰。 — Michael Albers > [28:44](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1724s) 觉得这未免有点太让人毛骨悚然了 — Michael Albers > [30:18](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1818s) 从安全防护的角度出发，最开始我对它是‘完全不信任’的。AI 必须自己去争取信任，我会一点一点、循序渐进地向它开放访问权限。 — Michael Albers > [30:18](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1818s) 严禁赋予删除权限（No deletion rights） — Michael Albers > [32:34](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1954s) 我正准备委派一个子 Agent 处理文件，建议切换为 Haiku 模型以节约成本。 — 幕僚长智能体 > [32:34](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=1954s) 绝不白白浪费算力 — Michael Albers > [35:42](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=2142s) 这又是一个历史性的转折点，而且我认为这个拐点可能与以往任何一次都截然不同。 — Michael Albers > [35:42](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=2142s) 如果现在你能随心所欲快速造出任何原型，这绝不意味着你应该把造出来的所有东西都推向生产环境。 — Michael Albers > [38:10](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=2290s) 当我骑车时，我不需要 AI 在我耳边喋喋不休 — Michael Albers > [39:16](https://www.youtube.com/watch?v=5UbqvkCk-m4&t=2356s) 骑得更远、更久、更尽兴 — Michael Albers ## Mentioned Michael Albers, John McAfee, Jeff Bonforte, Felix Khunhardt, Yahoo!, AOL, Netscape, McAfee Associates, Inktomi, LiveOps, Xobni, CardSpring, Albers Advisory, Google, Microsoft, Wells Fargo, Anthropic, Hetzner, Meta, Nvidia, Intel, Pindrop, Claude, Claude Opus, Claude Sonnet, Claude Haiku, Claude Code, Google Gemini, Manus, Lovable, Bolt, OpenClaw, Yahoo Mail, Yahoo Search Technology (YST), AOL Instant Messenger (AIM), Yahoo Messenger, Yahoo Answers, Yahoo Groups, Answerpedia, Netscape Navigator, LiveWork, Strava, Telegram, MCP (Model Context Protocol), Syncbox, Project Dakar, @Scale Podcast, @Scale: Product 2026 ## Video description What happens when building gets cheap? In this episode of the @Scale Podcast, AI-native product executive Michael Albers shares lessons from more than two decades building consumer products at scale and explores why judgment may be one of the most valuable skills in the age of AI. Michael spent much of his career at Yahoo! and AOL, ultimately serving as Yahoo!’s SVP and Chief Product Officer over a $7.5B+ portfolio serving more than a billion users. Earlier in his career, he was the primary product lead in moving Yahoo! Search off Google and onto its own search engine, and later served as VP of Product at Xobni. Today, Michael runs Albers Advisory, where he takes on fractional and interim product leadership roles. Since 2024, he has also been building his own AI systems hands-on, developing an AI-native approach to product work. In this conversation, Michael explores: • Why “building got cheap, judgment became scarce” • How AI is changing the economics of building products • Why deciding what NOT to build may become more important • Lessons from leading products at Yahoo! and AOL • Moving Yahoo! Search off Google and onto its own search engine • Making difficult product and portfolio decisions • The importance of defining success before building • How to evaluate ideas and determine what deserves to survive • Building an AI-native “team of one” • Using AI agents and custom systems to augment product leadership • What product leaders need to prioritize as AI accelerates the pace of building Michael Albers is based in Menlo Park and runs Albers Advisory, where he works with companies in fractional and interim product leadership roles. 🎙️ Subscribe to the @Scale Podcast for more conversations with the engineers, product leaders, and technology experts shaping what comes next. Learn more about Albers Advisory here: https://www.albersadvisory.biz/?utm_id=h8p91 Want to join more conversations like this in person? Join us at our next event, @Scale: Product 2026 in Menlo Park! Register here: https://atscaleconference.com/events/product-2026/ 00:00 Token Smart Model Picks 01:11 Intro 01:51 Reconnecting And Background 02:38 Amsterdam To Silicon Valley 03:45 Netscape Support Lessons 06:32 Inktomi To Yahoo Search 08:38 Tech Support To Product 10:17 Startup Tour Xobni Cardspring 12:55 Back To Yahoo Mail Scale 14:01 Project Dakar Reliability Reset 16:54 Hard Calls Killing Products 19:05 Judgment Over Shipping Speed 21:54 How PMs Build Judgment 22:45 Learning From Others 23:25 Three Ws Of Product 23:49 Becoming A GM 24:41 Unifying Product And Engineering 25:42 Structuring Startup Teams 28:04 Leaving Yahoo For Advisory 28:55 Building A Team Of Agents 29:55 Security And Permissions 33:23 Token Budgeting Hacks 35:42 Leadership Through AI Shifts 37:17 Lightning Round AI Tools 38:29 Biking And AI Balance 40:08 Ride Analytics With Strava 41:02 Closing And Event Invite [Source](https://www.youtube.com/watch?v=5UbqvkCk-m4)

[6:32] Michael Albers: 如果效果达不到基准，就绝不允许上线 [16:54] Michael Albers: 在当下这个时代，学会说‘不’、决定‘不做什么’，比盲目扩张更关键。 [19:23] Michael Albers: 制造变便宜了，判断力便成了稀缺品（Building got cheap, judgment became scarce） [19:23] Michael Albers: 如果摆在面前有 10 个方向，必须预先定好指标，确保只让其中 2 个存活下来，其余 8 个必须果断淘汰。 [28:44] Michael Albers: 觉得这未免有点太让人毛骨悚然了 [30:18] Michael Albers: 从安全防护的角度出发，最开始我对它是‘完全不信任’的。AI 必须自己去争取信任，我会一点一点、循序渐进地向它开放访问权限。 [30:18] Michael Albers: 严禁赋予删除权限（No deletion rights） [32:34] 幕僚长智能体: 我正准备委派一个子 Agent 处理文件，建议切换为 Haiku 模型以节约成本。 [32:34] Michael Albers: 绝不白白浪费算力 [35:42] Michael Albers: 这又是一个历史性的转折点，而且我认为这个拐点可能与以往任何一次都截然不同。 [35:42] Michael Albers: 如果现在你能随心所欲快速造出任何原型，这绝不意味着你应该把造出来的所有东西都推向生产环境。 [38:10] Michael Albers: 当我骑车时，我不需要 AI 在我耳边喋喋不休 [39:16] Michael Albers: 骑得更远、更久、更尽兴

[3:45] Michael Albers: Dealing with somebody angry on the other side of the phone really exposed me to, you know, what it takes to build strong servers and helping customers with their problems. [6:32] Michael Albers: Yahoo had an amazing editorial staff and they were the gatekeepers at the end of the day. You know, they did side-by-side comparison to different models that we had, different algorithms, how we compared against the incumbent provider. And they held the bar. You know, if it wasn't good enough, then it wouldn't go out. [19:23] Michael Albers: building got cheap, judgment became scarce [28:04] Michael Albers: team of one powered by a bunch of agents [31:11] Michael Albers: I do not trust you. You have to earn your right to trust and... I will slowly give you access and slowly give you permissions. [35:42] Michael Albers: an inflection point like no other [38:27] Michael Albers: that's where I build my judgment. It's where my creativity kicks in. [39:16] Michael Albers: entirely missing out

[0:00] my default today is is Opus. Um, you [0:03] know, it's a little smarter. And so my [0:04] chief of staff's brain is Opus as a [0:06] model. Um, but then when I need to do [0:08] file operation or simple things, I have [0:10] a conversation. It actually knows it. It [0:12] tells me I'm about to assign a sub [0:14] agent. I suggest we use Haiku. Okay. [0:16] Cheaper model, way cheaper to use, [0:18] right? And it does that then, right? If [0:20] I need something slightly more more [0:22] smarter, um, uh, it it's it it [0:25] introduces the sonnet model, right? And [0:27] there I even said effort, right? you can [0:29] set, you know, low, medium, high effort, [0:31] right? And so we adjust that. So every [0:33] time I talk to, you know, we dish out a [0:36] task to my agent, right? I I talk to my [0:38] chief of staff, which has all my [0:40] contacts, all my knowledge stored [0:42] locally in markdown files in a [0:45] hierarchy, uh, synced across my three [0:48] instances. Every time something is [0:50] delegated, um, then, uh, we talk about [0:53] what model to use. Y and this is how I [0:55] actually manage my workday. And what [0:57] then actually happens is usually by [0:58] Friday I'm like, "Oh, I got 30% tokens [1:01] left, which is pretty good." And then [1:03] I've turned Friday into my build day [1:05] because my tokens reset Saturday [1:07] morning. And so I have 24 hours to blow [1:09] the 30% of my tokens. Welcome back to [1:12] the Atscale podcast where we share [1:14] [music] [1:15] stories of technical innovation from top [1:18] industry leaders. You just heard a clip [1:20] from a special episode we recorded [1:21] [music] at Leisure Pizza in Santa Cruz, [1:24] California during an engineering meetup [1:26] with Michael Alver. Michael is a startup [1:28] veteran and [music] former chief product [1:30] officer at Yahoo where he led a team of [1:32] 750 plus people serving over a billion [1:35] users and now he advised tech companies [1:38] with a full team of AI agents. Let's [1:41] dive into our conversation about the [1:43] [music] latest agent tech product [1:45] trends, leadership lessons, and tips for [1:48] product leaders to actually manage teams [1:50] [music] and tokens. So, it's been a long [1:53] time that we haven't seen each other [1:55] >> for quite a few years. [1:56] >> For the audience, I want to make sure [1:58] like, hey, we know each other. We've [1:59] worked together in the past and knowing [2:04] you, I thought it would be like super [2:06] interesting for you to come on this [2:08] podcast. [2:08] >> Thank you. and to actually share your [2:11] experience because you've for the for [2:14] the many years you've worked your way [2:15] into many iteration of technology up to [2:20] this point where you're kind of doing a [2:22] oneman show but before that you had a [2:25] variety of experience [2:27] >> y [2:27] >> so let's start and let's talk about you [2:31] know you come from the Netherlands you [2:33] come from Amsterdam let's start there [2:35] like what's your background where did [2:37] you go to school and so Uh like you [2:39] said, I was born and raised in [2:40] Amsterdam, the Netherlands. Uh lived [2:43] there till I was 10 years old and then [2:45] we moved to the BBS where I went to [2:47] school in a city called Utre. Um I [2:50] studied electrical engineering. Um I [2:52] wanted to go into industrial technology [2:53] or industrial engineering. [2:54] >> And tell me at that time like I also [2:57] went to electrical engineering but I [2:59] wanted really to to to work in computers [3:01] but the program was just not available. [3:03] Was it the same for you? [3:04] >> Yeah, it was. And I actually think the [3:06] Netherlands was not really a space where [3:08] computer science at least at the time [3:10] was was very popular. Um and I you know [3:13] I like to be hands-on and so that's why [3:15] I went with electrical engineering right [3:16] I get to build circuit boards and and do [3:18] that and then you know after that in [3:21] 1990 I decided to come to the US um and [3:25] you know worked actually right in [3:27] Silicon Valley I came to Santa Clara and [3:29] my first job was at McAfee Associates. [3:31] Um, [3:31] >> wow. [3:32] >> Uh, we were on the side of Lawrence [3:34] Expressway in a very small building, you [3:35] know, probably 20 employees with with [3:38] John McAfee. Um, and, uh, that was [3:41] really how I got started. Um, you know, [3:43] antivirus software, that's mostly of [3:44] what we did. [3:45] >> Um, from there, um, I then, you know, [3:49] worked at some other smaller companies, [3:51] database consulting firms, uh, etc. And [3:54] then I ended up at Netscape. Um and so [3:57] uh and of course [3:58] >> and that's around 95 [4:00] >> yeah 95 96 um [snorts] and uh at [4:03] Netscape there was the browser site that [4:05] most people know. I actually worked on [4:07] the server side um and so I did [4:09] technical support um for you know [4:12] enterprise server which was the the [4:14] Netscape web server, proxy server, LDAP [4:17] server, SSL certificate server etc. um [4:20] and really exposed me to a lot of what [4:22] is now the foundation of you know the [4:24] internet right secure web server [4:26] communication uh all of that [4:29] >> and then I I believe at that time you're [4:30] dealing with like large account from [4:33] like a support perspective and then [4:36] >> do you remember like some like a lot of [4:38] people in the audience who kind of have [4:40] the similar type of role where they have [4:42] to deal with large account you remember [4:44] some learning from that time [4:46] >> yeah I mean you know I remember being on [4:48] call Right. I think you know all about [4:50] this. Um uh and you know supporting [4:54] customers like Wells Fargo, right? That [4:56] were using our [4:57] >> uh secure certificate server, right? To [5:00] be able to do banking and transactions [5:02] securely. Um things not working out and [5:05] so things going down, things not being [5:07] stable, right? Um and then you know that [5:09] was part of my role, right? To help them [5:11] out and make sure that the site was back [5:12] up and and doing that. Um, and I think [5:15] as a product guy, that really, you know, [5:18] a exposed me to a lot of things. I lived [5:20] inside of Unix terminals a lot. I I [5:22] dealt with these admin interfaces. I [5:25] understood what upside um really meant. [5:27] And I think, you know, dealing with [5:29] somebody angry on the other side of the [5:31] phone [5:32] >> um really exposed me to, you know, what [5:33] it takes to to build strong servers and [5:36] and and helping customers with with [5:38] their problems. [5:39] >> Do you remember a little bit the energy [5:41] of the era? because I kind of like I [5:43] vaguely remember it like like I back [5:45] then was working at Nortell [5:48] >> was like a new grad and then tried to [5:50] help on like adopting some of these [5:53] technology and the energy was high. It [5:55] it was great actually. And what to me [5:57] was amazing is the the kinds of people [5:59] in Netscape were able to pull in, right? [6:00] I mean, original founders of Apache [6:03] server, right? The people that wrote [6:05] proxy protocols, right, from uh [6:07] Switzerland, right? The the people that [6:09] really build the foundation of the [6:11] internet all working in the same place. [6:14] And then there was this fun little [6:15] battle back and forth between Netscape [6:17] and Microsoft, right? where we drop a [6:19] little net misilla dragon on you know [6:22] the Microsoft campus and they in turn [6:23] dropped the big E for you know the the [6:26] internet explorer on ours and uh that [6:28] was a really great vibe and and so that [6:30] was really exciting. Yeah, [6:32] >> great. Let's talk about career [6:34] progression. [6:34] >> Y [6:35] >> at some point you do the startup you do [6:38] Netscape and then there's a point where [6:40] you end up at Yahoo. How did that kind [6:42] of like transition worked out? I when I [6:45] left Netscape I actually joined a [6:46] company called Inkto and Inkto was a OEM [6:49] search provider. Uh we you know powered [6:52] a variety of companies uh with our [6:54] search technology and Yahoo acquired in [6:57] me. Um Intim did two things actually [6:59] search and CDNs. Y [7:01] >> um and I worked on the search side and [7:03] that ultimately is what Yahoo ended up [7:05] buying. Um, Yahoo was at the time [7:08] running on Google search and essentially [7:10] the acquisition was to bring in me into [7:14] Yahoo um and be on par and eventually [7:17] switch over um and you know we dubbed [7:20] this collective technology at one point [7:22] YST or Yahoo search technology. [7:24] >> Yep. Yeah. Yeah. I'm sure you're aware [7:26] of I remember [7:27] >> and uh so I was you know the PM lead to [7:30] help with the transition. This took an [7:32] army right certainly not me alone. This [7:34] is many many people to switch over but I [7:37] work closely with the search relevance [7:39] team uh editorial staff um and actually [7:42] for me actually first exposure to [7:44] machine learning [snorts] [7:45] >> right search algorithms training sets [7:48] right golden sets etc so uh really [7:51] interesting and now when I think about [7:52] evals and I think about you know what it [7:54] takes to train models it's very similar [7:57] >> it's very similar the same I would call [7:59] it like job infrastructure is bigger [8:01] with AI these days but kind of like the [8:04] same thing all over. [8:06] >> Yeah, it is. And and so, you know, I [8:07] think we had Yahoo had an amazing [8:09] editorial staff and they were the [8:11] gatekeepers at the end of the day. You [8:13] know, they did sideby-side comparison [8:15] to, you know, different models that we [8:17] had, different different algorithms, how [8:19] we compared against, you know, the [8:20] incumbent provider. Um, and they held [8:24] the bar. You know, if it wasn't good [8:25] enough, then it wouldn't go out. And [8:26] eventually, we succeeded or were better [8:29] as good as. And that was the moment we [8:31] switched over. Um and you know long [8:34] story short that became YCEO search [8:36] technology. [8:37] >> Yeah. Yeah. Oh that's great. And then [8:39] you also like you know part of that [8:41] overall career transition. You [8:43] transitioned from tech support to [8:45] product. [8:46] >> Yeah. I I I think product management is [8:48] a unique career actually in that it [8:49] there's no linear path to become a PM. [8:51] In fact many universities don't even [8:53] teach product management. Some are [8:55] starting to and I'm actually very [8:56] excited about that. Uh so yeah I [8:58] switched uh from tech support to product [9:00] and the way that actually happened is uh [9:03] you know there was a client that I work [9:05] with Microsoft um that wanted had a high [9:08] bar for spelling um and search and so I [9:11] started working with the the relevance [9:13] team with the engineering team and [9:15] realized that oh now I actually get to [9:16] shape you know the criteria definition [9:18] of what uh what is good and how you go [9:21] about that and ended up essentially [9:23] managing the delivery of that eventually [9:26] um and doing so and that is essentially [9:27] my entry into uh product and so that's [9:29] how I became a search PM um and you know [9:32] that carried me throughout uh and uh [9:35] yeah so the rest is kind of history that [9:38] that's where I started my product career [9:39] and you know sometimes you go from [9:41] engineering sometimes you go come from [9:43] the design side [9:44] >> yes yes it is very interesting because [9:47] like I had something similar I I started [9:49] more as let's call it like a coding [9:52] assistant for [laughter] [9:53] uh for researcher I started my career in [9:56] speech recognition And over time I [9:59] gravitated more in how do we put these [10:01] things in production and how do we [10:03] maintain them and like all the code that [10:06] goes around and yeah back then also it [10:09] was something similar where oh you're [10:11] not being taught you kind of have to [10:13] learn on the job and it's something that [10:15] you specialize over time. [10:17] >> Yeah. So tell me more about like so so [10:19] you at Yahoo and at some point you [10:21] decide to leave and then you have like [10:24] another I would call it like your second [10:25] start of the era. [10:26] >> That's right. That's right. Um and this [10:28] is where we actually met um when both of [10:32] us were at Zobi. [10:33] >> Yeah. [10:33] >> Uh can you tell us a bit about your [10:35] transition in this era? [10:36] >> Yeah. So uh I I left Yahoo um and joined [10:41] a a company uh called Live Ops. They did [10:44] remote workforce, you know, call [10:46] centers. And they were developing [10:48] something called live work um mechanical [10:50] tw equivalent, you know, where remote [10:52] people working from home uh would do [10:54] things remotely and you know, make edits [10:56] and and things like that. Um [10:59] >> uh and so that's what they did. [11:00] Copyright review, image analysis, etc. [11:03] from live ops or live work, the [11:05] mechanical platform we were building. Um [11:07] I then left and joined Zabnney. Um and [11:09] Zabni's inbox backwards. you and I [11:12] worked there together and uh we were [11:14] building essentially a people graph on [11:16] top of your inbox. And if you think [11:18] about the gold mine that is your inbox, [11:20] right? People, contact information, [11:22] documents, files, history, orders, etc. [11:25] Um uh that actually is uh what we were [11:28] focusing on. And then from there, um I [11:31] then left and uh joined a company called [11:34] CartSpring where we're essentially [11:35] building card linked offers, coupons and [11:38] ads on top of your credit card. to use [11:40] your card and you get an offer, you [11:41] know, in a pizza store, for example. Um, [11:44] and at that point, um, I got a call from [11:46] the CEO of Zabnney, Jeff Bonford, to um, [11:50] to ask me if you, you know, if I wanted [11:52] to run Yahoo Mail as head of product for [11:54] Yahoo Mail and so that's how I actually [11:56] came full circle. You know, Yahoo is the [11:58] name for it. They call them boomerangs. [12:00] >> Yeah, boomerang like a lot of places are [12:02] Yahoo. So, yep. You know, I I still do [12:05] remember the first day we met. Like I [12:07] think I I I I joined Zobni uh in order [12:11] to help kind of like scale and stabilize [12:13] what used to be called a backend or [12:15] server team because at that point in [12:17] time the team was making a big [12:19] transition from like being inside [12:21] Outlook to being a mobile app to be able [12:24] to support the inside of Gmail and all [12:27] of that. And I I still remember join [12:30] joining a little bit the chaos in in SF [12:33] around that and then [12:35] >> seeing that you were like managing that [12:37] area and building the weekly sprint and [12:40] that type of stuff and do uh [12:42] >> yeah that's kind of going from DLS to [12:45] server side that was actually the real [12:46] big transition. Um so yeah that's good [12:49] and you know uh I can't believe it's [12:51] been basically 16 years. [12:54] Yes. Yes. Now you're back at Yao and now [12:58] with more responsibility, [13:01] >> right? [13:02] >> And with more like you know more [13:04] decision, more stuff that you have to [13:07] do, a larger team and some level of [13:10] momentum. So tell us a bit more about [13:12] that transition. [13:14] >> Yeah, I mean that was obviously a much [13:16] larger scale. Um you know even at the [13:18] very startups I worked at you know we [13:20] had fewer customers and the scale was [13:22] much smaller. um you know Yahoo mail had [13:24] 225 million active users um and you know [13:28] that that's an order of magnitude more [13:30] um when I joined at the time as head of [13:32] product um a lot of that was also uh [13:35] during a time of transformation you know [13:37] had stability challenges um uh outages [13:41] you name it and so uh interesting time [13:43] to join when things were not great but [13:45] also an opportunity to kind of transform [13:46] all of that um and so product is really [13:49] kind of thinking through what should [13:51] mail become how do we do that and [13:53] actually how do we weave in our old zing [13:54] technology right to make you know [13:56] contact address uh books better the [13:59] people graph those kind of things right [14:01] >> talking of outage I remember this big [14:04] outage like when we bought part of Yahoo [14:08] mail [14:09] >> uh where you know a portion of users [14:11] lost their data uh because of some [14:13] something we did not detect properly [14:16] um and that spun off what we call both [14:19] of us call the project the car Yes. [14:22] >> Can you tell us what it was and what it [14:25] brought? [14:25] >> This is interesting, right? Um so, uh [14:28] yes, we actually there were a few [14:30] servers that went down um and not just [14:33] for a small period of time. Um people's [14:35] entire inboxes were not available for a [14:37] period of time at that uh moment. Um and [14:40] that showed that you know we had ignored [14:42] um stability, right? We uh you know [14:45] capacity planning issues and things like [14:47] that. Um, and so, uh, you know, I was [14:50] the head of product, but really under [14:51] Jeff Bonford, who was a GM at the time, [14:54] we basically decided to stop everything [14:56] and started project the car. And for [14:58] those that don't know, the car is a [14:59] rally. And so, this is a rally. Um, [15:01] everything stopped. Um, and I think it's [15:03] an indicator of aligning product and [15:06] engineering priorities at the same time. [15:09] And so, this is for once where you [15:11] everybody works off a common set of [15:12] priorities. And we then allocated teams, [15:15] scrum teams to work on reliability, [15:17] customer care problems, you know, [15:19] stability issues, right? Growth issues, [15:21] front-end issues, but we actually did [15:23] not end up doing new development. It was [15:25] all about stability. Yeah. [15:26] >> Um, and, you know, this was a [15:28] multi-month effort where we essentially [15:30] decided to stop everything we do to get [15:32] everything become stable again. Um, and [15:34] it really did change everything around [15:36] Yahoo Mail because from there on out, [15:38] you know, we were able to kind of grow [15:40] and stop. And if you continue to have [15:41] these issues um it actually makes it [15:43] really challenging to evolve a product [15:45] right to build new product on top of [15:46] that. [15:47] >> And what was interesting is like we [15:49] attacked a lot of like you know there [15:51] was partial migration from older system [15:54] to newer system that [15:55] >> it gave us the opportunity to complete [15:58] them and then to continue and then so it [16:02] put us in a way better space to actually [16:04] like move forward move the product [16:06] forward after the fact and [16:08] >> absolutely right. Yeah, [16:09] >> I I do remember like you know it was [16:11] intense like I think we have to report [16:13] like I believe like every week and it [16:15] was after work we had to report like [16:17] status on all our work stream and [16:20] >> uh yeah so it was intense but it was [16:22] worth it [16:22] >> and every workstream you know we had [16:24] code names right the ninja team has was [16:26] you know delivered something else right [16:27] and so uh to give people an identity [16:30] they even had logos per team right all [16:32] the readouts and the progress we made um [16:36] you know there there's a little bit of a [16:37] creation of a crisis and I Everybody [16:39] rallied, but we came out for the better. [16:41] And and if you think about it, it was [16:42] only a couple of months, right? But when [16:44] you're in the thick of it, [16:45] >> it's really seems like why are we doing [16:48] this? This is this is a lot of [16:49] commitment. Um and I think, you know, [16:51] like I said, it transformed Yahoo from [16:53] from where we were, right? [16:54] >> Coming back to product management, it's [16:56] a bit in this era where you probably had [16:59] to make the most diffic difficult [17:02] decision of your career. [17:04] >> Yes. Can you walk us through the [17:06] scenario and just give us a bit the [17:09] story and background? [17:10] >> Yeah, I you know I was both head of [17:12] product Yahoo mail. I became the GM of [17:13] mail and communication products and then [17:15] chief product officer at Yahoo. Yeah. [17:17] And there you know we had a lot of [17:19] products um under our purview um and [17:22] under our our our skies and what we were [17:24] doing. And so um one of the hardest [17:27] decisions I had to make is end of life [17:29] products. End of living products that [17:30] had users on it, right? And it started [17:32] with um you know killing essentially you [17:35] know AOL Instant Messenger AIM one of [17:38] the most commonly used messaging apps on [17:40] the platform at one point in time. Yep. [17:42] >> Not then. Yeah. [17:43] >> Yahoo messenger. Um uh same for Yahoo [17:46] Answers. I actually worked with the [17:48] Yahoo Answers team. I first did Yahoo [17:50] worked on a product called Answeredia [17:52] which is Q&A Answers and reads [17:54] Wikipedia. And then you know one of the [17:56] hardest ones was actually shutting down [17:58] Yahoo groups. Um, and I bring this up [18:00] because I think it's really important in [18:02] this day and time to say no to things, [18:05] right? Decide what not to do. And it [18:08] wasn't necessarily that these products [18:09] failed. The tradeoff of continue to [18:12] operate them. The cost of running these [18:14] products um was the challenge versus [18:17] what was mostly important, which is [18:19] focus, right? And so ultimately the team [18:21] had to focus on the right priorities, [18:23] the right business needs, the right [18:24] product strategy. Um and so shutting [18:27] down something like Yahoo groups which [18:28] had 115 million users 10 million groups [18:32] was not easy. Um but that decision you [18:34] you I had to make and that's something [18:36] you do as a product manager product [18:38] leader and you know it's not an [18:40] independent decision right you have a [18:42] lot of conversation with engineering [18:43] teams you you pick up on signals from [18:45] different people you see the challenges [18:47] right you talk to different groups that [18:49] interact with it and eventually you [18:51] conclude that this is the right call. So [18:52] from the outside it seems like it's one [18:54] call. It's many different things that [18:56] ultimately allow you to realize that [18:58] this is the right thing to do, right? Um [19:01] to stop something so you can continue on [19:03] to something else and focus. Yeah. [19:04] Right. And and that's why [19:05] >> and if you layer that with the world [19:08] we're living today like if I look at [19:10] like you know from my experience like [19:13] you know at meta lots of the coding [19:16] seems to be not free but it like it [19:18] happens a lot faster than it was before [19:21] >> and there seems to be a tremendous [19:23] amount of code that gets shipped [19:25] >> and now the question becomes like you [19:28] know what should we focus on what's [19:30] going to move the needle for users and [19:32] for our products like So give me a [19:35] little bit more around like from a [19:37] product management about like how do we [19:39] manage this influx of energy [19:42] >> and things so that we can still get [19:46] quality systems or quality products out. [19:48] I I mean the the the stopping or saying [19:51] no to things is is part of that, right? [19:53] And so uh you know I wrote a guide or an [19:56] article recently where I said um you [19:58] know building got cheap judgment became [20:00] scarce and judgment is what product is [20:02] all about product management right and [20:04] so I judgment as a leader to decide to [20:06] stop something like Yahoo groups and I [20:08] think there has to be judgment that you [20:10] implement when you decide to be able to [20:12] build anything because building does get [20:14] cheap building does get fast and so when [20:16] you can build a 100 prototypes a week [20:19] >> um I think the harder thing becomes what [20:22] do you decide not to build, right? And [20:24] so um and so I believe strongly that you [20:27] know you need to before you even do [20:29] anything in the product discovery cycle [20:30] up front um uh you know start thinking [20:35] about what does success look like right [20:37] what makes for a great product and then [20:39] two is define a kill rate actually where [20:42] I say of the 10 things that we look at [20:45] you know which are the two that survive [20:47] and why would they survive and then from [20:49] that you also develop an eval criteria [20:51] and so that says this is the this is the [20:54] reason why they make it through because [20:55] if you build every single prototype and [20:58] push it in production which you know all [21:00] about and then it becomes a production [21:02] solution or a production system you now [21:04] you have to keep it up right there's [21:06] usage there's load time there's things [21:07] like that and so um I believe you know [21:10] you have to sit down and actually [21:12] develop a guide that does that upfront [21:15] you know a good friend of mine Felix [21:18] Kwinhard and I wrote this guy together [21:21] to kind of say okay this is a product [21:22] discover recovery piece where you have [21:24] to define what does success look like, [21:27] what is the kill rate and then what's [21:28] the eval set and you do that all up [21:30] front through conversations. It's also [21:32] where you actually build judgment. I [21:34] actually believe most organizations [21:36] don't write down judgment in documents. [21:38] It lives in people's heads, right? Why [21:40] something good? [21:41] >> Yeah. It doesn't have memory. And I [21:42] think, you know, for PMs that are up and [21:44] cominging or junior PMs, [21:46] >> that is part of it as well. I think they [21:48] learn to build judgment in this kind of [21:50] the upfront discovery process. And so I [21:52] think it's a great training ground um to [21:53] do that as well. [21:54] >> How do you feel like young product [21:56] manager how how do they build this [21:59] judgment? Is it just by using the ham [22:03] more their product more but there's also [22:05] a question of understanding what the [22:07] user wants usage pattern. So how do how [22:09] do somebody build that judgment? [22:11] >> Yeah I I I I think uh of course you're [22:14] using software products right tools [22:17] systems um I think develops that first [22:19] and foremost. Um I think you can learn [22:21] through iteration very quickly. You know [22:23] it used to take probably you and I a lot [22:26] longer to get to know something to build [22:28] something uh build a piece of software [22:30] right to iterate on that. Um I think [22:32] these days um that you can do much [22:34] faster right because you can build [22:36] faster you can prototype faster you can [22:37] learn quicker. So I actually think you [22:39] can accelerate building judgments by [22:41] building a lot of these prototypes and [22:43] realize oh this doesn't work that [22:44] doesn't work oh this one seemed to work [22:46] good right and doing that. Um and so I [22:49] think that's one piece and then there's [22:51] a tremendous amount of information [22:54] available you know obviously on the [22:56] internet on YouTube podcast like this [22:58] right so listen to others that have [23:00] experience right pick up on that and so [23:03] I think they can very quickly build and [23:05] learn and I think if if you know things [23:09] are documented upfront right before you [23:11] even start building because you can [23:12] build pretty much anything nowadays um [23:15] that is a opportunity for young PMs to [23:17] should participate, right? And learn how [23:19] people decide, learn how to decide not [23:21] to build something, learn how they [23:23] decide why something is good. Um, and I [23:26] think in the world of product, right, [23:27] there's there's kind of the three W's I [23:29] think about, right? Who is your [23:31] customer? What problem are you solving? [23:33] And why is your approach the right one [23:36] or, you know, why are you why are you [23:38] the right person to build it or why is [23:40] your solution the right answer to that? [23:42] Um, and so just think about that, right? [23:44] It's, you know, who's your customer and [23:45] and what's the problem you're solving. [23:47] Very basic, but think about that. [23:49] >> Yeah. [23:49] >> Going back to career progression. [23:51] >> Yeah. [23:52] >> So, you were adding products at some [23:53] point in in Yahoo and Yahoo coms and [23:56] mail. [23:57] >> But at some point, you became GM also. [24:01] So, mean meaning a lot more [24:02] responsibility overseeing both product [24:05] team, engineering team and all the [24:07] support function teams and so on. [24:10] >> What was that transition like? a unique [24:13] transition where obviously I went from [24:15] mail uh to broader responsibilities you [24:18] know with coms etc but what was unique [24:20] about that role is as you said it wasn't [24:23] just product it was product it was [24:25] devops it was engineering it was design [24:28] uh etc and what's unique about that is I [24:31] technically owned the full P&L $3 half [24:33] billion dollar P&L um um 750 people [24:37] total in organization [24:39] >> but everything under one person and so [24:41] for me as a product person that [24:43] basically said product and engineering [24:44] priorities are one set of priorities and [24:47] I think it's very similar to what we did [24:48] with the car right where everybody's [24:50] executing off the same set of priorities [24:52] um and I think that is somewhat rare [24:54] typically there's a negotiation that [24:56] happens between a product team and an [24:58] engineering team and everybody has their [25:00] own priorities and there's some back and [25:01] forth around that um and I'm actually [25:03] starting to see a trend now where that [25:05] is kind of reversing um I'm hearing [25:08] CPTTO roles chief product and technology [25:10] officers where these becoming one. Um, [25:13] and I actually think that is probably a [25:15] direction you're moving into. Um, I've [25:17] heard folks looking for engineering [25:19] leaders with product chops. And so, you [25:21] know, that is I think uh where these [25:23] roles are starting to collapse [25:25] essentially because of are we building [25:27] the right thing? Right? Is product [25:28] judgment part of decision- making. Are [25:30] we all rowing in the same direction? Is [25:32] product strategy aligned? Are our [25:34] outcomes aligned? Are our success [25:35] criteria correct? Right? Um and I don't [25:38] I think it's much more where these roles [25:40] start collapsing mostly at a leadership [25:41] level. I believe [25:43] >> if you had to give advice to young [25:46] startup founders and then let's let's go [25:49] about how to structure the these teams [25:52] to avoid that clash between product and [25:55] engineering function. How would you [25:57] structure a small org? [25:59] >> I think it it used to be that you know [26:02] these functions you know worked very [26:04] independently and worked with each [26:05] other. I I think it should be much more [26:07] fluid than that. Um and so now I think [26:09] for a small startup a I think there are [26:12] things you can do that you wouldn't be [26:13] able to do before. Um you know I've [26:15] talked to some founders where you know [26:17] they're basically not hiring their CFO [26:19] just yet. They're not hiring their head [26:21] of legal just yet because they're able [26:23] to get a good enough responses out of AI [26:26] tools to be able to do that. And so they [26:27] delay hiring and they actually spend it [26:29] on guess what? Tokens, right? They spend [26:31] it on infrastructure um and those kind [26:33] of things, right? Um and uh I think that [26:36] is the right way to go about it. What I [26:37] think is important is with these tools [26:39] that are available um you have to change [26:42] the ways of working right. It's no [26:43] longer just a product manager hands it [26:45] off to a designer that gets then handed [26:47] off to engineering. These these teams [26:48] need to work together. [26:50] >> I think a designer can actually provide [26:52] you style guide or information look and [26:54] feel [26:55] >> so that the prototype that's output by [26:57] say a product manager looks familiar [26:59] right. I think the engineering teams can [27:02] share context of infrastructure system [27:05] limitations you know what kind of [27:06] database we use right the kinds of [27:08] things that um you wouldn't uh usually [27:11] have share that context up front so by [27:13] the time they do decide to pursue [27:16] something a feature or a product it can [27:18] actually run on the infrastructure that [27:19] already exists versus an engineer saying [27:21] well that's great we don't have this or [27:23] no we can't do that because of our [27:24] database limitations yeah things like [27:26] that [27:27] >> coming back to the structure of the team [27:29] would to um advise the younger founder [27:32] like hey I want you want your [27:33] engineering function to report directly [27:35] to you or like go to a single head. [27:38] >> Yeah I I think a small team is is [27:40] obviously more fluid. Um I I do believe [27:43] that I I think uh you know if you have a [27:46] a product a head of product that is [27:48] technical [27:50] um some of that can actually collapse [27:51] into that person because then I think [27:53] you're you're avoiding this kind of [27:55] conversation around you know these are [27:57] engineering priorities these are product [27:59] priorities and certainly when you're [28:00] small you want to make sure everybody's [28:01] focus [28:02] >> everybody goes into the same direction [28:04] yeah [28:04] >> there's a point then you manage 3.5 [28:08] billion P&L and so on and you say Hey, [28:11] I'm going to leave all that behind and [28:13] I'm going to move forward and start my [28:15] own thing. [28:16] >> Yes. [28:17] >> Tell us a little bit about this. [28:18] >> Yeah, I so I I left Yahoo in 2021 and [28:22] then um started my own advisory firm. I [28:24] basically take on interim and fractional [28:26] product roles. I'm a team of one powered [28:29] by a bunch of agents. Um and so uh I uh [28:33] you know went from you know running a [28:35] large organization to being an [28:37] individual contributor. Um, I help [28:38] companies when there's a gap or there's [28:40] a product need, you know, somebody [28:42] leaves, uh, there's a restructuring and [28:44] I come in to help them from the outside [28:46] in, essentially get the product team on [28:49] track or get a product out. Um, and [28:51] then, you know, I go on to my next [28:52] client. Um, and so essentially [28:53] independence right now. [28:55] >> So, you mentioned a team of one. That's [28:57] super interesting because like, you [28:58] know, [28:59] >> there's a bit of utopia, but there's [29:01] also like, you know, I I do love control [29:03] and team of one is great for that. [29:06] Um, tell us about your setup like like [29:08] like how do you manage like you know [29:10] I've read some article that you [29:12] published on LinkedIn talking about your [29:13] chief of staff and tell us a bit about [29:16] the orchestration how do you manage [29:18] agents what's kind of like your setup [29:20] >> I started small right so what a couple [29:23] years ago started with just lovable I [29:26] then started using bold and then [29:28] obviously as claude came about um wanted [29:31] to play with that um I actually started [29:33] an open claw so my first idea was uh I'm [29:36] going to build a chief of staff because [29:37] I was at my best with a great chief of [29:39] staff. Um and you know she kept me [29:42] honest. She kept me on track, make sure [29:44] all my tracks were going. Um I even [29:46] wanted to call my system after her name [29:48] and and decided yeah that's a little [29:50] creepy so I won't do that. Interestingly [29:52] named itself. So I'll talk about that as [29:54] well. When I started with Open Claw [29:56] there were a couple of things I ran [29:57] into. You know one is I was [30:00] uncomfortable with the security posture. [30:02] Um, and so just safety, security, the [30:05] trust, you know, those kind of things. [30:07] And then secondly, um, I had some agents [30:10] go rogue. And so overnight I spent a lot [30:12] of money that I didn't want to spend. [30:14] And so at the time it just wasn't ready. [30:16] >> U, but I learned from that. And so then [30:18] I switched to cloud code. And so I now [30:20] run three instances of cloud. Um, I have [30:23] one on my desktop. I have cloud running [30:25] on my laptop as I need to. And then I [30:27] have an always on Yubuntu server that [30:29] sits in Finland at a German ISP called [30:32] HNER. Um and uh they run instances [30:36] there. The reason why the server is [30:38] always on is because it runs research. [30:40] It manages my to-do bot. Um I have an [30:43] MCP interface that I've built. [30:45] >> So all my instances talk to that MCP [30:47] interface. Um and you know thinking [30:49] about inboxes, I built something I call [30:52] syncbox. And so my instances drop each [30:55] other's tasks to each other to perform [30:57] different things because I have [30:59] different access. And so when I first [31:01] started with cloud, I basic [31:02] >> so you manage access by kind of like [31:05] location of desktop versus your VM [31:07] running remotely. So so you have some [31:10] level of isolation. [31:11] >> It's some level of isolation. And a good [31:12] example of that is my desktop is the [31:14] only one that has token to my personal [31:16] email address. Okay. [31:17] >> Um my server does not um from a security [31:20] posture perspective. And so when I first [31:22] started, I actually said, "I do not [31:24] trust you. [31:25] >> You have to earn your right to trust and [31:27] you will I will slowly give you access [31:29] and slowly give you permissions." And so [31:31] I developed a trust and safety policy [31:33] within my own system [31:35] >> so that I could be careful about what is [31:37] shared and what's not. And so um [31:39] including things like PII filtering, [31:41] token masking, [31:43] >> I did not want these to go to the LLM [31:45] providers. And so that's how I managed [31:47] that. And so they still remain locally [31:49] today. And even to this day, nothing has [31:52] deletion rights. If I think about my [31:53] email inbox, right? Um, for example, you [31:56] know, it has draft rights, it has [31:58] archive rights, it can read everything, [32:01] no deletion, right? And so, uh, I manage [32:04] permissions through scope depending on [32:06] the task that I want them to do. Um, um, [32:08] and so there's always on server is [32:10] always available to me. You know, that [32:11] runs a telegram bot that does [32:13] transcription, it does things like that. [32:14] And often is where I do my builds. So I [32:17] drop my spec in there. And also there uh [32:20] I've defined what I call team in a box [32:23] because I am a team of one but I use [32:24] agents as a team. Um and they then help [32:27] me go build solutions and software that [32:31] that I'm interested in. Right. From apps [32:33] to different services. Yeah. [32:34] >> And that helps you in your current like [32:37] job as like like fractional CPO type of [32:40] thing. [32:41] >> It it does. Uh some of them are are are [32:43] side projects, things that I'm [32:44] personally interested in um to build. uh [32:47] others are truly performing tasks and so [32:49] an example of that is uh doing research [32:52] doing analysis um uh comparison of you [32:56] know trends in in the space um uh it has [32:59] access to certain documents right so it [33:01] has access to my Google drive accounts [33:02] and so that's where it creates surveys [33:05] that we survey results um it it it you [33:08] know emails participants and and things [33:10] like that um and you know you and I were [33:13] talking earlier I I can fully remotely [33:16] on my phone, you know, manage, you know, [33:18] a client if I wanted to do that. Um, [33:21] because a lot of these tasks are [33:22] happening in the background. [33:23] >> You talk about a bit indirectly about [33:25] token management. This becoming like a, [33:28] you know, a hot topic these days because [33:30] a lot of people have been surprised by [33:32] the overall cost of these things token. [33:35] Um, so you kind of manage it by scope [33:38] >> and you I must do you have limits in [33:41] some area or [33:42] >> because look I I'm a team of one and so [33:45] I try to manage my cost in token usage [33:47] and so I'm you know on on the anthropic [33:50] max plan it's 100 bucks a month I try [33:52] not to blow through it there they're I [33:54] learned that the hard way you know by [33:55] Tuesday everything was done and so now I [33:57] got to spend money to be able to use [33:59] more and so what I started doing is my [34:01] my default today is is opus um you know [34:04] it's a smarter and so my chief of [34:06] staff's brain is Opus as a model. Um, [34:09] but then when I need to do file [34:10] operation or simple things, I have a [34:12] conversation. It actually knows it. It [34:14] tells me I'm about to assign a sub [34:15] agent. I suggest we use Haiku. Okay, [34:18] >> cheaper model, way cheaper to use, [34:20] right? And it does that then, right? If [34:22] I need something slightly more smarter, [34:25] um, uh, it it it introduces the sonnet [34:28] model, right? And there I even set [34:30] effort, right? You can set, you know, [34:32] low, medium, high effort, right? And so [34:34] we adjust that. So every time I talk to, [34:36] you know, we dish out a task to my [34:38] agent, right? I I talk to my chief of [34:40] staff, which has all my contacts, all my [34:42] knowledge stored locally in markdown [34:46] files in a hierarchy, uh synced across [34:49] my three instances. Every time something [34:51] is delegated, um then uh we talk about [34:55] what model to use. Y and this is how I [34:57] actually manage my workday. And what [34:58] then actually happens is usually by [35:00] Friday I'm like, "Oh, I got 30% tokens [35:02] left, which is pretty good." And then [35:04] I've turned Friday into my build day [35:06] because my tokens reset Saturday [35:08] morning. And so I have 24 hours to blow [35:11] the 30% of my tokens and I go build. [35:13] >> Oh, you go and maximize. [35:15] >> Yes, why not? I'm not going to waste my [35:18] So you you kind of find a point like my [35:21] reset is Saturday morning. [35:22] >> So Friday morning, I'm like, "Ah, I got [35:24] 30% left. It was a slow week or [35:26] whatever. I didn't use it all." So I [35:28] blow it in something fun, right? I, you [35:29] know, I end up building an app or, you [35:31] know, whatever that may be. Um, and so [35:33] that's my hack day. My build day is [35:35] Friday. Oh, that's awesome. [35:36] >> Whatever that it could be automation, [35:37] could be infrastructure. [35:39] >> That's how I use it, right? [35:40] >> So that that's super awesome. You've [35:42] gone to many many transition and the [35:45] more recent one. Could you share some [35:47] kind of like leadership wisdom that you [35:50] learn along the way about like hey [35:54] what's the best way as a tech person [35:58] engineer product manager that like to [36:00] handle this transition like you know [36:02] people talk about adaptability but like [36:04] I'm like [36:05] >> I I mean I think it is some of that [36:07] right adaptability um you know I've seen [36:09] a lot of inflection points in my career [36:11] right having started with you know the [36:13] internet essentially going to surge [36:16] going to media, the shift to mobile, [36:18] then the shift to AI. This is another [36:21] inflection point. I actually think this [36:22] is probably an inflection point like [36:24] like no other. Um, and I know many [36:27] product people are having FOMO, right? [36:29] Because they're working their day jobs, [36:30] but they're very curious about it. And [36:31] so I had the luxury to spend my time on [36:34] learning these tools. And I decided to [36:36] do that because I was obviously very [36:37] curious and realized that I can only do [36:39] my job better. It's not to actually get [36:42] my work myself out of a job. I am [36:44] actually having superpowers, right? they [36:45] can do things more than they could do [36:47] before. Um, and so I' I'd say, you know, [36:50] be curious, right? Start thinking about [36:52] how you might use these tools in your [36:54] your your workflow. Um, and I think [36:57] actually the hardest part is an [36:58] individual being better and working [37:00] better is one thing. The team [37:02] collectively working better is a very [37:04] very different story. [37:06] >> And so I think that's where I think [37:07] leaders should start thinking about how [37:09] do we do this, right? If you can build [37:10] anything you want to in any prototype, [37:12] that doesn't mean you should ship [37:13] everything either, right? [37:15] >> Let us move to some lightning question. [37:18] They're they're fast, but they're [37:20] lighter, [37:20] >> right? [37:21] >> So, if I was to ask you today, like you [37:24] know, even in the latest in last week or [37:26] so, what's your currently favorite AI [37:29] tool? [37:30] >> Um, of course, I use Cloud a lot, right? [37:33] The one I actually ended up using quite [37:35] a bit recently that I'm quite impressed [37:36] with just as far as output workflows is [37:39] Manis. Um, and so, you know, there [37:42] there's something about how that's been [37:44] wired and how I work with it that I [37:46] really enjoyed. [37:47] >> Um, actually know it was part of meta [37:49] and recently spun back out. I had to [37:50] reset my account and all this stuff. [37:52] But, um, a pretty neat tool and I think [37:54] they've done some things really the [37:55] right way. [37:56] >> And in this case, you like the output [37:58] and like the fact that it was almost [38:00] like it was structured in a way or [38:02] >> Yeah. well structured. I think the the [38:04] handholding of of getting something [38:05] done, uh the ability to, you know, pull [38:09] in external, you know, SDKs and things [38:10] to get something to be performed. I [38:13] thought the image generation was quite [38:14] good. It actually used GPT2, I believe, [38:17] for for some of that. Uh but it was [38:19] seamless and so um it didn't feel like [38:21] there was a lot of back and forth and so [38:23] I I really enjoyed using that tool [38:25] myself recently and I I was rather [38:26] impressed with it. [38:27] >> Any AI tool in your nonwork life? [38:29] actually recently had a problem with my [38:31] bike and so you know my derailer broke I [38:34] had to buy a new derailer and so you [38:36] know I actually um used Gemini took a [38:40] picture of my derailer found the right [38:41] model it's an older bike almost 10 years [38:43] old now ordered it got it back I [38:46] installed the derailer and then um you [38:48] had to make some adjustments and so same [38:50] thing took a picture and do that now on [38:53] the flip side the one place I don't need [38:56] AI is when I'm on exercising when I'm on [38:58] my [38:59] I don't need it in my ear. And the [39:01] reason why is because that is alone time [39:03] for me where I get to think about [39:05] everything. I'd say that's where I build [39:07] my judgment. [snorts] [39:08] >> It's where my creativity kicks in. And [39:10] so I don't need AI there necessarily. Uh [39:13] because it's me and my brain and you [39:14] know that that's what I need. [39:16] >> Quickly, if you had to pick today, let's [39:19] say you talk about biking, mountain [39:20] biking. Um if you had to pick like ebike [39:23] or non ebike as a new bike, [39:25] >> interesting one. Um I have both [39:27] actually. So, uh, and, uh, so I do both. [39:30] Actually, I'll alternate. So, uh, one [39:32] day I'll use my regular mountain bike [39:33] and, um, grind up the mountain. Uh, I [39:36] have a place in Truckucky, so that's [39:37] where I do my mountain biking. Um, and [39:40] it is hard, right? You're at altitude, [39:42] you're climbing a lot of mountains, um, [39:44] and doing that. And then the next day I [39:45] feel like doing a ride and then I go [39:47] back to e- mountain biking and, you [39:49] know, so I kind of alternate. I have [39:51] some friends that are hardcore, no e [39:54] mountain bike whatsoever, and I think [39:55] they're entirely missing out [39:57] >> because you can go further, longer, [40:00] harder, and so for exploration, it's [40:02] absolutely fantastic. So, I I recommend [40:04] both. That's what I do. [40:06] >> Great. Final quick question. Um, if you [40:11] again I'll go again in the in the [40:12] mountain bike or like do you do any [40:14] analysis at the at the end after of your [40:17] rides and like you know people go like [40:18] perform like some amazing analysis of [40:21] their ride? [40:22] >> Uh yeah I do I I use Strava actually uh [40:25] quite a bit. So actually Straa has [40:26] recently integrated some uh some [40:28] intelligence where it tells you how you [40:31] did some things it noticed. Um I think [40:33] it's done they've done it very well. um [40:35] you know, I'm one of those guys that [40:37] once I get back to the house, I sit [40:39] down, look at my stats, how was my heart [40:41] rate, did I climb, did I have my output [40:43] correctly, uh those kind of things. And [40:45] so, uh yeah, I do spend a lot of time [40:47] with that. And I really like the Strava [40:49] AI because it says this was your longest [40:51] ride in a while. You really, you know, [40:52] we're in this zone and that zone. Um I [40:55] think it it it works pretty well. So, I [40:57] do like it after my ride. [40:59] >> Awesome. [41:00] >> So, great. Well, thank you. Thank you [41:02] for your generosity. That's awesome. [41:04] You're welcome. Thank you. [41:05] >> Thanks for listening and I hope you [41:07] enjoyed the conversation as much as I [41:09] did. If you're interested in connecting [41:12] with more infrastructure in product [41:14] engineer in person, join us at our next [41:16] at scale event, product at scale [music] [41:18] in Menllo Park on October 28th. We'll [41:21] hear about the latest AI innovation from [41:24] expert at Meta, Nvidia, Microsoft, [41:27] Intel, Pindrop, and more. [music] Go to [41:29] the Atscale website to register, and I [41:32] hope to see you there.