为学习而构建，为交付而构建

我们长期以来一直主张，开发产品始终至少有两种主要方式。

即使到了今天这个AI时代，最常见的仍是项目模式，它关注的全是产出。在这种模式下，利益相关者或高管提出一份排好优先级的功能与项目路线图；随后，对每个功能或项目，一位被称为功能团队产品经理的人编写规格说明，例如产品需求文档（PRD）；接着，设计师按照这份规格做设计，工程师再把规格中的东西构建出来。

另一种方式是产品模式，它关注的全是成效。在这里，产品领导者或利益相关者确定一个需要解决的重要问题，由一支获得充分授权、跨职能的产品团队，先发现一个值得构建的解决方案——也就是有证据表明我们能够取得所需成效的方案——然后再构建并交付它。在产品模式下，团队每周制作10至20个、甚至更多原型，并不罕见。早在生成式AI出现之前，情况就已经如此；借助Figma这样的原型工具，这其实并不难。〔注1〕

不过，虽然这两种工作模式早已存在，今天也依然存在，很多事情已经改变了。

如今，交付成本大幅下降，真正把功能或项目做出来，已经不再是瓶颈。产品领域的许多人现在认识到，项目模式就是一座加装了涡轮增压器的功能工厂，能够以比以往任何时候都更快的速度，生产出更多糟糕的产品。

现在，真正的瓶颈显而易见：发现一个值得构建的解决方案。它要同时满足客户和公司的需要，要产生所需的成效；它不仅要解决问题，还要比替代方案好得足够多，以至于客户愿意转而选择它。

AI依然能帮助产品发现，但它提供帮助的方式，与帮助交付的方式非常不同。最重要的是，产品发现正是产品经理的知识至关重要的地方。

我写这篇文章，是因为随着产品团队从项目模式转向产品模式，许多产品经理正在努力弄清自己今后能够做出什么贡献。他们知道，自己过去负责项目管理、协调推进的角色，无法提供所需的价值，但又不确定怎样做才能提供这些价值。

一些产品经理意识到，凭借新一代工程工具的能力，例如Claude Code和Cursor，他们确实可以更深入地参与产品构建，亲自承担更多工程工作。对于具备技术基础的人来说，他们当然可以这样做，这并没有什么问题。

但最优秀的产品经理认识到，虽然自己确实是产品的构建者与创造者，他们构建产品的目的，却与工程师非常不同。

多年前，产品教练Jeff Patton——《用户故事地图：发现完整故事，构建正确的产品》的作者——提出了“为学习而构建，与为交付而构建”这个说法，用来描述产品发现与产品交付之间的区别。〔注2〕

最近我发现，在生成式AI时代学习产品模式的团队，尤其容易对Jeff的这句话产生共鸣。

无论发现还是交付，我们都在构建，只是构建的目的截然不同：一个为了学习，一个为了交付；通常，使用的工具与方法也不同。此外，虽然发现与交付中都有“测试”这个概念，它在两者中的含义却很不一样。

在产品发现中，我们是为学习而构建。我们试图找到技术、功能、用户体验与业务约束的一种组合，以应对发现中的关键风险：价值、可用性、技术可行性和商业可行性。如今，几乎任何人每周制作10至20个原型，或完成这么多次原型迭代，都很容易；制作这些原型也不必依赖产品设计师或工程师的帮助。制作原型的主要目的是针对这些风险进行测试：“测试”意味着与用户和客户一起检验价值与可用性，与工程师一起检验技术可行性，与公司内部的利益相关者一起检验商业可行性。

在产品交付中，我们是为交付而构建。我们要构建的是达到商业质量标准的产品：我们能够销售它，为它提供服务与支持，客户能够依靠它经营自己的业务。为交付而构建时，面对的风险非常不同。我们需要考虑规模支撑能力、性能、容错、可靠性、准确性、隐私、安全、运维、资源开通与配置、国际化，以及更多要求。交付中的“测试”，意味着确保产品满足这份长长的要求清单，并且确实能够兑现它所宣称的功能与表现。

如今的实践中，有几处重要变化。

首先，四种主要的原型类型今天仍在使用，而且使用得比以往更多；但新一代工具改变了这四种选择的相对成本。现在，我们能够以比过去快得多、便宜得多的方式，制作使用真实数据的原型。这让我们能够更早、以更低成本，把产品的功能原型交给选定的用户和客户，并收集他们实际使用所产生的数据。这为“为学习而构建”带来了根本性的改变。

其次，得益于基于生成式AI的原型工具所带来的速度，我们往往可以并行测试多种方法。过去，迭代大体上是依次进行的：我们从自己认为最有希望的方案出发，不断迭代，直到有证据表明应该进入产品化，然后宣布大功告成，转向交付，也就是为交付而构建。而今天，迅速制作多个原型、探索解决问题的多种不同路径，再同时测试这些原型，已经并不罕见；之后，我们可以继续对最有希望的方案逐轮改进。

这里的讨论聚焦于产品发现中的原型制作，以及产品交付中的产品化。虽然两者各自包含的活动不止这些，但其核心确实就是为学习而构建，与为交付而构建。〔注3〕

如今，许多顶尖公司已经调整了产品管理岗位的面试流程，用来评估候选人是否理解这份工作的本质：构建并测试原型。

致力于为学习而构建的优秀产品经理，需要具备哪些技能与知识？熟练掌握原型工具和发现方法，是容易的部分。困难的部分，是培养评估学习所得、指引方向所必需的产品直觉。

我接触、辅导和指导过很多产品人。坦率地说，并非每个人都对为学习而构建感到兴奋；甚至可以说，并非每个人都对任何形式的构建感到兴奋。有些人更愿意把自己的作用理解为别的事情，通常是充当产品团队的协调者、管理者，或某种“黏合剂”。我认为，这些人面临的风险正在不断增大。

但对于那些拥抱产品经理这一角色的构建者、创造者本质，并专注于培养产品直觉与为学习而构建的技能的人，我相信，我们正在进入一个属于优秀产品人的黄金时代。

注：为回应大家提出的许多问题，我们已经发布了《为学习而构建：常见问题》。

如果你此前没有意识到，生成式AI出现之前就已有这种工作模式，可以看看2007年出版的《INSPIRED》第一版，或2017年出版的第二版，也可以两版都看。↩ 返回正文

有许多不同的说法，都试图概括产品模式的这个关键概念。例如，Y Combinator就以倡导“构建不能规模化的东西，与构建能够规模化的东西”而闻名。↩ 返回正文

必须认识到，我们在这里描述的不是一个流程；它是一种概念模型。发现与交付可以采用许多不同的流程。同样重要的是，不要把发现与交付看作前后相继的阶段：在实践中，两者都在持续进行，我们当然也会从交付中学习，尤其是在产品已经大规模部署之后。但原则是，在发现中失败、学习，而不是把我们的糟糕想法暴露给所有付费客户。↩ 返回正文

图片暂时无法载入，可通过上方出处查看原作。