Meta PM Morrow Warns Early GenAI Flaws Trigger 60% Customer Churn

The Stochastic Product Manager: A New Playbook for the GenAI Era With Meta — Ai4

Ai4

Generative AI features fail when conversational friction disrupts established consumer habits, as low-quality responses within the first four interactions increase user churn by 60%.

AI-assisted summary of The Stochastic Product Manager: A New Playbook for the GenAI Era With Meta — original source. Check the original for full context.

Source published:

Detailed notes

## Background Published on YouTube by the Ai4 channel on August 28, 2025, this talk features Chris Morrow, a Product Manager at Meta and former PM on Amazon Rufus. The session provides a durable, first-principles framework for product managers to navigate the stochastic, unpredictable nature of generative AI development.

## TL;DR Chris Morrow contrasts traditional deterministic software management with product managing large language models, explaining that roadmaps must pivot from static feature checklists to task coverage and statistical win rates. He emphasizes that customer convenience is the primary driver of adoption, demonstrating how Amazon Rufus minimized friction across 3,400-pixel detail pages rather than forcing intrusive conversational flows. To sustain competitive advantage, Morrow outlines a practical GenAI flywheel: define simple binary quality SOPs, ship an MVP focused on high-convenience tasks, and leverage real customer telemetry to fuel rapid iteration velocity.

## Atmosphere & style The presentation carries a pragmatic, self-deprecating, and humorous tone that cuts cleanly through standard generative AI hype. Morrow engages the audience with grounded analogies—comparing erratic model behavior to a moody teenager and critiquing conversational friction during simple shopping tasks. It feels like an honest, battle-tested debrief from a practitioner sharing hard-won lessons from scaling AI products to over 100 million users.

## Key takeaways - [01:49](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=109s) Traditional software product management is deterministic and linear, whereas LLMs are inherently stochastic, shifting product focus from feature checklists to task coverage and statistical quality win rates. - [03:50](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=230s) Customer convenience—defined by saving time, reducing complexity, minimizing steps, and building trust—is the primary driver of GenAI adoption. - [03:50](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=230s) Forcing unnecessary conversational friction or high-latency LLM interactions into established user flows destroys convenience and drives product failure. - [05:25](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=325s) On Amazon product detail pages, Rufus tackled the 3,400-pixel scrolling problem by surfacing single-tap question chips above the fold rather than requiring open-ended chat prompts. - [05:25](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=325s) Early interaction quality is critical for trust: users who experienced poor or unhelpful GenAI responses within their first four interactions were 60% more likely to churn. - [09:25](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=565s) To establish GenAI task coverage, product teams should identify high-friction points in the customer journey that directly align with core LLM strengths, such as multi-source data synthesis. - [09:25](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=565s) MVP roadmap prioritization should be filtered by three core criteria: lowest technical complexity, fastest time to market, and maximum added customer convenience. - [10:15](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=615s) Quality evaluation standard operating procedures (SOPs) should be limited to 3–5 binary yes/no dimensions (e.g., factuality, relevance, specificity) that an uninformed reviewer can understand in 5 to 10 minutes. - [10:15](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=615s) Before scaling to external annotation pipelines, PMs should directly evaluate initial model outputs themselves alongside a small internal team to establish baseline quality for a Minimum Lovable Product. - [13:07](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=787s) Standard product engagement metrics like clicks, conversion rates, and repeat usage serve as dependable proxies for whether an AI feature delivers real utility. - [14:41](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=881s) Deploying an MVP unlocks high-volume customer telemetry, which feeds a continuous data flywheel for prompt engineering, RAG tuning, and model fine-tuning. - [14:41](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=881s) Iteration velocity serves as the ultimate competitive moat in GenAI, accelerating product refinement and model alignment far beyond the pace of traditional software development.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=4s) Introduction and the Role of a Stochastic Product Manager

Chris Morrow opens his talk with self-deprecating humor about the title of the session, immediately admitting, "I regret immediately naming it that because it's actually kind of hard to say." He engages the crowd with audience polls, joking that everyone is a product person whether they admit it or not, and asking who simply showed up to figure out what "stochastic" actually means. Morrow establishes his background—showing a stylized "Studio Ghibli" avatar of himself—noting his product management work at Alexa, serving as Product Manager #3 on Amazon Rufus, moving to Meta, and helping launch DeepLearning.AI's *AI for Everyone* course. His goal is to share concrete, hard-won learnings from building at scale so others don't have to learn through painful trial and error.

He sets expectations for the session: comparing the management of traditional deterministic software versus LLMs, followed by two tactical plays—finding customer value and constructing a generative AI flywheel. Reacting to the room's quiet initial energy, Morrow jokes that audience responsiveness is "trending red" against his third success metric, but promises practical takeaways.

- **Speaker Background**: Product Manager at Meta, former PM at Alexa, PM #3 on Amazon Rufus, and contributor to DeepLearning.AI's *AI for Everyone*. - **Session Goals**: Contrast traditional software PMing with LLM PMing, dive deep into the value and flywheel mechanics, and deliver an actionable playbook.

---

[01:49](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=109s) Managing Software vs. Product Managing LLMs

Traditional software product management is fundamentally deterministic and predictable: systems have defined requirements, explicit acceptance criteria, and discrete feature backlogs. Morrow emphasizes that his perspective is not based on "using ChatGPT to manage my life for 5 days and posting it on Medium," but on shipping products to over 100 million users globally. LLMs are fundamentally stochastic—meaning probabilistic. Given a set of inputs, one cannot deterministically predict the exact output every single time, turning production monitoring into a "living nightmare" when stakeholders inevitably send screenshots of edge-case hallucinations that fall within a 5% error tolerance.

Instead of writing static PRDs with discrete feature checklists, LLM product managers must focus on **coverage** (defining what specific tasks the model is responsible for) and **quality** (establishing how to evaluate whether it performs those tasks well). Progress in LLM development is inherently fluid and non-linear. Morrow humorously compares working with an LLM to his 12-year-old son: "one day it shows up awesome and the next day it just like can't get out of bed." Consequently, milestone tracking shifts from counting completed Jira tickets to tracking statistical win rates (e.g., reaching a 55% win rate against an evaluation benchmark to greenlight a launch).

| Traditional Software PM | Stochastic (LLM) PM | |:--- |:--- | | **System Behavior** | Predictable / Deterministic | Probabilistic / Stochastic | | **Product Focus** | Discrete features, acceptance criteria, fixed PRDs | Task coverage, quality rubrics, SOPs | | **Progress Trajectory** | Linear development against a feature backlog | Fluid, statistical improvements (win rates vs. benchmarks) | | **Failure Modes** | Code bugs, logic errors | Hallucinations, tolerance variance, unpredictable outputs |

---

[03:50](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=230s) Playbook 1: Convenience is King

Morrow introduces his first core playbook principle: convenience is the ultimate driver of customer adoption. While convenience is a time-tested concept, for end users it boils down to concrete, tangible benefits: fewer steps, saved time, reduced complexity, and enhanced trust. However, teams building in generative AI often succumb to the trap of ignoring the detractors of convenience. Propelled by the urge to "invent the future" and make every single user action a runtime inference call, product teams frequently add friction rather than removing it.

Customers already possess deeply ingrained habits and mental models for mature products. Forcing an unprompted, conversational AI interaction into a simple purchase flow ruins the experience. As Morrow quips, "if you throw a random LLM at me while I'm trying to buy toilet paper, that's less convenient. Now I'm pissed." When product teams hand-wave away the friction, latency, and extra cognitive load introduced by AI, the product invariably fails.

```mermaid flowchart TD accTitle: The Convenience Equation for GenAI Features

subgraph Drivers["Convenience Drivers (Adoption)"] D1["Fewer steps to complete task"] D2["Saves user time"] D3["Reduces operational complexity"] D4["Increases system trust"] end

subgraph Detractors["Convenience Detractors (Churn)"] X1["Unnecessary conversational friction"] X2["High inference latency"] X3["Disrupting established habits"] X4["Unverifiable hallucinations"] end

Drivers --> Outcome["Product Market Fit & Retention"] Detractors -.-> Fail["60% Higher Churn"] ```

---

[05:25](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=325s) Applying Convenience to Amazon Rufus: The 3,400-Pixel Problem

Morrow illustrates convenience through his experience as PM #3 on Amazon Rufus in 2023, tasked with finding 0-to-1 product-market fit for an AI shopping assistant embedded within a mature, highly optimized e-commerce interface. The challenge was figuring out how to deliver net-new convenience to shoppers who already knew how to search and check out.

An Amazon product detail page (PDP) is roughly 3,400 pixels long and requires an average of nine full scrolls on mobile to reach the bottom. While core elements like price, shipping date, and top reviews sit near the top, granular product specifications and detailed descriptions are buried three to four scrolls down in modules that shift positions across categories. Rather than forcing shoppers into an open-ended chat interface, the Rufus team mapped the customer journey, extracted high-frequency questions, and surfaced them as single-tap query chips directly above the fold. Tapping a question pulled up a lightweight bottom sheet containing the answer.

