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

Marty Cagan｜Build to Learn vs Build to Earn

原文发表：2026-04-16｜中文发布：2026-11-02

全文中文翻译。经授权全文译载，格得译。earn按文中可销售、服务和持续支持的商业产品语境译为“交付”；分节标题与关系图为编者所加，三条原注完整保留。

[阅读原文](https://www.svpg.com/build-to-learn-vs-build-to-earn/)

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

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

## 产品模式：找到值得构建的方案

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

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

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

现在，真正的瓶颈显而易见：发现一个值得构建的解决方案。它要同时满足客户和公司的需要，要产生所需的成效；它不仅要解决问题，还要[比替代方案好得足够多](https://www.svpg.com/commercial-vs-internal-products/)，以至于客户愿意转而选择它。

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

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

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

但最优秀的产品经理认识到，虽然自己确实是[产品的构建者与创造者](https://www.svpg.com/the-era-of-the-product-creator/)，他们构建产品的目的，却与工程师非常不同。

## 发现与交付：两种构建目的

多年前，产品教练[Jeff Patton](https://www.linkedin.com/in/productdesigncoach/)——[*《用户故事地图：发现完整故事，构建正确的产品》*](https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909)的作者——提出了“为学习而构建，与为交付而构建”这个说法，用来描述产品发现与产品交付之间的区别。[〔注2〕](#section-5)

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

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

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

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

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

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

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

## 产品经理需要怎样的能力

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

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

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

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

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

注：为回应大家提出的许多问题，我们已经发布了[《为学习而构建：常见问题》](https://www.svpg.com/build-to-learn-faq/)。

## 注释1

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

## 注释2

有许多不同的说法，都试图概括产品模式的这个关键概念。例如，[Y Combinator](https://www.ycombinator.com/)就以倡导“构建不能规模化的东西，与构建能够规模化的东西”而闻名。[↩ 返回正文](#opening)

## 注释3

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

## 编者关系图

![两个并列区域分别说明发现要检验是否值得做、交付要检验能否可靠使用，中间双向箭头表示持续交换证据。](https://taste.fangs.cc/images/articles/build-to-learn-reading/cover.png)

## 图片出处

- 编者图｜格得原创关系示意。两种构建持续并行，交付后的真实使用也会带回新问题；不是原文插图或先后阶段图。 · [来源](https://taste.fangs.cc/articles/build-to-learn-reading/) · 格得为本篇原创绘制；未使用原站图片，可随本篇正文及封面展示。