Spotify 是一家杰出的公司，是我工作过的最好的公司。六年多后，当我离开公司时，我想帮助其他公司变得更像 Spotify。然而，我不认为公司可以仅仅复制后来被称为“Spotify 模式”的部落、分会和小队的组织结构，但我想解释一下 Spotify 的真正与众不同之处。
Marty Cagan 的《Inspired》一书中的做法对 Spotify 的运营模式产生了重大影响。因此，当他开始讨论授权产品团队时，它准确地呼应了我们所说的“自治团队”的含义。我很快开始融入这个术语，并大量借鉴了 Marty 和 SVPG 对这个想法的富有洞察力的解释。
当《Empowered》一书出版时，我惊讶地发现它如此贴切地阐述了我在 Spotify 的经历。现在他们给了我更好的概念，通过“产品运营模式”的定义来解释真正的 Spotify 模式，以及该模式与大多数公司正在做的模式有何不同。
背景
到 2000 年代末，Spotify 赢得了主要唱片公司的认可，认为流媒体是未来，从而彻底改变了音乐行业。
到 2014 年，该服务已经积累了 6000 万活跃用户，现在战斗已经转移到另一个战场。许多新的竞争对手，包括谷歌、亚马逊和苹果，都准备通过自己的订阅流媒体服务加入战斗。
通过流媒体轻松访问音乐——Spotify 曾竭尽全力实现这一目标——现在已成为赌注，而不是差异化因素。Spotify 需要继续创新以保持其市场领先地位。
产品运营模式
当我们讨论产品运营模式时，我们从高层次上关注三个主要维度：
- 首先是公司如何决定要解决的最重要的问题——产品策略。
- 第二个是他们如何解决这些问题并发现值得构建的解决方案——产品发现。
- 第三是他们如何构建、测试并向客户交付这些解决方案——产品交付。
本文将试图重点介绍 Spotify 如何拥抱并体现这三个维度背后的原则。
1、您如何决定要解决哪些问题 - 产品策略
Spotify 的产品战略是根据对受众群体划分的洞察而制定的。Spotify 知道他们基本上有两种主要类型的用户。那些知道自己想听的音乐的人，他们称之为“前倾”听众。而那些并不真正了解艺术家或专辑的人，他们只是希望该服务能够帮助他们发现他们喜欢的音乐，他们将其称为“向后靠”听众。
很长一段时间以来，Spotify 一直认为这项服务对于发现音乐来说已经相当不错了。您所需要的只是一个好的搜索栏和一个播放列表工具。它能有多难？
事实证明，对于许多主流“后仰”用户来说，这相当困难，因为他们没有早期采用者和 Spotify 雇用的音乐迷所拥有的时间或知识。
另一个战略洞察是，越来越多的用户通过 Spotify 所谓的“ 时刻”来发现音乐，例如“学习”、“跑步”或“聚餐”，而不是通过寻找特定
的流派或艺术家。
Spotify 已经开始从用户通过关注人和播放列表来构建音乐库来完成工作的模型转变为基于推荐的模型，在该模型中，服务根据用户过去听过的内容来完成工作。
意识到推荐需要成为产品战略的核心部分，Spotify 最近收购了位于马萨诸塞州的初创公司 The Echo Nest。前 Echo Nest 工程师现在与 Spotify 的机器学习工程师合作，帮助改进基于推荐的音乐发现。
因此，Spotify 领导层召集了他们的产品团队，并解释说，他们需要集中精力了解为什么服务在后倾用例中表现不佳，并尝试解决这个问题。
这种关注意味着对许多其他潜在机会说不，并推迟或终止其他机会。例如，他们关闭了一项围绕视频流的重大计划，并重新分配人员和资源，以专注于后倾听众问题。
这种对业务的整体看法以及由此产生的关注点使产品团队能够将精力投入到要解决的最关键问题上，从而提高成功的可能性。
2、如何解决问题——产品发现
最初 Spotify 有一种名为Discover的推荐方法 ，它根据用户的个人收听历史，以 Netflix 风格的布局呈现专辑建议，但这似乎需要用户进行太多交互，用户表示希望“让我快速上手，而不需要担心”。付出努力。”
与此同时，Spotify 的新 浏览 功能成为该应用程序的新起始视图，并展示了 Spotify 编辑团队手工策划的播放列表，例如 Spotify 编辑团队的“Your 最喜爱的咖啡馆” ，与“发现”功能 相比，用户参与度显着提高 。
最重要的是，某些行业专家认为，向后倾斜的用户根本对探索新音乐不感兴趣。
然而，一些正在研究建议的机器学习工程师并不相信这是真的。他们相信必须有一种方法可以减少用户的摩擦，并帮助他们筛选 3000 万首歌曲以找到精彩的推荐。
他们的乐观情绪得到了最近一个名为“ Play It Forward”的黑客周项目的支持，该项目是 Spotify 流行的“Year In Music” （现在称为“ Wrapped ”）的一个附加 功能，该功能提供了用户在 Spotify 上的一年的摘要。
Play It Forward分析了用户的收听历史记录，使用与Discover 相同的算法 来创建您尚未在 Spotify 上收听过但您可能会喜欢的音乐播放列表。
该播放列表是在用户的《音乐之年》评论结束时呈现给用户的 。几个月后，工程师们惊讶地发现数百万用户仍然在使用它。
这引发了一个想法：如果我们可以创建一个这样的播放列表，并且更频繁地更新它会怎么样？这就是后来被称为《Discover Weekly》的想法的种子 。
这个概念相当简单，并且可以利用现有技术。该功能将您的收听历史记录分类为微流派。然后，它对数十亿用户创建的播放列表使用协作过滤，识别出那些像您一样听过 x 也听过 y 的用户——这是您尚未在 Spotify 上发现的曲目。
工程师们向产品经理和产品设计师提出了这个想法，他们开始产品、设计和工程之间的跨职能协作，以评估潜在的产品风险。
首先是 价值 风险：用户会选择使用它吗？最重要的是，如果他们确实使用它，他们会发现足够的价值来继续使用它吗？
接下来是 可用性 风险：用户能弄清楚如何使用它吗？他们是否能够轻松找到该功能并了解其好处？意识到 Spotify 以前从未 为 用户制作过播放列表，并且之前只是将其转储到他们的库中 - 人们对此有何反应？
接下来是 可行性 风险：工程师是否可以利用现有系统来实现此目的，或者他们是否需要构建新系统（可能成本很高）？Spotify 的高级工程师已经警告团队，他们的计划可能无法扩展，因为播放列表系统并不是为处理这种使用而构建的。
最后，这对 Spotify 的业务可行吗？几个月后，Apple Music 在未经用户同意的情况下将 U2 的新专辑《Songs of Innocence》放入每个用户的音乐库中，引起了强烈的反对，并迫使苹果公司创建了专门的工具来删除该 专辑。人们对类似的越界行为感到担忧，Spotify 联合创始人兼首席执行官 Daniel Ek 明确向团队指出，这个想法可能会适得其反。
在考虑了所有风险后，产品团队认为这个想法有可能有意义地解决向后倾斜用户的问题，因此他们认为值得进行一系列实验并收集一些具体数据。该团队有明确的指标来引导他们取得切实的业务成果：提高覆盖范围、深度和保留率。
该团队开始悄悄地试验实时数据原型，并在没有任何正式公告的情况下巧妙地向所有员工推出了该原型。通过监控指标，他们观察到该功能在同事中的病毒式传播。这一初步回应是一个早期迹象，表明有经验的用户至少能够找到并使用 Discover Weekly。
这给了团队足够的信心来进行适当的员工释放（在许多产品公司中被亲切地称为“dogfooding”），通过电子邮件和其他内部沟通渠道宣布，并呼吁尝试一下，并提供定性反馈。
Spotify 员工喜欢这个新功能。“就好像我的秘密音乐双胞胎把它们放在一起一样！ 里面的一切都 很好！”
在令人鼓舞的同时，产品团队也明白 Spotify 的员工并不是一个预测测试，尤其是对于向后倾斜的情况。但现在他们有信心尝试回答实际用户是否也会有同样的感觉？
与其他产品模型公司一样，在 Spotify，任何授权的产品团队都可以向最多 5% 的用户进行实验，而无需获得许可。该团队决定将其推广到 1.5%（1,000,000 个用户），并密切关注数据开始流入。
主要指标表现非常出色，定性结果同样令人印象深刻。该功能邀请用户对新功能进行评分，并提供开放式反馈。超过 1500 份调查回复纷至沓来，超过 85% 的受访者在 5 分制中给予 4 或 5 分，只有极少数人提出了因 Apple Music U2 的反应而成为先前关注的同意问题。
值得注意的是，65% 的受访者在他们的个性化每周播放列表中发现了“一首最喜欢的新歌曲”。 用户还在 Twitter 上赞扬了他们最喜欢的新功能，并发表了这样的评论：“Spotify 的Discover Weekly播放列表对我的了解程度如此之高，真是太可怕了 。”
迄今为止，产品发现实验成功地降低了与可行性、可用性和价值相关的风险。但可行性仍然是一个问题。
该团队希望将 Discover Weekly扩展 到更广泛的用户群。然而，随着用户数量的增加，很明显现有的播放列表系统将无法扩展，正如 Spotify 高级工程师所预测的那样。该播放列表系统根本无法处理 7500 万用户播放列表的同时更新。
但现在 Spotify 拥有了他们所需的证据，表明重建播放列表系统以适应必要的规模是值得投资的（这就是我们所说的高度 完整性的商业案例）。
3、如何构建——产品交付
2006 年，在 Spotify 诞生之际，软件产品开发的标准瀑布方法需要花费数月的编码时间，主要由内部利益相关者指导，然后才能向全世界发布产品。
这种方法的一个明显缺点是，直到项目结束为止，用户反馈很少，导致产品更多地反映内部利益相关者的偏好，并乐观地希望它也能与潜在客户产生共鸣。
认识到这些局限性后，Spotify 的领导者和产品团队在早期就意识到需要采用更好的方法来发现和交付产品。
因此，我们进行了大量投资来支持必要的实验，并为产品团队提供访问关键用户行为数据的权限。这包括仪器仪表、遥测、监控和报告的基础设施。该公司还大力投资于部署基础设施，特别是 A/B 测试，并拥有专门的平台产品团队专注于支持这些实时数据测试。
Spotify 也是小型、频繁、非耦合发布的早期倡导者，并投资于持续交付的工具和技术。
由于 Spotify 在产品交付方面的技术在业界相当有名，因此我们不会在这里花太多时间。然而，至关重要的是要认识到，这些投资使 Spotify 授权的产品团队能够交付 成果，而不仅仅是产出。
这种交付基础设施为Discover Weekly 和无数其他大大小小的 Spotify 创新铺平了道路 。
产品团队和产品文化
希望对 Spotify 产品工作的剖析有助于阐明由强大的产品领导者领导的、在产品模型中工作的强大产品团队的力量。
虽然 Spotify 以其强大的产品团队而闻名，但这个例子展示了这个概念在实践中的真正含义。它需要强大的产品领导者提供战略背景——尤其是硬产品战略决策——并知道如何为产品团队做好工作建立必要的环境。
联合创始人丹尼尔相信，在这样的结构中，对业务成果的责任，与对产品策略的清晰理解相结合，使用基于数据的实验，将产生最好的结果——即使这些想法不是他自己的。
《Discover Weekly》的这个例子如此具有说明性的原因之一 是 Daniel 公开对产品理念持怀疑态度，并向产品团队分享了他的担忧。但值得赞扬的是，他给团队提出了一个需要解决的问题，然后让工作继续进行。
值得赞扬的是，产品团队看到了支持技术的潜力，并开始负责任、有效地解决产品风险。这就是众多技术驱动的创新背后的原因，也是授权产品团队的真正含义。
与其他产品模型公司一样，Spotify 认识到，最具创新性的想法（真正与客户产生共鸣的想法）通常源自那些每天与支持技术打交道的人——工程师。他们具有独特的优势，可以发现新兴的可能性。
伟大的领导者明白创造一个环境的必要性，让授权的产品团队可以发挥他们的创造力，发现和提供不仅客户喜欢的创新解决方案，而且可以推动业务成功。