Crucially, the bottom sheet could be easily dismissed, allowing users to scroll down and cross-reference the AI's answer against the raw detail page. Morrow emphasizes that trust verification is paramount: users do not blindly trust model output for buying decisions without checking. The team discovered that if the AI delivered a poor or unhelpful experience within the first four interactions, customers were **60% more likely to churn** and abandon the feature entirely.

- **Detail Page Length**: 3,400 pixels (~9 mobile scrolls to the bottom). - **Target Information**: Buried product details/descriptions typically located 3–4 scrolls down. - **UI Solution**: Proactive single-tap question chips above the fold with a dismissible bottom sheet answer. - **Trust & Churn Metric**: Poor quality within the first 4 interactions resulted in a 60% higher user churn rate.

---

[08:02](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=482s) Playbook 2: The GenAI Flywheel and Initial Coverage

Morrow transitions to the second playbook: establishing a Generative AI Flywheel. Quoting the Andreessen Horowitz principle that AI systems compound in quality as data accumulates, he outlines the core operational loop for application-layer PMs: foundational capabilities, coverage, quality, customer engagement, and relevance.

```mermaid flowchart LR accTitle: The Generative AI Flywheel subgraph Flywheel["The Application-Layer GenAI Flywheel"] A["Foundational Capabilities"] --> B["Define Coverage"] B --> C["Establish Quality SOPs"] C --> D["Launch MVP"] D --> E["Drive Customer Engagement"] E --> F["Improve Relevance & Win Rates"] F --> B end ```

When leadership asks the ubiquitous question, *"What are we doing in AI?"*, Morrow advises avoiding overcomplication: 1. **Define Coverage**: Start simply by taking a piece of paper and brainstorming a discrete list of specific tasks customers are trying to accomplish and why they are using the product. 2. **Establish Quality SOPs**: Create explicit standard operating procedures to measure whether the LLM answers those tasks accurately. 3. **Launch MVP**: Ship the targeted task scope to gather real-world usage. 4. **Leverage Engagement for Relevance**: Use real customer queries and engagement telemetry to continuously refine prompts, retrieval, and model alignment.

[09:25](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=565s) Identifying LLM-Fit Customer Tasks and Prioritizing the MVP

Building an effective product strategy starts with examining why the business exists and understanding the tactical steps in the customer journey. Product managers must ask where in that journey they can genuinely save customers time, and then evaluate which of those high-friction tasks align with core LLM capabilities. Large language models excel at synthesizing information and pulling disparate data sources together into a coherent response. If a task would save time but an LLM cannot reliably perform it, pursuing it will just lead to spinning wheels.

To prioritize what to build first, teams should avoid overcomplicating their roadmap. The initial list of potential features should be filtered by three primary criteria: the least technical complexity, the fastest path to market, and the highest added convenience for the customer. Starting with this intersection provides sufficient coverage to test product-market fit without unnecessary overhead.

- Focus on tasks where LLM strengths (such as summarization and multi-source synthesis) directly reduce customer effort. - Filter the feature backlog using a straightforward prioritization heuristic: lowest complexity, fastest time to market, and maximum user convenience.

---

[10:15](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=615s) Building a Quality SOP and Evaluation Framework

When defining response quality, teams do not need exhaustive academic frameworks to get started. A practical approach is to head to a whiteboard and identify three to four core dimensions—capping it at five. These dimensions represent the non-negotiable bars a response must meet before launch, such as factuality, grammatical correctness, proper language, relevance to the query, and specificity.

```mermaid flowchart TD accTitle: GenAI Evaluation Framework accDescription: Workflow showing how quality dimensions turn into an SOP and feed evaluation methods.

subgraph Definition ["1. Define Quality Standard"] A["Brainstorm 3-4 Dimensions<br>(Factuality, Relevance, Specificity)"] --> B["Draft Binary Yes/No Questions<br>('Play Jeopardy')"] B --> C["Ambush Uninformed Colleague<br>(Test & gather feedback in 5-10 min)"] C --> D["Finalize Quality SOP"] end

subgraph Execution ["2. Evaluation Strategy"] D --> E["Internal Review<br>(Evaluate 20 examples yourself & with 5 peers)"] E --> F{"Choose Evaluation Layer"} F --> G["Foundational: Automated Metrics"] F --> H["Application: LLM-as-a-Judge & Human Eval"] end ```

For each dimension, create a straightforward binary yes/no question—essentially playing Jeopardy to ask, "Is this factual or not?" Once drafted, validate these criteria by ambushing an internal colleague who has zero context on the project. If they ask questions like "What does factual mean?" or "Compared to what?", use their confusion to refine the wording. Once the criteria can be explained and applied by an uninformed person in five to ten minutes, a functional Standard Operating Procedure (SOP) is complete, as professional annotators are simply external reviewers without context.

With the SOP established, engineering and product teams can choose between automated metrics, LLM-as-a-judge, and human evaluation. While automated metrics are common for foundational models, application-layer products rely heavily on LLM judges and human evaluators. Before spending resources on massive external labeling operations, product managers should evaluate their own models, run twenty examples against the SOP to adjust the prompt or guidelines, and leverage a small group of roughly five informed colleagues to establish the baseline for a Minimum Lovable Product (MLP).

- Limit quality dimensions to 3–4 critical attributes (e.g., factuality, language correctness, relevance, specificity). - Frame quality criteria as simple yes/no questions and refine them against feedback from people with zero project context. - Keep the evaluation loop lean for the MLP stage by inspecting the first batches of outputs personally alongside a small internal team.

---

[13:07](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=787s) Validating Value with Simple Proxy Metrics

Once a Minimum Viable Product is deployed, measuring whether it creates genuine utility does not require complex metric engineering. Clear proxy metrics such as clicks, engagement, conversion, and retention provide definitive signals of customer value.

Unless a company happens to have a user base that visits an application simply to kill an afternoon, customers are there to complete a specific task and move on with their day. Because users will not waste time on friction-heavy tools, sustained engagement and repeat usage directly reflect whether the AI feature added tangible convenience to their workflow.

- Simple product metrics—clicks, engagement, conversion rates, and retention—act as dependable proxies for AI utility. - Repeat usage confirms that the generative AI feature is solving real problems rather than serving as a novel, one-off distraction.

---

[14:41](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=881s) The GenAI Data Flywheel and Iteration Velocity

Once a product reaches tens of thousands of active users, the system unlocks its most critical asset: high-volume, labeled customer interaction data. Analyzing this telemetry reveals whether users are engaging with the product as originally hypothesized or surfacing unexpected query types and edge cases (such as anomalous queries in complex retail domains like the books category). These real-world logs provide a direct, empirical roadmap for the next development cycle, indicating where prompt tuning, retrieval-augmented generation (RAG) updates, or model fine-tuning are needed.

```mermaid flowchart LR accTitle: The GenAI Data Flywheel accDescription: Circular flywheel diagram showing how usage generates data to improve models and accelerate iteration.

A["Launch MVP / MLP"] --> B["Customer Interactions<br>& Real Usage"] B --> C["Labeled User Data<br>& Query Insights"] C --> D["Prompt Tuning &<br>Model Fine-Tuning"] D --> E["Higher Quality &<br>Better Customer Fit"] E --> B ```

This dynamic creates a self-reinforcing flywheel. Quoting Sam Altman's advice to startup founders, product managers must "make it one of your top goals to build the fastest iterating company the world has ever seen." Iteration velocity forms the ultimate competitive moat in AI.

Historical model releases highlight this momentum: while the jump from GPT-3 to GPT-3.5 took roughly two and a half years, the transition from GPT-3.5 to GPT-4 happened far more rapidly. The influx of user interaction data provided the necessary training, preference, and fine-tuning pipelines to accelerate deployment speed—a trend equally visible across Claude and Llama ecosystems.

| Product / Model Era | Transition Dynamic | Role of Customer Data | |:--- |:--- |:--- | | **GPT-3 to GPT-3.5** | Took ~2.5 years to reach broad conversational utility. | Limited user feedback loop prior to public chat interfaces. | | **GPT-3.5 to GPT-4** | Shipped in rapid succession following wide release. | Scaled interaction data directly fueled alignment, fine-tuning, and model evaluations. | | **Modern Ecosystem (Claude, Llama)** | Accelerated update cadences across foundational and fine-tuned models. | Continuous telemetry and evaluation data allow faster model and application iterations. |

In summary, winning playbooks in the generative AI era center on three enduring principles: 1. **Convenience is King:** Solve tangible customer problems and save them time. 2. **The Flywheel Effect:** Convert real customer interaction telemetry into proprietary training and tuning data to establish a durable moat. 3. **Iteration Velocity:** Build systems and operational cadences that out-iterate the competition.

## Notable quotes > [00:04](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=4s) I regret immediately naming it that because it's actually kind of hard to say. — Chris Morrow

> [01:49](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=109s) using ChatGPT to manage my life for 5 days and posting it on Medium — Chris Morrow

> [01:49](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=109s) one day it shows up awesome and the next day it just like can't get out of bed. — Chris Morrow

