# 序言
LLMS 索引： [llms.txt](/llms.txt)
---
北方海獭（比如本书封面上的那只）很像软件工程师，只是更可爱。它们会使用工具，主要是用石头敲开贝壳。它们也会协作，会结成由许多个体组成的巨大“筏群”，彼此抓住前爪，这样既能漂浮在水面上，也不至于被水流冲散。
海獭也是*边界态*（*liminal*）生物：它们漂浮在空气与海洋的交界处，不完全属于任何一边。这些海洋哺乳动物必须从空气中获取氧气，但食物来自海里。它们有类似陆生哺乳动物的爪子，却又靠鳍肢适应海洋环境。
工程师同样是边界态生物，只不过我们栖身于系统与用户的边界空间。软件世界里的数据库、协议、调用栈和容器，就像大海；当我们向更深处潜去，最终落脚在承载这一切的硬件之上。
但用户是我们的氧气，也是我们头顶那片阳光普照的天空。借着他们的光，我们才能看得更远；而要做到这一点，我们必须始终保持“漂浮”。
### 为什么写这本书 {#id1}
围绕软件产品的思考，归根结底可分为两类：
- **系统思维**：关注算法与数据结构、编程语言、分布式系统的容错、固件的内存约束等议题。
- **产品思维**：关注对用户的理解，包括其背景知识与需求、行为序列、群体互动，以及服务于这些目标的设计方法与信息架构。
软件工程教育大多围绕系统思维展开。大学计算机课程、编程训练营和软件工程文献，重点都在算法、数据结构、编程语言、系统知识与设计模式上。除了偶尔能遇到的人机交互选修课之外，我们大多只能靠耳濡目染，慢慢学会产品设计，也慢慢学会理解用户。为什么会这样？
的确，系统思维是我们最具区分度的能力，产品经理、设计师和用户体验研究员通常不具备这项能力。但你若去问他们，他们往往会说，希望工程师拥有更多产品能力。他们要同时覆盖很多产品，沟通与对齐都很有挑战。与其试图解读一份由 PM 匆忙勾勒、又没覆盖任何边界场景的需求文档，不如基于我们对用户的深度理解来决策，这样我们对产品命运的掌控会更强。
在软件工程还是“前沿学科”的年代，有些人即便缺乏产品能力也能过关。哪怕是基础技能，也需要超常的天赋、韧性与投入才能掌握。那时真正会高效编码的人太少，最紧迫的任务是培养整整一代程序员与软件设计者。工具和语言本身又很难用，光是学会并用好它们就足以成为一份全职工作。
但现在不同了。过去二十年里，在开源生态、云计算和开发者工具公司资本投入的推动下，开发技术发生了巨大进步。AI 编码助手与智能体已经替我们承担了大量繁重工作，处理掉许多细枝末节，让我们能把注意力放到别的议题上，比如产品思维。
写这本书，是为了补足你既有教育中的空白：把你已经具备的工程能力，与用户同理心和产品能力融合起来。比如，我们在这里不会教你设计数据结构或算法，但我们会讨论如何依据用户需求来选择它们。
掌握这些能力后，你可以在工程岗位上做得更好：
- 基于影响力更好地确定优先级。
- 与产品经理和设计师更高效协作。
- 做出信息更充分的工程设计决策。
- 把队友视为你所写抽象的用户，从而写出更有用、也更易维护的代码。
- 在多数日子里，都能带着服务产品用户的热情醒来。
或者，你也可以在那些要求“产品+工程”复合能力的岗位上进一步升级：
- 成为产品/工程复合型人才，既参与产品决策也推动落地，在工程目标与产品目标之间做出纯工程或纯产品角色难以做到的协同优化。
- 以具备产品感的技术创始人身份创业，更从容地应对初创公司面临的多元挑战。
- 成为或进一步成长为技术负责人，以用户结果为依据，用扎实的推理带领团队。
### 本书适合谁 {#id180}
本书面向各类职业软件工程师：你已经掌握了编写与交付代码的基本功，但渴望持续做出更大影响。无论你刚入行一年，还是资深工程师，这些主题都能给你启发。你在这里学到的用户导向能力，同样适用于服务同事、开源社区成员和付费客户；不论用户是普通消费者、专业人士，还是其他开发者。
我纳入了多种类型的例子，从用户界面到开发者平台再到基础设施；在我看来，它们都是产品。即便是一个不起眼的函数，也可以被视作微型产品：它通过接口与用户沟通，并满足用户需求。
是的，基础设施工程师也在构建产品；只不过他们最直接的目标用户通常是其他工程师，以及这些工程师所服务的终端用户。更具挑战的是，基础设施团队往往缺少产品经理和设计师，反而使某些产品能力（比如用例意识）对成功变得更关键。
### 本书结构 {#id271}
[第 1 章](/ch1/#ch01_foundations_prod)包含导论内容，是阅读后续章节的前置基础。
之后你可以按兴趣或时机，以任意顺序阅读其余章节。不过，如果你没有特别偏好，我已按我建议的次序排列。
这八章被划分为四个部分，对应软件产品生命周期“**双钻模型**”的不同阶段。这里先简要岔开说明一下。
#### 双钻流程模型 {#id2}
这本书并不是一本讲软件流程的书，我也不会试图向你兜售某种流程。但理解双钻流程模型会帮助你更顺畅地阅读本书；如果你和我一样，它还会拓展你对“打造优秀软件究竟需要什么”的理解。
许多有效的软件生命周期实践，都可以归纳为四个基本阶段：
- **探索（Discover）**：明确我们服务谁、他们需要解决什么问题。这个阶段强调调研、创造力与探索。
- **定义（Define）**：构思并架构一个能解决这些问题的产品。这个阶段强调收敛选项，形成聚焦计划。
- **开发（Develop）**：选择并细化实现方案。在这个阶段，我们寻找最佳实现路径，并打磨先前定义的高层产品。
- **交付（Deliver）**：把产品做出来，验证你做出的结果，交付给客户，并收集反馈。
把这四个阶段连在一起，可视化后如[图 P-1](/preface/#double_diamond)所示。
**图 P-1.** 英国设计委员会对双钻流程模型的示意图
图中它们被表示为沿着两个菱形推进的箭头。在探索与开发阶段，箭头发散，因为我们会并行探索多条线索；而在定义与交付阶段，箭头收敛，因为我们会尝试把这些线索编织成一个紧凑的产品。
别误会我的意思：软件项目并不会沿着这些阶段整齐线性推进。当你深入到子功能层面时，循环会层层嵌套；你会学到新东西，也会回退重来，等等。
在创造与聚焦之间来回切换，本身就很有启发。如果你在推进交付时，常被同事提出创意想法“带偏”而感到挫败，也许只是你们所处阶段不同。反过来，如果你觉得有人总在压制你的好点子，也可能是同样原因。先花点时间确认你们是否在同一阶段，比如到底是在探索（Discovery）还是开发（Development）。
这个模型也帮助我们把视野扩展到完整产品生命周期：从问题被提出的那一刻，到产品发布并开始获取反馈。不要一上来就跳到解法，也别在功能首版上线后就以为万事大吉。
成熟的产品思维工程师，会在生命周期的全部四个阶段塑造产品命运。
#### 各部分内容 {#id3}
对工程师而言，产品思维无处不在。因此本书会贯穿这些阶段，展示如何在每个阶段运用产品思维，拿到更好的结果。
大体上，本书各部分覆盖了双钻的各阶段，不过起点放在了产品周期的中段。我们先从开发（Develop）与交付（Deliver）阶段开始，因为这是各层级工程师最常经历的部分。随后我会回到探索（Discover）和定义（Define）阶段，这些通常更偏向资深及以上角色的工作域。
当我们进入第三、第四部分，即探索与定义时，尽管这些决策常常发生在产品周期更早阶段，但它们会更具挑战，也需要更多上下文。不过，如果你更愿意按阶段顺序阅读，也完全可以；只是要知道，你会先接触更有挑战的内容。
#### 各章概览 {#id4}
- [第 1 章](/ch1/#ch01_foundations_prod)会介绍“人物画像（persona）”与“场景（scenario）”这两个核心概念，它们会在全书反复出现，并补充一些用户心理学基础。
[第一部分：“开发”](/part-i/#part1)
- [第 2 章《引导用户使用你的产品》](/ch2/#ch02_naming)聚焦于具备沟通性、直觉性的产品界面。你将通过有效命名与层级设计的渐进呈现，帮助用户发现、理解并使用你的产品。
- 在[第 3 章《错误与警告》](/ch3/#ch03_errors)中，你将学习如何编写可行动的错误信息，并如何设计代码架构，让错误可编程且真正有用。
[第二部分：“交付”](/part-ii/#part2)
- [第 4 章《亲自体验你的产品》](/ch4/#ch04_dogfooding)讨论内部试用（dogfooding）自己产品的高效方法，例如编写文档、场景测试和摩擦日志（friction log）。
- [第 5 章《持续倾听用户》](/ch5/#ch05_user_feedback)会教你“面向变化而设计”，并基于用户反馈与指标迭代走向成功。
[第三部分：“探索”](/part-iii/#part3)
- 在[第 6 章《理解你的目标受众》](/ch6/#ch06_target_aud)中，你会接触客户，理解他们在寻找什么，并把这种理解共享给整个团队。
- [第 7 章《通过模拟发现你的产品》](/ch7/#ch07_product_discovery_sim)会帮助你把用户场景转化为产品需求和优先级计划。
[第四部分：“定义”](/part-iv/#part4)
- 在[第 8 章《交互设计》](/ch8/#ch08_interaction_design)中，我们会深入功能设计细节，帮助你设计出“只用于预期用途、避免被用于不安全用途”的产品。
- [第 9 章《产品架构》](/ch9/#ch09_product_architecture)将产品思维应用到吞吐量、数据一致性、延迟等系统层面的关切。
### 阅读说明 {#id5}
在开始前，这里有几点说明：
- 本书包含代码清单。我选择 Python 作为示例语言，因为它既常见又相对易懂。我会在必要时解释你可能不熟悉的语法。
- 每一章都以发人深省的练习和这些练习的示例答案收尾。请务必动手做！产品思维需要练习。
- 我曾在 Microsoft、Facebook、Stripe 和 Temporal 工作。本书中的一些例子来自我在这些公司的经历，另一些来自我亲手参与的产品。我选择它们并非为这些公司背书，而是因为这种第一手经验让我能够提供一本产品思维书籍所需的细腻细节，并保证准确性。
- 我的职业生涯大部分时间都在为开发者构建产品。尽管本书覆盖的产品类型广得多，我也广泛征求了不同意见，力求让建议更具普适性，但内容仍可能会偏向那些更适合服务技术用户、而非消费者的技巧。
### 本书使用的约定 {#id272}
本书采用以下排版约定：
- ***斜体***：表示新术语、URL 和电子邮件地址。
- **`等宽字体`**：用于程序清单；也用于段落内指代程序元素，如变量名、函数名、数据库、数据类型、环境变量、语句和关键字。
> [!TIP]
> 此元素表示提示或建议。
> [!NOTE]
> 此元素表示一般说明。
> [!WARNING]
> 此元素表示警告或注意事项。
### O’Reilly 在线学习 {#id273}
> [!NOTE]
> 40 多年来，[*O’Reilly Media*](https://oreilly.com/) 一直提供技术与商业培训、知识和洞见，帮助企业获得成功。
我们独特的专家与创新者网络，会通过图书、文章和在线学习平台分享他们的知识与经验。O’Reilly 在线学习平台提供按需访问能力，涵盖实时培训课程、深度学习路径、交互式编码环境，以及来自 O’Reilly 与 200 多家其他出版商的大量图文与视频内容。更多信息请访问 [*https://oreilly.com*](https://oreilly.com/)。
### 联系我们 {#id274}
关于本书的意见与问题，请联系出版方：
- O’Reilly Media, Inc.
- 141 Stony Circle, Suite 195
- Santa Rosa, CA 95401
- 800-889-8969（美国或加拿大）
- 707-827-7019（国际或本地）
- 707-829-0104（传真）
- [*support@oreilly.com*](mailto:support@oreilly.com)
- [*https://oreilly.com/about/contact.html*](https://oreilly.com/about/contact.html)
我们为本书提供了网页，发布勘误和补充信息。你可以通过 [*https://oreil.ly/the-product-minded-engineer-1e*](https://oreil.ly/the-product-minded-engineer-1e) 访问。
如需获取图书与课程的新闻和信息，请访问 [*https://oreilly.com*](https://oreilly.com/)。
在 LinkedIn 关注我们：[*https://linkedin.com/company/oreilly-media*](https://linkedin.com/company/oreilly-media)
在 YouTube 观看我们：[*https://youtube.com/oreillymedia*](https://youtube.com/oreillymedia)
### 致谢 {#id275}
衷心感谢我的朋友和坚定的 alpha 读者 Carmen Krol 与 Peter Schuller。他们认真读完了早期粗稿的全部内容，并给出了极其出色的反馈。
我也特别感谢我的 beta 读者 Kimberly Hou、Scott Storkel 和 Chelsea Troy。他们完整通读了 beta 稿，并坦诚地给了我反馈。
还要感谢其他贡献者：Adam Hupp、Ben Lavender、Paul Nordstrom、Jason Rosenfeld、Jeff Schoner、Venkat Subramaniam 和 Mark Wong，你们都为本书带来了积极影响。
其他感谢：
- 感谢 Anthropic 打造了我的研究伙伴 Claude。这次对产品思维的快速梳理涵盖了很多主题，我在其中不少方面都需要知识补强。
- 感谢 Louise Corrigan 对我的信任，并建议我写这个很棒的主题。
- 感谢我耐心而博学的编辑 Angela Rufino。
- 感谢 Joshua Bloch、Don Norman 和 Steven Clarke，开启了我的产品思维之旅。
- 感谢 Charles Zedlewski，建议我在做了多年工程师后尝试产品管理。若没有这段经历，本书的某些部分很难写好。
- 感谢 Gergely Orosz 以及他那篇富有启发的博文 *The Product-Minded Software Engineer*。
- 感谢 Patrick Collison 在 O’Reilly 为我引荐，也感谢他打造了一家充满产品思维工程师的公司。
- 感谢 Peter Dimov，教会我拥抱自己作为产品思维工程师的使命。