Newshot AI Product Management at Spotify: A View From Three Angles
几乎每一篇关于产品管理与 AI 的文章或播客，都会把“AI PM”当作一个岗位来谈论。但这个岗位究竟长什么样，取决于你在构建什么。
我们三个人在同一家公司、同一套技术栈、组织中的同一片区域工作。我们时刻都在交流，但我们的日常工作，以及成功的定义，却相当不同。
Henok 在 Tech Research 负责产品，这里的成功可能是一个团队做出了正确的技术选型，可能是一套帮助多个团队更有信心地工作的方法论，也可能是一个向组织展示“什么是可能的”的成果。Divita 负责一个推荐基础模型的产品，塑造它学习什么，以及它的能力如何帮助团队为听众构建更好的体验。Humberto 构建用户真正交互的体验，把模型能力、交互设计和用户反馈融合成用户觉得有价值且可信的东西。
我们共享的不仅是技术。我们在朝着相同的公司优先级努力，最终服务的也是相同的外部用户。我们的工作深度相连：一个来自研究的想法，可能变成一项可复用的模型能力，从而在用户体验中打开新的可能性。而让它真正落地，需要三个人的协作。
这种紧密关系，反而容易让人忽略我们角色之间的差异，尤其是当我们使用同一套 PM 词汇时。我们都会谈“质量”“evals”和“shipping”，但这些词的含义会随着各自负责的问题空间而变化。就连影响力看起来也不一样。组织信念的转变或投资方向的改变，可能就是研究上的重大胜利；对模型 PM 而言，回报出现在模型改进转化为多个用户体验中更好的推荐时。而对体验 PM 来说，归根结底取决于用户是否喜爱这个产品并愿意回来。
产品管理的基本功依然适用。但构建 AI 产品需要根据你所负责的内容进行不同形式的专业化。下面，我们每个人分享这在实践中是什么样子。
The research layer: where the product is technical leverage
Henok，Principal Product Manager，Tech Research，Personalization
作为 Tech Research 的产品负责人，我在与产品团队一起应对当下需求的同时，也在观察随着 AI 改变“什么是可能的”，接下来什么可能变得重要。我把我们的产品看作技术杠杆：把科学专长用在能够改变 Spotify 构建什么、或者能让我们更有信心地构建的地方。
1. AI is changing which problems need research
更好的模型和工具意味着产品团队越来越能够完成过去需要研究深度参与的工作。这让研究可以更多地聚焦于共享方法、系统设计，以及那些正确路径仍不明确的新兴能力。
真正重要的问题往往横跨多个团队，这进一步改变了研究与产品团队之间的动态。两个例子是：如何评估开放式模型行为，以及如何以多个产品都能使用的方式来表示用户和内容。
AI 让快速构建一个令人兴奋的原型变得容易。然而，这个原型与一个能为数亿用户稳定工作的产品之间的差距可能非常大。同样，一个更复杂的模型可能在演示中看起来很棒，但在真正重要的生产任务上却没有实质性差异。考虑到这一点，评估、延迟、成本、数据和集成都成为研究问题的一部分。这正是帮助我们做出有依据的投资决策的东西。
2. A promising model architecture is not a roadmap
Spotify 的 AI 产品管理：三个视角
有一个项目让我尤其清楚地看到了这一点。我们一直在探索一种架构，它把目前分散在不同系统中的能力整合在一起。起初，问题是它能否奏效。随着证据增多，一个更难的产品问题浮现出来：组织应该拿它做什么？新架构可能会影响基础设施、评估、界面以及多个团队的计划，而且它还要与已经运行的系统并存。
我的工作是把更大的想法转化为组织可以合理做出的决策：从一个具体问题开始，找到有用的测试，并就什么证据足以证明下一步合理达成一致。这不是非此即彼。我们沿途开发的方法和组件已经可以改进现有系统，即使更大的问题仍未解决。
最初作为探索的工作现在为模型团队和体验团队提供信息，其方法和组件可以改进现有系统，即使更大的架构问题仍未解决。更难的工作是在产品需求、技术约束和现有承诺之间找到一条可信的路径。
3. 快速变化领域中的长反馈循环
研究的影响可能需要数月才能显现，而且常常出现在另一个团队的路线图或指标中。在此期间，技术和组织的优先级都可能发生变化。这使得影响力成为该角色的关键部分。
在研究团队内部，我提供产品和战略背景，但不规定答案。在团队外部，我把工作与决策连接起来，让相关团队尽早参与，同时明确证据能说明什么、不能说明什么。如果等到研究完成才开始这样做，决策窗口可能已经关闭。
AI 的步伐还要求我比过去许多 PM 角色更深入地理解技术。AI 工具帮助我梳理论文和原型，而且我一次会密切关注一两个项目，以判断其中的选择和障碍。
这个角色要求技术深度和组织判断力：看清哪些问题在跨团队层面重要，在想法变成承诺之前进行测试，并及时把证据与决策连接起来。当我们做到这一点时，影响会通过团队使用的方法、选择的技术和构建的体验不断累积。
模型层：产品是一种能力，客户是另一个团队
Divita，AI Foundation 个性化团队首席产品经理
我负责一个基础模型的产品工作，这是一个专为推荐构建的语言模型，设计目的是引用 Spotify 上的真实内容项。和任何平台团队一样，我们构建的一切都通过其他产品团队触达用户。这个平台的不同之处在于产品本身。它的行为由数据塑造，输出是概率性的，而质量对每个集成它的团队来说含义都不同。正是这种组合塑造了这份工作。
我的客户是内部团队，他们构建 Spotify 用户每天交互的界面和体验。他们有自己的路线图和指标，而同一个模型需要服务于对“好推荐”的不同定义。我的工作是理解这些需求，并决定共享能力在哪些地方能很好地服务他们。一个团队的请求可能指向对多个体验都有用的东西；识别这些机会有助于塑造模型的方向。
正是在这里，产品基本功变得具体。产品市场契合意味着理解团队可以用模型解决哪些问题。清晰的价值主张意味着解释模型能为他们的特定体验提供什么。而业务影响来自他们用模型交付的东西。理解这些需求给了我们方向。把它们转化为模型行为，才是工作发生变化的地方。
1. 你无法为模型行为制定规格。你要塑造它，然后证明它重要。
在传统的产品岗位上，我会定义系统应该做什么，并与工程师合作把它构建出来。在这里，行为是通过训练学习到的，而不是直接在代码中指定的。如果我们想提升推荐的相关性，仅靠一份规格说明无法做到。我会与团队一起决定模型需要学习什么、哪些数据能帮助它学会这些，以及我们如何知道它是否已经学会。训练需要时间，因此这些决定会影响我们在每个周期中优先处理什么。
真正起作用的两个杠杆是教模型什么，以及如何检查它学到了什么。数据和评估。我工作的很大一部分是决定这些评估应该衡量什么。对某个特定听众、在某个特定时刻，什么样的推荐才算好？一个看似合理的推荐只是起点。我们需要理解它在多大程度上契合听众的上下文、在熟悉感与探索之间取得平衡，并随时间保持相关性。设计评估意味着把这些期望转化为我们可以一致评估的标准。
然后，我们需要把我们在模型中衡量的内容与听众的体验联系起来。离线评估帮助我们理解模型行为，而在线指标则显示这种行如何转化为用户体验。我与合作团队一起了解哪些模型改进会在他们的产品中产生影响。我们一起学到的东西有助于我们确定下一个训练周期的优先级。
2. 展示共享模型能实现什么
共享推荐模型的前景在于，一项改进可以惠及多种体验。但每个团队都已经有一套针对自身需求优化的系统。我们的首要任务是证明共享模型能够满足该体验在质量、延迟和成本方面的要求。我与合作团队一起定义这些标准，并就如何评估它们达成一致。
满足这些要求只是一个起点。更长期的问题是，团队通过构建在同一个模型之上能获得什么。我们在一种体验中学到的东西，能否改进另一种体验中的推荐？团队能否在现有能力之上尝试新东西？我工作的一部分，就是把这一前景转化为我们可以测试的具体问题。
单次评估无法回答所有这些问题。我们需要跟踪模型在多个训练周期中如何发展，以及这些变化如何在不同体验中转化。这让我们能够区分一个有前景的结果和一个可以据此规划的规律。
基础模型需要时间和资源，而且随着更多团队使用，收益会逐渐累积。清楚这些收益出现在哪里，以及我们还需要确立什么，有助于我们决定下一步的优先级。这就是我们随着时间推移为模型建立论证的方式：通过团队可以在自身产品决策中使用的证据。
3. 如果没人用它上线，好也不够
成功意味着让团队用你的模型上线产品。一个好模型至关重要，但它的价值取决于另一个团队能否用它解决对他们重要的问题。
促成这件事的很多工作看起来完全不像模型工作。这意味着找到一个团队，其当前系统在他们关心的某个指标上已经触及天花板，然后让模型成为一条有吸引力且切实可行的前进路径。这需要就需要这项能力交付什么达成一致，定义集成契约，并在要求合作团队承诺之前，负责测试风险最高的假设。
我团队今年最好的成果来自一个 surface 团队，他们想要一个我们正好有能力交付的结果。这次合作之所以奏效，是因为我们在就架构达成一致之前，先就如何衡量成功达成了一致。这为我们决定构建什么以及它是否有效提供了共同基础。
这就是我会向考虑这份工作的人描述的工作版本。你负责模型，但你也负责把它的能力转化为另一个团队可以自信上线、用户能够受益的东西。
体验层：客户即用户，模型只是众多要素之一
Humberto，Sessions、Personalization 首席产品经理
如果研究层创造技术杠杆，模型层创造可复用的能力，那么体验层就是所有这些都必须为 Spotify 数亿用户发挥作用的地方。我构建的是用户实际交互的产品：在这个界面上，一种模糊的心情会变成一组歌曲，而系统必须在请求含糊不清时也能做出有用的事情。
我的客户直接就是 Spotify 的用户。这是与其他两个角色最简单的区别，也几乎改变了这份工作的一切。研究和模型层是我的基础技术，我的工作是把这项技术变成令人愉悦的东西。因为体验团队离用户最近，我们最直接地看到哪些模型缺口和未解答的研究问题当下最重要。这使得对其他层的依赖不那么像瓶颈，而更像是整个技术栈中共享的优先级信号。
1. 为无限输入而设计
与以往产品工作相比，最大的转变是输入的性质。在传统产品中，用户的操作是受约束的：他们点击按钮、从菜单中选择、输入搜索关键词。系统的响应是可预测的，测试也是如此。你知道用户做了什么，你知道系统应该做什么，而且你可以验证它。
在 AI 体验中，输入是开放式的。用户提出模糊、不明确或复杂的请求，这些请求并不映射到目录中的任何单一实体。智能体会解读用户可能的意思，并构建响应。
这重塑了你原以为固定的约束。在关键词搜索中不可接受的延迟，在对话式交互中却完全可以容忍，因为用户明白他们要求的是更难的事情。但诸如系统在没有信心时应如何响应，以及出错时如何恢复之类的问题，并没有稳定的答案——它们属于产品，而不是模型。
2. 评估是产品，不只是流程
A/B 测试和离线评估仍然重要，但仅靠它们并不足够。当输入空间是开放式的，你无法预先定义每一个值得测试的场景。
所以我们构建新的工具。我们从真实使用模式中构建数据集，并设计反馈回路，以显示系统在哪里误解了请求或做得不够。我们构建基于 LLM 的评判器和针对我们产品所支持的具体交互调优的自定义评估器，然后用它们来衡量变化究竟是真正的改进，还是只是不同。
评估不是发布前发生的某个阶段；它本身就是一个持续的产品。一个能在基础模型的众多用例中通用的评估是起点，而不是终点。体验团队必须弥合“模型总体不错”和“这个具体交互对这个具体用户来说不错”之间的差距。
3. 对话让反馈变得自然
在对话式产品中，用户不只是与系统交互。他们与它交谈。当出错时，他们会用自己的话实时说出来。这种直接性在以往的产品界面中并不存在，它改变了可能性。
用户对具体交互的挫败感，同时是对体验、模型以及潜在训练数据的反馈。用户告诉系统“那不是我的意思”，不仅仅是一个需要在本地修复的产品问题。工作是构建机制，大规模检测该信号、解释它，并把它传回协作链，让每一层都得到改进。
这是我会向正在考虑这个职位的人描述的角色版本。你对用户有最直接的接触渠道，并对结果拥有最切实的归属责任。但你是在你能够影响而非控制的系统之上构建，服务的用户，其期望正被他们接触的每一个其他 AI 产品实时塑造。这门手艺在于，用本质上具有概率性的素材，做出值得信赖的东西。
总体反思
我们在这个技术栈上工作得越久，就越明白并不存在一种简单的新“AI PM”技能组合。产品管理一直就是同一门手艺：清晰定义问题、深入了解客户、衡量真正重要的事项，并通过证据而非热情建立信念。但 AI 技术栈增加的不是一份不同的工作。它是在基本功之上的一层专业化，而这些层次呈现出的类型比人们意识到的更多，并且因产品而异。AI 产品管理是一个多样且复杂的角色，只会随着变化速度而变得更令人兴奋。
分享这篇文章