> [03:50](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=230s) if you throw a random LLM at me while I'm trying to buy toilet paper, that's less convenient. Now I'm pissed. — Chris Morrow

> [08:02](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=482s) What are we doing in AI? — Chris Morrow

> [10:15](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=615s) Is this factual or not? — Chris Morrow

> [10:15](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=615s) What does factual mean? — Chris Morrow

> [10:15](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=615s) Compared to what? — Chris Morrow

> [14:41](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=881s) make it one of your top goals to build the fastest iterating company the world has ever seen. — Sam Altman

## Mentioned Chris Morrow, Meta, Alexa, Amazon Rufus, DeepLearning.AI, AI for Everyone, ChatGPT, Andreessen Horowitz, Sam Altman, GPT-3, GPT-3.5, GPT-4, Claude, Llama, Ai4, Studio Ghibli

## Video description Chris Morrow, Product Manager, Meta

Abstracts

How do you build a roadmap for a product that is inherently unpredictable? The established playbooks for software development were built for predictable systems, but Large Language Models are stochastic, breaking the traditional model. In this talk, I will share a practical framework for product management in the generative AI era, built from direct experience shipping and scaling Amazon Rufus. I will explain three key concepts: why customer convenience is the ultimate driver for adoption, how to spin up a "GenAI Flywheel" of quality and relevance, and how to leverage iteration velocity as a decisive competitive advantage.

Join this session to get a durable, first-principles framework to navigate the ambiguity of building with large language models.

[Source](https://www.youtube.com/watch?v=ch4a8oCY-Kc)

中文简报

Meta产品经理Morrow警告:早期GenAI缺陷会导致60%的用户流失 当对话摩擦打乱既有的消费者习惯时,生成式AI功能便会失败;在前四次交互中出现低质量回复,会使用户流失率增加60%。 Chris Morrow将传统的确定性软件管理与大语言模型的产品管理进行了对比,指出产品路线图必须从静态的功能清单转向任务覆盖率和统计胜率。他强调,客户便利性是推动采用的主要动力,并阐述了Amazon Rufus如何在长达3400像素的详情页中最大程度减少摩擦,而不是强推侵入式的对话交互流程。为维持竞争优势,Morrow概述了一个实用的GenAI飞轮:定义简单的二元质量SOP,发布专注于高便利性任务的MVP,并利用真实的客户遥测数据推动快速迭代。 传统软件产品管理是确定性和线性的,而LLM本质上具有随机性,这使产品重心从功能清单转向了任务覆盖率和统计质量胜率。 (1:49) 客户便利性——具体表现为节省时间、降低复杂性、减少步骤和建立信任——是推动GenAI采用的主要驱动力。 (3:50) 在既有用户流程中强行加入不必要的对话摩擦或高延迟LLM交互会破坏便利性,并导致产品失败。 (3:50) 在Amazon商品详情页上,Rufus通过在首屏展示单击式问题标签解决了3400像素的滚动浏览问题,而不是要求用户输入开放式的聊天提示词。 (5:25) 早期交互质量对建立信任至关重要:在前四次交互中遇到较差或无用GenAI回复的用户,其流失概率要高出60%。 (5:25)

Reading summary

Chris Morrow, Product Manager at Meta and former PM on Amazon Rufus, argues that managing generative AI products requires moving from deterministic feature checklists to managing probabilistic task coverage and evaluation rubrics, with user convenience and rapid iteration cycles serving as the primary competitive moat. Deterministic Software vs. Stochastic Models (1:49) Traditional software engineering is deterministic and predictable, defined by explicit acceptance criteria, static PRDs, and progress tracked along discrete feature backlogs. In contrast, large language models are inherently probabilistic, meaning identical inputs can yield variable outputs. Morrow observes that this variance makes production monitoring difficult, as edge-case hallucinations can trigger stakeholder concern even when falling within acceptable 5% error tolerances. Because development trajectories are fluid rather than linear, Morrow contends that product managers must pivot their focus toward task coverage—defining the exact jobs a model handles—and quality rubrics. Project milestones shift from completing Jira tickets to driving statistical win rates against established evaluation benchmarks before greenlighting a launch. Prioritizing Convenience over Conversational Friction (3:50) Morrow identifies convenience as the core driver of adoption, defined as fewer steps, saved time, reduced operational complexity, and verifiable trust. However, generative AI teams frequently introduce detractors such as latency, cognitive load, and forced conversational workflows that interrupt existing user habits. Morrow warns that forcing unprompted AI interactions into simple tasks damages the user experience rather than improving it. To illustrate this, Morrow points to Amazon's 3,400-pixel product detail page, which requires roughly nine mobile scrolls to reach the bottom and buries key specifications three to four scrolls down. Rather than introducing an open chat window, the Rufus team placed single-tap question chips above the fold that opened a dismissible bottom sheet, allowing shoppers to easily verify answers against page details. Morrow reports that delivering a poor experience within the first four interactions increased user churn by 60%, making low-friction verification essential. Practical Quality SOPs and Evaluation (10:15) To establish quality without overcomplicated academic frameworks, Morrow recommends defining three to four non-negotiable dimensions, such as factuality, relevance, specificity, and grammatical correctness. These criteria should be formatted as binary yes/no questions and tested on colleagues with zero project context. Once an uninformed reviewer can accurately apply the criteria within five to ten minutes, the standard operating procedure (SOP) is sufficiently robust for operational use. For early-stage products, Morrow advises against immediately deploying expensive external labeling pipelines. Instead, product managers should personally evaluate the first batches of model outputs against the SOP, testing roughly 20 examples alongside a small internal group of about five peers to set a baseline Minimum Lovable Product before incorporating automated metrics or LLM-as-a-judge pipelines. The Data Flywheel and Iteration Cadence (14:41) Once an application launches, Morrow notes that product utility can be validated using straightforward proxy metrics such as clicks, engagement, conversion, and retention. Sustained repeat usage confirms that an AI feature provides practical value rather than acting as a temporary novelty. Reaching tens of thousands of active users generates interaction telemetry that uncovers real-world edge cases and unpredicted query types. These logs provide direct evidence for prompt tuning, retrieval updates, and model fine-tuning. Morrow cites the dramatic compression in release cadences between early GPT models and contemporary releases to emphasize that converting live user interactions into rapid model improvements creates a self-reinforcing flywheel, making iteration velocity a team's primary competitive advantage. Morrow concludes that winning with generative AI depends not on forcing models into every interface, but on solving real customer friction points, validating quality with clear binary standards, and using real-world interaction data to maximize iteration speed.

精炼阅读摘要

Meta 产品经理 Chris Morrow 指出,生成式 AI 时代的产品管理已从确定性软件交付转向概率性的“随机产品管理”。团队制胜的核心在于放弃过度复杂的对话交互,聚焦于切实节省用户时间的“便利性”,并通过低成本质量标准作业程序与数据飞轮拉升系统迭代速度。 从确定性软件转向概率性模型管理 (1:49) 传统软件产品管理建立在确定性与高可预测性的逻辑之上,产品经理通过明确的需求文档、功能清单与验收标准推进线性交付。然而,大型语言模型在本质上属于概率性系统,输入相同指令无法保证每次输出完全一致,甚至存在不可控的幻觉风险与容错率波动。Morrow 指出,这种随机特征彻底改变了开发与监控方式,使得研发进程呈现出流动的、非线性的特点。 面对这种不确定性,产品经理的职责重心必须从拆解孤立功能,转向界定“任务覆盖范围”与建立“质量评测标准”。在项目里程碑管理上,团队无法再单纯依靠已完成的工单数量衡量进度,而是需要依赖统计学维度的基准胜率。例如,只有当模型在特定的评估基准上达到 55% 的胜率时,才具备批准上线推进的决策依据。 便利性驱动:消除 AI 交互中的无谓摩擦 (3:50) 便利性是推动用户采纳 AI 产品的首要驱动力,其核心在于减少交互步骤、节约操作时间、降低认知复杂度并建立系统信任。然而在生成式 AI 研发中,部分团队因急于实现全流程智能化,往往在用户成熟的操作路径上强加非必要的对话式交互。Morrow 直言,如果在原本清晰的购物流程中强行植入未经提示的对话交互,不仅无法带来便利,反而会因为额外延迟和认知负荷引发用户不满。 在 2023 年打造 Amazon Rufus 购物助手的实践中,面对长达 3,400 像素、在移动端平均需滑动 9 次才能见底的商品详情页,团队并未强迫用户使用开放式聊天界面。相反,他们提炼出深层高频问题,在首屏上方提供单次点击的问题卡片,并以可轻松关闭的底部抽屉呈现答案,方便用户下拉对照原文进行事实核查。Morrow 强调,用户决策极度依赖对 AI 输出的交叉验证;数据显示,若用户在最初 4 次交互中遭遇劣质体验,其整体流失率将暴增 60%。 精简质量标准与低成本评测验证闭环 (10:15) 定义大模型输出质量无需套用繁琐的学术框架。Morrow 建议产品团队在白板上列出 3 至 4 个核心维度(上限不超过 5 个),例如事实性、语法规范、语言得体性、查询相关性和细节具体性,将其作为产品发布前不可逾越的红线。每个维度需进一步提炼为非黑即白的二元“是/否”问题,确保评判标准足够具象化且易于执行。 为验证标准作业程序(SOP)的有效性,产品经理可以在团队内部寻找无项目上下文的同事进行 5 至 10 分钟的压力测试,根据其疑问逆向修正表述,直至无背景人员也能准确执行打分。在最小可爱产品(MLP)阶段,产品经理应亲自评审前 20 个输出样本以调整提示词,并借助约 5 名内部同事建立评估基线,随后再按需结合大模型评测(LLM-as-a-judge)与人工标注,避免过早投入高昂的外部标注成本。 驱动数据飞轮与以迭代速度构建竞争壁垒 (14:41) 当 AI 应用达到数万活跃用户规模后,真正的护城河便源自真实用户交互所产生的遥测数据。这些数据能够揭示用户在真实业务场景中突发的边缘用例与异常提问(例如复杂商品类目中的特殊检索需求),从而为后续的提示词调优、检索增强生成(RAG)更新或模型微调提供经验驱动的路线图,驱动系统能力与相关性持续上升。 Morrow 援引 Sam Altman 关于“打造全球迭代最快公司”的建议,强调在 AI 领域,极速的迭代节奏是构建持久竞争壁垒的核心。从 GPT-3 到 GPT-3.5 耗时长达约两年半,而 GPT-3.5 到 GPT-4 的演进则因海量真实交互数据的反哺而大幅加快;当前无论是 Claude 还是 Llama 生态均体现了这一趋势。团队通过点击量、转化率和留存率等实用代理指标验证价值,并借助数据飞轮将用户反馈转化为专有调优资产,才能在长期竞争中胜出。 Morrow 总结认为,生成式 AI 产品取胜的关键在于坚守“便利性至上”、转化真实数据以运转飞轮,以及建立超越同行的极速迭代机制。不过,演讲侧重于电商与应用层产品的实践经验,未深入探讨在高度敏感、受严苛隐私法规约束或冷启动数据匮乏的业务场景中,该飞轮机制可能面临的数据合规与冷启动限制。

Detailed notes — zh

## Background 本内容由 YouTube 频道 Ai4 于 2025 年 8 月 28 日发布。视频为 Meta 产品经理 Chris Morrow 的主题演讲,简介阐述了大语言模型本质上的随机性如何打破传统软件开发范式,并结合其主导亚马逊导购助手 Amazon Rufus 规模化落地的经验,分享生成式 AI 时代的产品管理方法论。 ## TL;DR 演讲深入剖析了传统确定性软件管理与大模型概率性/随机性系统之间的根本差异,指出 GenAI PM 的核心重心需从离散功能规格转向任务覆盖面与质量评估。Chris 提出了驱动产品成功的实战三步法:首先坚持“便利为王”,在核心旅程中以最低交互摩擦为用户极致省时;其次通过制定轻量化质量 SOP、小步快跑上线 MVP 并引入真实标注数据,启动越用越聪明的“GenAI 数据飞轮”;最后以极高的迭代速度为核心壁垒,持续拉开与竞争对手的差距。 ## Atmosphere & style 整场演讲氛围幽默接地气、务实且充满一线实战的硬核干货。Chris 以自嘲和打趣开场,彻底摒弃了空洞的行业套话与营销辞令,用生动的比喻(如“管教叛逆期孩子”和“玩 Jeopardy 问答游戏”)拆解复杂概念。听众在轻松会心的互动中,能深切感受到一位历经 0 到 1 亿用户大模型产品实战磨砺的 PM 所传递的真诚、洞见与敏锐的产品直觉。 ## Key takeaways - [01:49](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=109s) 传统软件系统是确定性的,而大语言模型具有随机性和概率性,无法保证相同输入总产生相同输出,迫使产品管理从离散功能规格转向界定覆盖面与模型质量。 - [01:49](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=109s) 生成式 AI 项目无法再依靠离散功能的完成清单打钩来衡量进度,而是转向依赖统计学指标(如针对 Benchmark 的胜率 Win Rate)来决定上线门槛。 - [03:50](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=230s) 驱动 GenAI 产品采纳的核心在于“便利为王”,体现在减少操作步骤、节省时间、降低理解复杂度并建立用户信任;若 AI 介入反而增加了操作摩擦,产品必然失败。 - [03:50](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=230s) 亚马逊 Rufus 团队将原本深藏在 3400 像素、需滑动数屏后的商品参数与高频问答,直接重构为首屏推荐胶囊,通过抽屉式交互让用户即时查验并核对原页面细节。 - [03:50](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=230s) 用户对大模型产品的容错率极低:在最初的 4 次交互尝试中,一旦回答出现严重失误或不及预期,用户永久流失的概率将激增 60%。 - [09:25](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=565s) 寻找冷启动切入点应遵循“交集原则”与极简公式:只做“为用户省时”与“LLM 原生擅长能力(如摘要、多源整合)”重叠的任务,优先选择复杂度最低、上线最快且便利增量最大的场景。 - [10:15](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=615s) 质量评估标准(SOP)无需复杂理论,可通过白板梳理 3-5 个核心维度(如真实性、相关性、具体性),并转化为二元判定(Yes/No)题型以便非专业人员快速复现。 - [10:15](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=615s) 在投入重度外部标注流水线前,应用层团队应以 LLM-as-a-judge 与内部人工评估为主,PM 和核心成员亲自跑通少量样例即可低成本验证最简可行/最讨喜产品(MLP)。 - [13:07](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=787s) 捕捉 GenAI 产品的价值验证应避开虚浮的间接指标,直接以点击量、交互深度、业务转化率与用户留存率作为衡量便利性的核心代理信号。 - [14:41](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=881s) 上线后沉淀的真实客户交互数据构成了 GenAI 飞轮的核心燃料,直接用于提示词微调与模型定向对齐,形成使用越多模型表现越好的正向闭环护城河。 - [14:41](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=881s) 正如 Sam Altman 所言,迭代速度(Iteration Velocity)是 AI 时代最决定性的竞争壁垒,能够建立最快数据演进闭环的公司才能在激烈的模型与应用竞赛中脱颖而出。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=4s) 认识“随机型产品经理”(Stochastic PM) Chris Morrow 以轻松幽默的方式开场,笑称自己没有任何推销目的,纯粹是带着对生成式 AI 时代产品管理的热情来分享。他调侃自己选的演讲标题“The Stochastic Product Manager”(随机型产品经理)念起来实在拗口,下次一定会取个更好发音的名字。在与台下观众互动时,他半开玩笑地提问:“如果你是做产品的,请举手——这是个陷阱题,因为人人都是做产品的。”接着又问:“有多少人来这里只是为了搞清楚‘随机性’(Stochastic)到底是什么意思?” ```mermaid flowchart TD accTitle: 传统软件 PM 与大模型 PM 的核心差异 subgraph Traditional["传统软件产品管理 (Deterministic)"] T1["确定性与可预测性"] --> T2["离散功能与验收标准 (PRD/AC)"] T2 --> T3["里程碑推进:按功能开发清单打钩"] end subgraph GenAI["大模型产品管理 (Stochastic)"] G1["概率性与不可预测性 (输出波动)"] --> G2["定义覆盖面 (Coverage) 与质量 (Quality)"] G2 --> G3["统计学指标推进:胜率 (Win Rate) 对标基准"] end ``` 针对自身经历,Chris 介绍自己曾供职于 Alexa,并以 3 号产品经理的身份主导推出了亚马逊的专属 AI 导购助手 Amazon Rufus,目前在 Meta 担任产品经理。此外,他还曾参与吴恩达(Andrew Ng)DeepLearning.AI 平台《AI for Everyone》课程的上线工作,一直致力于推动 AI 普及,帮助更多人理解技术并构建面向随机系统的产品方法论。他坦言,本次分享的核心目的是将自己在第一线趟坑换来的经验直接交付给同行,避免大家重蹈覆辙。 ### [01:49](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=109s) 传统软件管理与大模型管理的根本分歧 Chris 直言,自己的认知并非来自“在 ChatGPT 上把生活打理五天然后发一篇 Medium 博客”,而是源自真实将产品从 0 扩展到全球 1 亿用户的实战经验。传统软件开发是确定性的系统,而大语言模型(LLM)从本质上来说是**随机的、概率性的**(Probabilistic)。给入同样的输入,系统并不能保证每次都产生相同的输出。这种特性在生产环境中堪称“噩梦”:随时都会有人截下一张模型反常表现的截图丢到 PM 脸上质问,而 PM 只能无奈解释这其实落在允许的 5% 容错容差区间内。 两者的管理范式存在根本区别: - **从离散功能转向覆盖面与质量**:传统软件 PM 专注于详尽描述功能规格、验收标准(Acceptance Criteria)和 PRD 需求;而 LLM 理论上什么任务都能做,因此大模型 PM 的核心工作转变为界定覆盖面(Coverage,究竟要支持哪些高价值任务)与质量(Quality,如何量化衡量模型完成任务的好坏)。 - **非线性的流动态进展**:大模型的研发迭代体验就像在管教一个 12 岁的青春期孩子——今天精神抖擞发挥超常,明天可能就完全“赖床不起”,性能退化。这种反复对商业和产品来说都极度折磨,因为质量直接关联客户体验。 - **以统计指标而非打钩清单驱动发布**:衡量项目是否接近上线的标准,不再是“还剩 N 个功能未完成,第 3 个里程碑即将达成”,而是基于统计学指标,例如“面对某项基准测试(Benchmark),模型的胜率(Win Rate)达到了 55%,满足上线标准”。 ### [03:50](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=230s) 打法一:便利为王(Convenience is King)与摩擦陷阱 在进入第一个实战策略时,Chris 强调“便利为王”虽然听起来是不言自明的常识,但对用户而言,便利有着极其明确且具体的衡量标准:**减少操作步骤、节省时间、降低理解复杂度、提升对产品的信任度**。 ```mermaid flowchart LR accTitle: 亚马逊商品详情页痛点与 Rufus 交互改造 subgraph PainPoint["痛点:冗长的页面遍历"] A["商品详情页 (PDP) 全长 3400 像素"] --> B["平均需滑动 3 至 4 屏甚至 9 屏"] B --> C["参数与描述模块浮动在深层‘深渊’"] end subgraph RufusSolution["Rufus 方案:折叠屏上方直给答案"] D["提取高频问题置于首屏 (Above the fold)"] --> E["一键呼出底部抽屉 (Bottom Sheet) 呈现回答"] E --> F["易于收起 + 支持与详情页对照验证建立信任"] end ``` 然而,业界在狂热拥抱大模型时,常常盲目叫嚣“用 LLM 发明未来,把所有交互全变成运行时推理调用(Runtime Inference Call)”,却忽视了便利的破坏因素(Detractors of convenience)。如果用户进入一个高度成熟、早已养成操作习惯的应用(例如在亚马逊上买卫生纸),原本两步就能买完,产品团队却冷不丁弹出一个未经打磨的 LLM 对话框拦截路径,用户只会感到被打扰甚至愤怒。如果忽视这些因 AI 介入而增加的用户摩擦,产品必然难逃失败。 - 亚马逊移动端商品详情页(PDP)页面长达 3,400 像素,从顶部到底部需要完整滑动 9 屏。 - 绝大部分用户根本不会滑到页面底部的“地下室”(那里甚至连广告模块都没有),大家只关心核心信息:价格、配送日期、用户评价,以及藏在冗长描述和多变参数规格中的具体细节。 - **首屏一键触达(Above the fold)**:Rufus 团队通过拆解用户购物全旅程,将用户通常需要滑动 3 到 4 屏才能找到的商品细节信息,在首屏直接转化成预设问题建议胶囊。用户点击即可通过底部抽屉(Bottom Sheet)弹出答案,且抽屉极易关闭,方便用户对照原页面核对真伪。 - **容错率极低**:在用户最初的 4 次交互尝试中,一旦模型回答出现严重错误或不及预期,用户流失且永不再使用该功能的概率就会激增 60%。 ### [08:02](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=482s) 打法二:构建生成式 AI 飞轮(GenAI Flywheel) 针对如何寻找产品市场契合度(PMF),Chris 提出了第二个核心策略:启动生成式 AI 飞轮。他引用了 Andreessen Horowitz(a16z)的经典观点——AI 系统具有数据越多越聪明的正向循环潜力。Chris 明确指出,本次讨论的重心落在应用层(Application Layer)的全新产品构建上,而非底层的模型对齐或基础训练集开发。当管理层抛来那句经典的灵魂拷问——“在 AI 浪潮里我们该干点啥?”时,PM 需要有一套标准的落地行动清单。 ```mermaid flowchart TD accTitle: 生成式 AI 应用层飞轮模型 subgraph Flywheel["生成式 AI 落地闭环"] F1["定义初始覆盖面 (Initial Coverage)"] --> F2["制定质量评估标准 (Quality SOP)"] F2 --> F3["发布最小可行产品 (Launch MVP)"] F3 --> F4["收集真实交互 (Customer Engagement)"] F4 --> F5["反哺提升相关性与体验 (Improve Relevance)"] F5 --> F1 end ``` 飞轮启动的具体推进脉络: 1. **定义初始覆盖面(Initial Coverage)**:明确界定 AI 助手首发需要支持的任务边界。在具体执行层面,PM 根本不需要把这件事情神秘化,最实用的方法就是拿出一张纸坐下来,纯粹从第一性原理脑暴:用户的真实意图到底是什么?为什么他们需要这个功能? 2. **制定质量操作规范(Quality SOP)**:建立明确的评分和评估基准,让质量衡量可复现、可追踪。 3. **上线 MVP 产品**:以最轻量级的闭环验证核心便利性价值。 4. **利用客户真实互动提升相关性(Relevance)**:观察用户实际向模型输入了什么,进而持续优化覆盖范围与应答质量,形成越用越好的正向循环。 ### [09:25](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=565s) 寻找 LLM 与客户旅程的交集及快速冷启动 在构思产品时,首先要回到生意的本质:用户为什么要使用你的产品?他们在具体的客户旅程(Customer Journey)中究竟想完成什么任务?在这条战术路径上,你能如何帮他们节省时间?接下来的关键是寻找大语言模型(LLM)擅长的能力交集——比如提炼和总结信息、从分散的多个数据源中提取信息并进行整合输出等。如果某项任务虽然能节省时间,但 LLM 根本不擅长处理,那么团队就是在做无用功、原地打转。 在确定交集后,优先级的排序应遵循极简原则:选择复杂度最低(Least Complexity)、上市速度最快(Fastest to Market)且能为客户带来最大便利(Most Added Convenience)的切入点。不必一开始就追求极其复杂的架构,只要列出一份清单、快速启动,以此来验证产品与市场匹配度(Product-Market Fit, PMF)。 - **核心交集点**:只有当“能为客户节省时间”与“LLM 所擅长的能力(如总结、多源信息整合)”产生交集时,方案才具备落地价值。 - **冷启动优先级公式**:最低复杂度 + 最快上线时间 + 最大化客户便利。 --- ### [10:15](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=615s) 构建质量评估标准(SOP)与评测流程 定义 GenAI 产品的质量并不需要过于复杂的理论。团队只需找一块白板,提炼出 3 到 5 个最关心的质量维度(Dimensions)——即用来判断模型生成结果是否达到发布门槛的标准。这些维度通常包括:真实性/事实性(Factuality)、语法与语言正确性、针对用户提问的相关性(Relevance)以及具体性(Specificity)。针对每个维度,设计简单的“Yes/No”二元判断题(就像玩《危险边缘》(Jeopardy)游戏一样,直接提问“这个回答是否属实?”)。 梳理出这套问题后,下一步是在公司里找一个完全不了解该项目的同事进行“突击测试”。将回答展示给对方并询问其判断,根据对方的困惑(例如“什么叫属实?基于什么标准?”)反复修正维度的定义。因为实际标注人员(Human Annotators)本质上就是缺乏上下文的普通人,只要能在 5 到 10 分钟内向无背景人员解释清楚这套标准,一份耗时约 3 小时的质量标准作业程序(SOP)便构建完成了。 在评估指标落地层面,主要有三种方式:自动化指标(Automated Metrics,多用于模型底模层)、LLM-as-a-judge(大模型作为裁判)以及人工评估(Human Evaluation)。对于应用层团队而言,后两者是核心。在花大价钱搭建大规模外部标注管线之前,产品经理和团队成员应该亲自下场评估至少 20 个样例,通过几名核心人员的小规模闭环,就能极快地将最简可行/最讨喜产品(MLP)推向可用状态。 ```mermaid flowchart TD accTitle: GenAI 质量评估 SOP 制定与迭代流程 subgraph S1["1. 维度与标准制定"] A["白板脑暴 3-4 个核心维度<br/>(真实性、相关性、特定性等)"] --> B["设计 Yes/No 二元判定问题"] end subgraph S2["2. 盲测校验与 SOP 固化"] B --> C["突击测试无背景同事"] C --> D["吸收反馈,确保 5-10 分钟内讲透"] D --> E["形成标准化评估 SOP"] end subgraph S3["3. 内部跑通与上线评估"] E --> F["PM/团队自身试跑 20 个样例"] F --> G["应用层评测组合:<br/>LLM-as-a-judge + 内部人工评估"] end ``` - **核心质量维度参考**:真实性(Factuality)、语法与语言准确性、针对用户需求的相关性(Relevance)、回答的具体性(Specificity)。 - **指标实施层级**:底层基座模型依赖自动化指标;应用层产品主要依赖“大模型作为裁判(LLM-as-a-judge)”与“人工评估(Human Evaluation)”。 --- ### [13:07](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=787s) 定义衡量价值的核心代理指标 当 MVP/MLP 准备就绪并推向市场后,团队需要明确如何捕捉客户获得价值的信号。鉴于产品的核心目标是“提供便利”,衡量指标无需过度复杂化,点击量(Clicks)、参与度(Engagement)以及转化率(Conversion)就是最直接、最有效的代理信号(Proxy Signals)。 用户不会无缘无故在应用或网站中闲逛打发时间,每个人都是带着具体的问题或任务而来,并且希望以最快速度完成。因此,如果用户持续点击、深度交互并留存下来(Retention,反复回访),这就强有力地证明了产品正在为他们创造实用价值。团队无须在复杂的间接指标上耗费过多心力,关注最直接的用户行为即可。 - **核心代理指标**:点击量、交互参与深度、业务转化率、用户留存率。 - **用户行为本质**:用户时间极其宝贵,持续的使用与回访本身就是产品具备便利性与价值的最佳证据。 --- ### [14:41](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=881s) 启动 GenAI 飞轮与迭代速度的竞争壁垒 当产品上线并迎来数万真实用户的交互后,团队就获得了最核心的资产——带标签的真实客户数据(Labeled Customer Data)。产品经理需要立刻深入分析这些数据:用户的实际参与深度如何?他们真实执行的任务与最初的假设是否一致?(在实际场景中往往大相径庭,比如在图书品类中用户提出的各种意料之外的复杂问题)。 这些一手数据直接构成了下一轮迭代的优先级来源。团队可以据此调整 Prompt 提示词工程、进行模型微调(Fine-tuning)以及优化输出对齐,使模型更贴合用户的真实诉求。这就形成了一个正向循环的“GenAI 飞轮”(Flywheel):更多的交互带来更多真实数据,数据驱动模型质量与相关性的提升,更好的体验吸引更多用户使用,从而产生更多数据。 ```mermaid flowchart LR accTitle: GenAI 数据飞轮效应 A["发布极致便利的 MVP"] --> B["用户高频交互与高留存"] B --> C["沉淀真实标注数据与长尾用例"] C --> D["精准 Prompt 调优与模型微调"] D --> E["模型表现与用户意图高度拟合"] E --> B ``` 正如 Sam Altman 在一次面向初创团队的演讲中所强调的:"Make it one of your top goals to build the fastest iterating company the world has ever seen"(把建立世界上迭代速度最快的公司作为你的首要目标)。迭代速度(Iteration Velocity)是 AI 时代最决定性的竞争壁垒。从行业历史来看,OpenAI 从 GPT-3 发展到 GPT-3.5 耗时近两年半,但随后凭借海量真实交互数据作为训练、标注与微调的养料,极快地推出了 GPT-4;Anthropic 的 Claude 以及 Meta 的 Llama 同样展现出了这种飞轮加速轨迹。 演讲最后总结了 GenAI 时代产品经理的三大核心认知: 1. **便利为王(Convenience is King)**:为用户省时、创造极致便利是驱动产品采纳的终极动力。 2. **飞轮效应(Flywheel Effect)**:利用真实数据持续反哺模型质量与相关性,构建企业最坚固的护城河。 3. **迭代速度(Iteration Velocity)**:以最快的数据闭环与演进速度,拉开与所有竞争对手的差距。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=4s) 如果你是做产品的,请举手——这是个陷阱题,因为人人都是做产品的。 — Chris Morrow > [00:04](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=4s) 有多少人来这里只是为了搞清楚‘随机性’(Stochastic)到底是什么意思? — Chris Morrow > [01:49](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=109s) 面对某项基准测试(Benchmark),模型的胜率(Win Rate)达到了 55%,满足上线标准 — Chris Morrow > [03:50](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=230s) 用 LLM 发明未来,把所有交互全变成运行时推理调用(Runtime Inference Call) — Chris Morrow > [03:50](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=230s) 在用户最初的 4 次交互尝试中,一旦模型回答出现严重错误或不及预期,用户流失且永不再使用该功能的概率就会激增 60%。 — Chris Morrow > [08:02](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=482s) 在 AI 浪潮里我们该干点啥? — Chris Morrow > [09:25](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=565s) 只有当“能为客户节省时间”与“LLM 所擅长的能力(如总结、多源信息整合)”产生交集时,方案才具备落地价值。 — Chris Morrow > [09:25](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=565s) 最低复杂度 + 最快上线时间 + 最大化客户便利。 — Chris Morrow > [10:15](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=615s) 这个回答是否属实? — Chris Morrow > [14:41](https://www.youtube.com/watch?v=ch4a8oCY-Kc&t=881s) Make it one of your top goals to build the fastest iterating company the world has ever seen — Sam Altman ## Mentioned Chris Morrow, Meta, Amazon, Amazon Rufus, Alexa, Andrew Ng, DeepLearning.AI, AI for Everyone, ChatGPT, Andreessen Horowitz (a16z), Sam Altman, OpenAI, GPT-3, GPT-3.5, GPT-4, Anthropic, Claude, Llama, Jeopardy ## Video description Chris Morrow, Product Manager, Meta Abstracts How do you build a roadmap for a product that is inherently unpredictable? The established playbooks for software development were built for predictable systems, but Large Language Models are stochastic, breaking the traditional model. In this talk, I will share a practical framework for product management in the generative AI era, built from direct experience shipping and scaling Amazon Rufus. I will explain three key concepts: why customer convenience is the ultimate driver for adoption, how to spin up a "GenAI Flywheel" of quality and relevance, and how to leverage iteration velocity as a decisive competitive advantage. Join this session to get a durable, first-principles framework to navigate the ambiguity of building with large language models. [Source](https://www.youtube.com/watch?v=ch4a8oCY-Kc)

Source quotes

[0:04] Chris Morrow: 如果你是做产品的,请举手——这是个陷阱题,因为人人都是做产品的。 [0:04] Chris Morrow: 有多少人来这里只是为了搞清楚‘随机性’(Stochastic)到底是什么意思? [1:49] Chris Morrow: 面对某项基准测试(Benchmark),模型的胜率(Win Rate)达到了 55%,满足上线标准 [3:50] Chris Morrow: 用 LLM 发明未来,把所有交互全变成运行时推理调用(Runtime Inference Call) [3:50] Chris Morrow: 在用户最初的 4 次交互尝试中,一旦模型回答出现严重错误或不及预期,用户流失且永不再使用该功能的概率就会激增 60%。 [8:02] Chris Morrow: 在 AI 浪潮里我们该干点啥? [9:25] Chris Morrow: 只有当“能为客户节省时间”与“LLM 所擅长的能力(如总结、多源信息整合)”产生交集时,方案才具备落地价值。 [9:25] Chris Morrow: 最低复杂度 + 最快上线时间 + 最大化客户便利。 [10:15] Chris Morrow: 这个回答是否属实? [14:41] Sam Altman: Make it one of your top goals to build the fastest iterating company the world has ever seen

Source quotes

[0:04] Chris Morrow: I regret immediately naming it that because it's actually kind of hard to say. [1:49] Chris Morrow: using ChatGPT to manage my life for 5 days and posting it on Medium [1:49] Chris Morrow: one day it shows up awesome and the next day it just like can't get out of bed. [3:50] Chris Morrow: if you throw a random LLM at me while I'm trying to buy toilet paper, that's less convenient. Now I'm pissed. [8:02] Chris Morrow: What are we doing in AI? [10:15] Chris Morrow: Is this factual or not? [10:15] Chris Morrow: What does factual mean? [10:15] Chris Morrow: Compared to what? [14:41] Sam Altman: make it one of your top goals to build the fastest iterating company the world has ever seen.

Original transcript

[0:04] Uh well, we're about to have some fun. [0:06] Uh step one, I don't have anything to [0:08] sell you. I'm just excited to be here uh [0:10] and talk about a topic that uh well [0:13] about being a stoastic product manager, [0:15] which I regret immediately naming it [0:17] that because it's actually kind of hard [0:18] to say, which uh so next time future [0:21] improvement, it will not be named that. [0:23] Raise your hand if you're a product [0:25] person. [0:27] It's a trick question. Everybody's a [0:29] product person. Come on, guys. You help [0:31] me out here. Okay. Uh, raise your hand [0:34] if you're here just to figure out what [0:35] the heck stochastic means. [0:39] Okay. All right. All right. That's fair. [0:40] All right. Uh, excellent. So, um, I [0:44] guess first we should start with like [0:45] who am I? This is me if I'm in Studio [0:47] Gibbli. Uh, I'm a product manager. I've [0:49] been at Alexa. I launched Amazon Rufus [0:52] and now I'm at Meta. Uh, I also helped [0:54] launch deep learning.AI's AI's course on [0:56] AI for everyone because I get really [0:58] excited about this topic of like let's [1:00] make AI accessible. Uh let's make sure [1:02] people can understand it and then let's [1:05] like deep dive on product frameworks for [1:08] stochastic systems. And the purpose is [1:11] like I'm here to bring you my learnings [1:13] so that you can go out and do new [1:15] learnings and not um learn the hard way [1:19] sometimes. Um so what are we going to [1:21] talk about today? We're going to talk [1:22] about the differences between software [1:24] product managing software and product [1:26] managing LLMs and then we're going to [1:28] two key plays. We're going to dive [1:30] really deep and be very very tactical on [1:33] finding the value and building the [1:35] flywheel and then we'll wrap up. [1:37] Everybody with me so far? [1:40] Oh golly. Okay, we got one. All right, [1:41] thank you. Don't worry. We're going to [1:43] success metric three by the end of the [1:45] uh end of the session. We're kind of [1:47] like trending red towards that. Um, [1:49] okay. Why do you care? Managing [1:52] software. Product managing software. [1:54] Okay. It's predictable. You kind of know [1:56] this. Raise your hand. Do I need to [1:58] cover software? [2:01] Excellent. Okay. So, here's what I've [2:04] learned. Not using chat GPT to manage my [2:07] life for 5 days and posting it on [2:08] Medium, but actually shipping products [2:11] scaling to 100 million users globally [2:13] is, okay, LLMs, they're stochastic. It [2:16] means probabilistic. It just means that [2:18] given some out inputs, we can't [2:20] necessarily predict exactly what you're [2:23] going to get on the uh output side, [2:25] which makes it a living nightmare [2:27] because someone's always going to send [2:28] you that one screenshot of like, hey, [2:31] the the production model did this. And [2:33] you're like, yeah, sorry, it's within [2:34] the 5% tolerance, but we'll talk more [2:36] about that. um the product focus instead [2:39] of describing the discrete features, the [2:42] acceptance criteria, the requirements, [2:44] we're talking about defining and [2:45] describing coverage and quality, what [2:49] you are going, what tasks you care about [2:51] because the LM can do anything. Uh well, [2:54] theoretically, uh and then the quality, [2:56] how you're going to know if it's doing [2:57] those tasks well or not. We're going to [3:00] talk more about this too. Uh progress is [3:02] fluid. [3:03] Bless its heart. some of the LM that [3:05] I've worked with, it's like working with [3:06] my 12-year-old son. Like, one day it [3:08] shows up awesome and the next day it [3:09] just like can't get out of bed. And [3:11] that's frustrating for the business, [3:13] frustrating for product managers because [3:16] we care a lot about quality because it's [3:18] at least in theory connected directly to [3:21] a customer outcome. Um, and then the [3:23] last one we'll talk about more, but [3:24] statistical improvement progress towards [3:26] launch is tracked by improvements to a [3:29] quality metric. It's not we're not like [3:31] running down the list of features and [3:33] saying, "Well, we've got n features left [3:34] to develop. We're on track to hit [3:36] milestone 3." It's we're at 55% win rate [3:40] against some benchmark [3:43] that puts us on track for launch. Okay, [3:47] so everybody's with me so far. Playbook [3:50] number one, convenience is king. [3:54] Do I need to deep dive here? [3:57] It kind of makes sense, you know? Yeah, [3:58] convenience king. durable. We've been [4:00] selling stuff around that for a long [4:01] time. But what I really want to get into [4:03] is is highlight here. You have [4:06] convenience. It's like, yeah, that's [4:08] kind of obvious. But like to the [4:09] customer, it's super discreet. Like it's [4:11] not like pie in the sky, hand wavy, hard [4:13] to measure. It's just like fewer steps. [4:15] Save me time. Make something less [4:17] complex. Help me trust whatever it is [4:21] the product that you're building more. [4:23] Love that. Love everything about that. [4:25] What I often see is that the detractors [4:29] of convenience are ignored because we [4:31] say [4:34] we're going to invent the future with [4:35] large language models. Everything will [4:38] be a runtime inference call. Like, okay, [4:40] cool. I love that. But also like where [4:43] and why? Um because as a customer, I [4:46] already know how to use your service [4:47] unless you're launching something like [4:49] brand new. I already know how to shop on [4:50] Amazon, which is what we're going to [4:51] talk about. So, like if you throw a [4:54] random LLM at me while I'm trying to buy [4:56] toilet paper, that's less convenient. [4:59] Now I'm pissed. And like I might I might [5:01] be so insensed I'll go buy my toilet [5:03] paper locally. Maybe I won't actually do [5:05] that. Um, just kidding. But I think what [5:08] I what I overall see is like it's we [5:11] handwave [5:12] sometimes uh the detractors of [5:15] convenience and then the product fails [5:18] because we didn't account for we [5:20] actually added a bunch of friction for [5:22] the customer. Um okay so let's let's you [5:25] know let's talk more about this. I was [5:26] PM number three on Amazon Rufus in case [5:28] you didn't know. Amazon Rufus is [5:29] basically a proprietary LM. It's a [5:31] shopping assistant built into Amazon. Uh [5:34] back in 2023, the goal was 0 to1 find [5:37] product market fit for this shopping [5:38] assistant. And the problem that I was [5:40] running into is like, well, how can we [5:41] add customer convenience to a mature [5:43] optimized service? Mobile's been around [5:45] for a long time. Amazon's been around [5:47] for a long time, and everybody knows how [5:48] to buy their toilet paper or in this [5:49] case, I think, you know, Philips Philips [5:52] toothbrush. Um, so how are we going to [5:54] do that? Well, you know, you may may [5:56] have caught it. Um, [5:59] it doesn't matter. Did you know that the [6:01] product detail page is actually 3,400 [6:03] pixels long? It takes you nine scrolls [6:05] to get from the top of a product detail [6:07] page on Amazon to get all the way to the [6:08] bottom. Now, who the hell ends up in the [6:10] basement of the product detail page? [6:12] Like, there's not even an ad module down [6:13] there. Uh, you know, it's unclear, but [6:15] what we knew is that customers are [6:17] coming and they're looking for very [6:18] discreet pieces of information. You want [6:19] to know the price, you want to know the [6:20] shipping date, you want to look at the [6:21] reviews, and then for some people, [6:23] you're going to go down and try to find [6:25] something in the abyss of the product [6:27] details and the product description. two [6:29] modules that move around all over the [6:31] place on the product detail page. Uh, [6:33] and so, oh yeah, here we go. Yeah, look [6:35] at that. Oh, we're still traversing. [6:36] Okay, here we go. Oh, nope. Not there [6:38] yet. Keep going. Keep going. And we're [6:40] done. Now, [6:42] that's a long way. Okay, so like what do [6:45] we do? Just give the customers the [6:48] information in one click. All I did was [6:50] just like map every single step of the [6:53] customer journey. Okay, customers [6:55] looking for product for product details [6:57] or product description information. It's [6:59] three to four scrolls on average, [7:01] sometimes more, sometimes less. [7:04] All we did was we just brought that [7:05] information above the fold, phrased it [7:07] like a question. We found that customers [7:09] were willing to they generally [7:11] understood what they would get if they [7:12] tapped one of these. They assumed they [7:14] were going to get an answer. They didn't [7:15] know exactly how. And then we made it so [7:17] that this bottom sheet that would pop up [7:19] and answer the question, customers could [7:21] easily dismiss it. and then scroll the [7:25] detail page like they know how to do and [7:27] compare the information in the answer to [7:29] the information that's on the page [7:30] because that's the more trust part of [7:33] adding convenience. Nobody cares if an [7:37] LLM spouts out something. They're first [7:39] going to check before I decide I'm going [7:41] to make a purchase decision on that. I'm [7:43] going to check to make sure I can trust [7:44] it. Fun fact, if we messed this up in [7:47] the first four interactions, customers [7:49] were 60% more likely to churn and never [7:52] come back because it's just not worth [7:54] their time. Like, I'm trying to buy [7:56] toilet paper. I don't need an extra 20 [7:57] seconds figuring out if I if if this is [8:00] worth my time. [8:02] Lovely. Okay, so that's like the [8:03] northstar. Convenience is king. Make [8:05] sure that we're, you know, weaving that [8:07] throughout. What's play number two? Gen [8:10] AI flywheel. Uh, this is a lovely quote [8:12] from Andrea Horowitz. AI systems get [8:15] better as more data is collected which [8:16] means it's possible to create a virtuous [8:18] cycle and that starts here where the [8:21] foundational uh model capabilities raise [8:23] your hand if you're working on [8:24] foundational models. [8:26] Okay. Okay. Okay. This is I can talk [8:29] more afterwards about specifics for [8:31] foundational models but this is [8:32] generally what I'm talking about is new [8:33] product development in the application [8:35] layer. I'm assuming that you're not deep [8:37] deep in model alignment [8:40] you know generating training data sets [8:41] etc. quality, coverage, customer [8:44] engagement, relevance. That's it's kind [8:46] of your playbook. Uh, okay, great. So, [8:49] like, okay, now you have to find product [8:51] market fit for this because somebody [8:54] comes to you and says, "Hey, what are we [8:56] doing in AI?" Hey, anybody gotten that [8:58] question before? Hey, what are we doing [8:59] in AI? Okay, cool. So, you're going to [9:02] define the initial coverage. You're [9:03] define the quality SOP. You're going to [9:05] launch the MVP, and then you're use [9:07] customer engagement to improve [9:08] relevance. And there's your playbook. I [9:10] can just take questions now. Just [9:12] kidding. Okay, so what do you do for [9:14] coverage? Coverage, you just make a [9:16] list. It's literally it's just there's [9:18] it's not more complicated. Grab a piece [9:20] of paper, sit down, brainstorm. What are [9:23] your customers trying to do? Why do they [9:25] why do you have a functioning business? [9:28] What are they trying to do? How and then [9:30] in that very very tactical customer [9:32] journey, how can you save them time? [9:35] And then [9:37] which of these tasks are LLM's good at? [9:40] Can you summarize information for [9:41] customers? Can you pull information from [9:43] disparate sources and combine it into [9:45] something for customers? [9:47] That intersection is is key because if [9:50] you have something that saves time but [9:51] an LM's not good at it, like well, [9:53] you're just kind of spinning your [9:55] wheels. And then just prioritize. My [9:57] lovely pro tip companion. This is my [9:59] intern Christopher. Um [10:02] just least complexity, fastest to [10:04] market, most added convenience for [10:05] customers. It doesn't have to be like [10:07] crazy complex. You can just start there [10:10] and assess product market fit. Great [10:13] coverage. Make a list. That's all. Just [10:15] get started. Quality. Oh man, I love [10:18] this. I'm not going to go super deep [10:20] into this because there have been some [10:21] really, really good talks here on [10:23] measuring quality, but like just go to a [10:25] whiteboard. You get five dimensions. I [10:28] kind of suggest like three, maybe four. [10:31] What's a dimension? It is a thing you [10:34] care about that helps you know whether a [10:36] response meets the bar for quality for a [10:38] launch. [10:40] Might be something like maybe you care [10:42] about factuality. Maybe you care that [10:44] it's grammatically correct and in the [10:46] correct language. Uh maybe you care that [10:48] it's relevant to the customer response. [10:50] Maybe you care that it's specific to the [10:52] customer response. You know that's just [10:54] a quick brainstorm. So you do that and [10:57] then you write just like a question, a [10:59] yes no question. Play Jeopardy. How [11:01] would you know if a response, how would [11:04] you ask somebody to look at a response [11:06] and then just say, "Is it good or not? [11:08] Is it factual or not?" Once you have [11:10] those, go ambush another human. Just [11:12] like put time on somebody else's [11:14] calendar. The less familiarity they have [11:16] with this, the better. And then you just [11:19] ask them, "Hey, here's a response. Is it [11:22] factual?" [11:23] And they're going to give you a lot of [11:24] feedback like, "Well, I don't know. I [11:26] can't quite, you know, like what do you [11:27] mean factual? What does factual mean? [11:29] like what is a based on what compared to [11:31] what? Lovely. You can you incorporate [11:34] all that feedback as soon as you can [11:36] explain these questions for the [11:37] dimensions that you've picked to a [11:40] person with no context because oh by the [11:42] way what is a human annotator? A person [11:44] with no context who's looking at your [11:46] response. If you can explain it to [11:49] somebody in 5 to 10 minutes, you got a [11:51] quality SOP. Look at that. like we've [11:54] spent like three hours on this so far, [11:56] maybe a little bit more depending on how [11:58] sparsely populated your office is. Um [12:01] and then the sort of final piece of this [12:03] is then working with the engineering [12:05] team defining the metrics um which you [12:08] can see sort of here of you know you [12:11] have three options there's sort of [12:13] generally human evaluation pros and cons [12:15] LLM as a judge automated metrics um [12:19] automated metrics is going to be a lot [12:20] on the foundational side um so if you're [12:22] in the application layer you're probably [12:24] doing LLM as a judge and or human [12:26] evaluation where do I get these human [12:28] evaluators Raise [12:31] your hand if you've ever evaluated your [12:32] own responses. [12:35] That's your like number one thing. It's [12:37] like that's go do it. Just now take your [12:40] SOP, run through 20 examples. Yeah, I [12:43] don't know. This one's not quite right. [12:44] I don't like that one. Okay, revise your [12:46] SOP. Um get now those five people that [12:50] you randomly picked, now they're doing [12:51] that work for free, hopefully. Um, but [12:54] before you go and like spin up a massive [12:57] evaluation, you can get really far with [13:00] your MLP by just five people who know [13:02] what they're doing looking at these [13:05] things. Okay, great. Quality solved. All [13:07] right, what else? Um, okay. You got to [13:10] define how customers are going to get [13:11] value. What's the signal once you launch [13:14] this thing? Launch the MVP. How do you [13:16] know if the customers are are driving [13:18] any utility for it? Because at the end [13:19] of the day, we're trying to add [13:20] convenience. [13:22] I mean [13:24] like I'm not the smartest guy and I just [13:26] like it's just clicks, engagement, [13:29] conversion. Pick one. Like what's [13:31] important to your business? Our [13:34] customers aren't dumb and no one has [13:37] time to waste. So like sometimes I I [13:40] field some questions about like well but [13:42] is you know is clicks is engagement like [13:44] precise enough? Is it detailed enough? [13:46] Yeah, because unless you happen to have [13:48] the world's greatest, most passionate [13:50] customer base who's just wandering to [13:53] your website or app to like kill an [13:55] afternoon, everybody has a job that [13:57] they're a problem they're trying to [13:58] solve, a job they're trying to do, and [14:00] they're trying to do it fast because [14:01] there's a million other things to do. [14:03] So, clicks, engagement, that's those are [14:06] great proxy signals for a customer is [14:08] deriving value. Retention is another [14:10] great, you know, signal. If they try it [14:12] once, then they keep coming back. That's [14:14] another great signal of value. That's [14:15] just not You don't have to expend a [14:18] bunch of brain power on this. It's just [14:20] what I'm saying. Um, okay. So then [14:23] great. We defined the quality. We [14:26] measured the quality. We defined the [14:27] metrics. We set a launch threshold. [14:29] Lovely. It's out. Customers love it. [14:31] They just love it. There's engagement's [14:32] through the roof. Uh oh, I got five [14:35] minutes. Yes, we got engagement through [14:38] the roof. Now, what do we have? Anybody [14:41] guess? [14:43] We have a splitting fly. Well, we almost [14:46] do. We need to do one more thing which [14:47] is [14:49] I often see that this is not discussed [14:53] specifically in like during product [14:56] development is cool. Now we have 50,000 [15:00] people interacting with it. What do we [15:01] have? We have labeled customer data. [15:04] That's amazing because now you can go [15:07] look at that customer data. What did [15:08] they choose? What's their depth of [15:10] engagement? what use cases you you know [15:12] you had a hypothesis about the tasks [15:14] that customers want to perform. Is that [15:17] what they're performing or are they [15:18] asking different questions? Are they [15:19] interacting with it in the way that you [15:21] assumed or in different ways? It's [15:23] probably going to be different ways. Uh [15:26] so then take that data and now that is [15:29] the prioritization for your iteration. [15:32] Now you go back to the prompt. Now you [15:34] go back to fine-tuning. Now you go back [15:36] to you work with the team to improve the [15:39] model's output and better fit it to what [15:41] the hell your customers are doing. [15:43] Again, it's not handwavy. Like it's it's [15:47] just very like you can you can just pull [15:49] it from the database, look at it, and [15:52] just immediately get a sense of like, [15:54] yeah, cool. They're getting the value [15:55] that we thought they were getting or [15:57] gez, we didn't anticipate that question. [16:00] I don't want to talk about the books [16:01] category. um we didn't anticipate that [16:04] question and okay it's a little bit [16:05] different now we need to go into prop [16:07] tuning now we need to go into finetuning [16:09] etc [16:11] I love this quote from Sam Alman which [16:13] is like now we have a flywheel and Sam [16:16] gave this talk to uh a bunch of like I [16:19] know him Sam Alman gave a talk to um a [16:22] bunch of startups and had this quote [16:24] about make it one of your top goals to [16:25] build the fastest iterating company the [16:27] world has ever seen that's the [16:29] competitive advantage more data [16:32] more engagement, more data to improve [16:34] the model, better fit to your customers, [16:37] and that that flywheel keeps spinning [16:39] faster. And this is just a table where [16:41] I'm just highlighting. So, you know, if [16:43] you look at GPT3, [16:46] you look at the usage. Well, it took [16:47] them, you know, almost two and a half [16:49] years to go from GPT3 to GPT3.5 [16:52] and then it was uh it was followed very [16:56] rapidly with GPT4. Why? They had a bunch [16:58] of customer data that then turned into [17:00] training data, labeled data, fine-tuning [17:02] data, and they can move it faster. You [17:04] can see the same with Claude and with [17:06] Llama. [17:08] So, just to recap, we've got convenience [17:11] is king. Pretty obvious. The flywheel [17:14] effect. It's it's a virtuous cycle and [17:16] that becomes the moat for your company. [17:19] Uh, and then iteration velocity, that's [17:21] what differentiates you from, you know, [17:24] any other company. [17:26] That's all I got. Thank you.