有一个数字，在产品行业流传了将近二十年，没有人真正当回事，但所有人心里都知道它是真的：
九成的软件产品没能实现既定目标。
这不是哪家咨询公司编出来吓人的数字。
马蒂·卡根在《启示录》里用整本书解释这件事，他见过太多团队，聪明、努力、资金充裕，但结果一塌糊涂。
问题出在哪？不是执行力，不是团队不够聪明，不是市场不够大。
大多数产品失败，是因为在开发之前很久，方向就已经错了。
这本书 2008 年第一版，写的是硅谷顶级产品团队的方法论。
eBay、惠普、网景……卡根在这些公司工作过、观察过，然后把他认为最关键的东西写了下来。
豆瓣上这本书有将近五千条评论，是产品经理书单里几乎永远排在第一位的那本。
但我想说一件事：这本书读起来很顺，很多地方让你觉得"对对对，就是这样"，然后合上书，第二天继续写 PRD，继续串行交接，继续开评审会。
读完没有任何改变，是因为你以为自己理解了，其实只是点了点头。
这篇文章试图做一件事：把这本书里真正有价值的东西，逐一拆开来说清楚。
很多人入行做产品，做了两三年，说不清产品经理的核心职责是什么。
这不是他们的问题，是整个行业的问题，大多数公司对这个岗位的定义本来就是模糊的。
卡根给出了一个非常清晰的答案，只有两项：
评估产品机会，定义要开发的产品。
听起来简单，展开来说，这两件事里藏着很深的东西。
评估产品机会，意思是当一个产品创意出现在你面前，你要判断它值不值得做。
创意的来源很多，高管说"我们来做个这个功能"，销售说"客户有个需求你们得满足"，竞品上线了某个东西你们没有，用户在反馈里提了很多次某个诉求……面对这些来自四面八方的声音，产品经理的职责是过滤，是评估，是判断哪些值得做、哪些不值得做，而不是照单全收。
定义要开发的产品，意思是在决定要做某个东西之后，你要告诉团队做什么，但不是怎么做。
你要确定产品的价值、体验、发布标准，但技术方案是工程师的事，视觉设计是设计师的事，产品经理的职责是把"做什么"想清楚，留出空间让其他人发挥。
这两件事，加在一起，就是卡根所说的"产品探索"的核心。
但问题是，大多数公司的产品经理，花大量时间做的不是这两件事。
他们在盯进度，在写用户故事，在协调会议，在解答开发人员的各种问题，在跑上跑下确认需求，在处理各种来自不同部门的打断。
真正花在"评估机会"和"定义产品"上的时间，可能只有 20%，甚至更少。
这不是个人效率问题，是岗位设计问题。
很多公司根本没有给产品经理留出做这两件事的时间和空间。
卡根还提到一个很多人没意识到的边界问题：产品经理不是项目经理，也不是产品营销经理。
这三个角色在中文互联网语境里经常被混用，但它们是完全不同的职能。
项目经理的核心任务是制订计划、跟踪进度、确保按时交付。
他关心的是"这件事能不能按时做完"，不是"这件事值不值得做"。
产品营销经理的核心任务是对外发布信息、培训销售队伍、定价、命名、推广。
他关心的是"怎么让市场知道这个产品"，不是"这个产品应该是什么"。
这三个角色分开来说都很清晰，但在实际公司里，常常被一个人兼任，或者职责边界模糊到没有人去认真追究。
结果就是，产品经理做了很多项目管理和营销配合的事，真正的产品定义工作没有人在认真做。
卡根的观点是：如果没有人在认真评估机会和定义产品，那么做得再好的项目管理和产品营销，也只是在高效地把一个错误的产品推向市场。
知道了产品经理的核心职责，下一个问题就来了：怎么评估机会？
卡根给了一个具体的框架，叫机会评估（Opportunity Assessment）。
他建议用几个关键问题来完成这个评估：
这个产品要解决什么问题？
它解决的是谁的问题？
成功的判断标准是什么？
有没有更好的替代方案已经存在？
为什么现在是做这件事的时机？
公司为什么是做这件事的合适主体？
这几个问题，读起来很基础，但真正逐一认真回答，会发现大多数产品创意在第二三个问题上就站不住脚了。
卡根强调，机会评估有一条铁律：只讨论待解决的问题，绝对不讨论解决方案。
这条规则背后有深意。
很多团队的会议是这样开的：有人提了一个创意，十分钟后，所有人已经在讨论怎么实现这个创意了。没有人追问这个问题本身是否成立，没有人质疑目标用户是否真实，没有人问成功的标准是什么。
把解决方案当成问题本身，是产品团队最常犯的错误之一。
一旦团队开始讨论"我们怎么做这个功能"，就很难再退回去讨论"我们是否应该做这件事"。
因为具体的方案会让人产生投入感，方案讨论得越深入，放弃的心理代价越大。
机会评估阶段就应该严格只讨论问题，把方案的讨论完全锁在门外。
还有一个微妙的地方：机会评估不是一个可以独自完成的工作。
它需要产品经理真正去接触用户、接触市场，而不是坐在办公室里想象用户会怎么想。
卡根后来在第二版里更加强调这一点，好的产品探索，必须建立在持续的用户接触上，而不是季度一次的用研报告。
豆瓣上一条高赞书评说得很直接：这本书最大的价值，是给了产品经理一个"拒绝权"，让你有足够的理论支撑去说"这个创意不值得做"。
有了"机会评估"这个框架，可以说"我们还没完成机会评估，先不进入方案"。
就成了一个可以在会议室里讲出来的句子。
说到这里，必须谈产品行业里一个几乎所有人都知道是问题、但所有公司都还在用的东西：产品需求文档（简称 PRD）。
PRD 是什么？
就是用文字、流程图、静态截图来描述一个产品应该是什么样子的文件。
几十页，甚至上百页，详细描述每一个功能点、每一个状态、每一个边界条件。
PRD 本身不是坏东西，它的问题在于被用来做一件它根本做不了的事：验证产品是否真的有用。
你能用文字写清楚"点击这个按钮之后会出现一个弹窗，弹窗里有两个选项"，但你没办法用文字描述"用户看到这个弹窗之后会不会困惑，会不会点错，会不会直接关掉"。
动态的用户体验，文字描述不了。
更大的问题是：PRD 无法用于真实用户测试。
你没办法把一份 Word 文档递给用户说"你来试试这个产品"，用户无法在文档上操作，你也看不到他们的真实反应。
这就导致了一种普遍的悲剧模式：团队花了三个月，按照 PRD 把产品开发出来，然后上线，才发现用户根本不知道某个核心功能怎么用，或者某个关键流程因为步骤太多用户直接放弃了。
此时想改，整个架构已经定型，牵一发动全身，代价极高。
卡根把这叫做"非常昂贵的原型"，你花了三个月时间和大量资金，最终只是验证了一个假设，这是对开发资源最大的浪费。
他的解决方案，是用高保真原型替代 PRD。
高保真原型是什么？
是可以点击、可以跳转、可以体验完整核心流程的交互稿，它不是最终产品，但它足够逼真，足以让用户在上面完成真实的操作，足以让工程师判断技术可行性，足以让整个团队看到他们在做什么。
在写第一行正式代码之前，先把高保真原型做出来，然后用它回答三个问题：
用户会不会用这个产品？用户喜不喜欢这个产品？工程师在现有技术条件下能不能做出来？
三个问题都有明确答案了，再进入开发阶段。
这个顺序的改变，让所有的验证发生在代码之前，而不是在发布之后。
代价从三个月的开发资源降低到一两周的原型制作时间。
今天这个方案的执行成本比 2008 年低了一个数量级。
用 Figma 做高保真原型，一个设计师一周可以完成几乎任何复杂度的核心流程。
用 Lovable 或 v0 直接生成可交互的前端 Demo，可能只需要几小时。"做原型来不及"这个说法从今以后站不住脚。
说到高保真原型，一个紧接着的问题是：怎么用它做用户测试？测多少用户？问什么问题？
卡根推荐的方法，是"走廊测试"——不需要正式的用研实验室，不需要招募大量被试，就在走廊里或者咖啡馆里，找到目标用户，把原型放在他们面前，看他们怎么用。
尼尔森诺曼集团有一个著名的研究结论：找 5 个用户做可用性测试，能发现 85% 的可用性问题。
找更多用户，发现的新问题边际递减。
也就是说，用 5 个真实用户测试一个原型，成本低，但收获的信息已经足够。
做用户测试，有几个容易犯的错误：
第一个是告诉用户怎么操作。
用户拿到原型不知道怎么用，很多产品经理忍不住说"这里你可以点一下"。
一旦你开口提示，测试就失效了，你测的是有人提示后用户会不会用，不是用户会不会自然地找到这个功能。
第二个是问"你觉得这个设计好不好"。
这种问题得到的答案没有价值，因为用户不擅长评价设计，他们会说"还不错"，但他们可能在操作中完全走错了方向。
正确的方式是给用户一个任务："假设你要完成 XX，你会怎么做？"然后观察，不要打断。
第三个是只找技术爱好者做测试。
技术爱好者愿意尝试新东西，对产品不成熟有更高的容忍度，他们能帮你发现很多 Bug 和可用性问题，但他们的使用行为不代表主流用户。
判断产品有没有真实市场，必须找那些被具体痛点折磨、正在主动寻找解决方案的普通用户。
第四个是测试完发现了问题却不改。
用户测试的价值在于发现问题，发现问题之后修改原型，然后再测，这个循环必须转起来。
很多团队做了用户测试，然后把报告放在文件夹里，继续按原来的方向开发，测试形同虚设。
卡根特别提到了一种用户类型：特约用户。
这是一批被你明确招募进来、愿意提前参与原型测试的目标用户，大概 6 到 15 个。
他们不是付费用户，而是合作伙伴，你把最早期的想法和原型给他们，他们给你真实反馈。
这样的关系比随机找用户测试深度大得多，而且他们往往在产品正式上线后会成为第一批真正的口碑传播者，因为他们亲历了产品从粗糙到成型的过程，有一种参与感和认同感。
在可行性验证这一端，卡根主张在原型阶段就把架构师或主程序员拉进来。
产品经理常犯的错误是完成了原型，直接扔给开发团队，认为可行性是开发的事。
但如果某个功能在技术上根本行不通，越晚发现代价越高。
最好的时机是原型阶段，此时改动成本最低。
工程师看了原型，可以直接指出"这里响应速度会不够"，"这个功能需要第三方 API，存在合规风险"，产品团队可以立刻调整方向。
说完了产品探索本身，来说说谁来做这件事。
传统的产品开发流程是串行的：产品经理写完需求，扔给设计师，设计师出完图，扔给工程师，工程师写完代码，扔给测试，测试完发布。
每个环节是独立的，交接像接力赛。
这个模式的问题，不只是效率低，而是它把三个本来应该相互依存的角色，变成了三道独立的工序。
卡根的主张是，产品经理、交互设计师、软件架构师（或主程序员），这三个角色，应该从一开始就紧密协作，互相渗透。
他称这三人组合为"产品铁三角"。
为什么设计师必须在早期就参与？
因为产品的交互方式会直接影响产品能解决什么问题，以及用户体验的质量。
如果产品经理先把功能需求定死，设计师只是在这个框架里填图，很多好的设计可能性就被排除了。
设计师早期参与，他们能提出一些产品经理没有想到的交互方案，有时候这些方案可以让同样的功能变得更直觉，更容易上手。
为什么工程师必须在早期就参与？
因为可行性不是最后才考虑的问题。设计师做了一个很漂亮的交互，产品经理很兴奋，进入开发才发现实现这个交互需要额外两个月，或者性能上根本跑不起来。
工程师在原型阶段就介入，可以在成本最低的时候给出可行性判断，帮团队避开这些雷区。
三角共创的具体运作是什么样的？
不是每周开一次碰头会，而是持续的、非正式的密集协作。
设计师在探索交互方案的时候，随时可以找产品经理确认方向，可以找工程师问技术限制。
工程师写代码遇到理解不确定的地方，不是等到下次会议，而是直接走过去问产品或设计。
原型在持续迭代，三方都在看最新版本，都对现在的方向有共同理解。
Teresa Torres 在她的书《持续发现习惯》里，把这种协作方式叫"产品三角"，并且给出了更具体的描述：
产品三角里，产品经理是战略思考者，负责统合用户需求与商业目标；
设计师是体验设计者，负责打造用户理解和喜爱的方案；
工程师是技术实现者，了解什么在现阶段可行。
三者的分工不是流水线上的先后顺序，而是对同一件事的不同角度，必须同时在场。
高保真原型，在这种协作里扮演的角色是"共同语言"。
三个背景不同、思维方式不同的人，对着同一个看得见能点击的东西讨论，比对着文字理解彼此意思要高效得多。产品原型是三角共创的载体，没有原型的三角协作，效果大打折扣。
卡根还提到了一个关于节奏的建议：产品经理和设计师的工作进度，应该比开发团队领先一到两个迭代周期。
也就是说，当开发在做当前周期的功能时，产品和设计应该已经在探索下一个或下下一个迭代的方向了。
这样工程师拿到的永远是已经过测试和验证的方案，不需要在开发中等待决策。
说到这里，必须谈《启示录》里另一个被反复提及的概念：功能工厂（需避免）。
什么叫功能工厂？
就是一个团队把"持续输出功能"当成工作目标。路线图上永远有排不完的需求，团队永远在开发，产品越来越大，功能越来越多，但用户留存没有改善，核心商业指标没有上升，甚至因为产品太复杂，用户越来越难用。
这个模式普遍到令人沮丧。
功能工厂是怎么形成的？
一是管理层对"进度"的焦虑。
产品开发有很强的不确定性，不确定让管理层不舒服，于是他们用"我们这周上线了什么"来代替"我们解决了什么问题"作为进度指标。
每周都要有功能上线，团队自然变成了功能生产线。
另外是客户和销售的压力。
客户说"你们如果有 XX 功能我就续费"，销售说"竞品有这个你们没有"，这些声音在短期内都指向一个方向：加功能。
但每次妥协，团队就离真正的通用产品方向更远一步。
最后一个是产品经理自己的问题。
有些产品经理对创造的热情高于对问题的专注，喜欢提新功能，喜欢看到自己的想法变成现实，但对功能上线之后用户是否真的在用、真的有价值，缺乏持续追踪的意愿。
功能工厂最危险的地方，是它看起来很像在努力工作。
团队很忙，每个人都在做事，每周都有发布，路线图上每个季度都在推进。
但如果你去看真正重要的指标，比如周活跃用户数、30 天留存率、核心流程完成率，这些数字没有在动。
卡根给出的解法，是把注意力从"我们做了什么"转移到"我们解决了什么问题"。
路线图不应该是功能列表，而是要解决的问题清单。
每个项目的成功标准，应该在开始之前就定义清楚，而不是上线之后回头解释。
具体操作上，卡根建议用数据找到用户流失的关键节点，比如注册流程有五个步骤，发现大量用户在第三步放弃了，那么下一个迭代的重点就是优化第三步，而不是加新功能。
这种聚焦，和功能工厂的思维完全不同。
在 AI 时代，功能工厂陷阱升级了。
当 AI 工具能帮你在两小时内实现一个新功能，"加一个新功能"的门槛更低，诱惑更大，团队更容易陷入"高产出、低价值"的循环。
Nikhyl Singhal，曾任 Meta 和 Google 产品领导者，有一个观察放在这里很准确：AI 让项目的前 10% 几乎免费，探索、原型、生成备选方案都变容易了，但最后 10% 的精致度、稳定性和规模化依然一样难。
这意味着现在最危险的处境，不是团队做不到，而是团队做了太多没必要做的事。
《启示录》里有一章我认为每个产品从业者都应该背下来，就是卡根列出的那些会系统性扼杀创新的组织模式。
这些模式不是某一家公司才有的问题，而是在绝大多数公司里以不同形式出现的通病。
第一种：依赖冗长 PRD，把文档当成产品定义的主要工具。
上一节已经说过 PRD 的问题。
在这里补充一点：冗长的 PRD 还有一个副作用，就是它制造了一种"工作已经完成"的错觉。
当一份 50 页的文档写完，所有人都会觉得"我们想清楚了"，但这份文档从来没有被真实用户验证过，从来没有被工程师认真评估过可行性，只是思考的产物被打印了下来。
第二种：妥协于大客户的"特例产品"需求。
这是一个非常经典的陷阱，尤其在早期阶段。
销售带来一个大客户，对方愿意付一笔不错的钱，但条件是产品必须增加某些他们特定的功能。
管理层一看，钱到手的机会，说干就干。
这样的事发生一次，两次，慢慢地，产品里有越来越多只服务少数特定客户的功能，这些功能被合同锁死，每次版本迭代都要做兼容测试，代码越来越复杂，维护成本越来越高。
同时，用于大众市场的通用功能探索越来越少，因为团队的资源被这些特例需求占据了。
卡根说，这条路的终点，是把自己变成一家定制软件公司，失去了做通用产品的能力。
第三种：把产品管理部门归属于开发部或市场部。
产品管理放在开发部下面，产品经理很容易被技术细节和执行要求淹没，没有时间和空间做真正的市场探索和机会评估。
产品管理放在市场部下面，产品管理和产品营销会被混淆，产品经理花大量时间做对外宣传相关的事，产品的核心定义工作被忽视。
卡根的建议是，产品管理应该是一个独立的职能部门，和开发部、市场部平级，直接向高层汇报。
这在组织架构上给了产品探索应有的地位和资源。
第四种：瀑布式串行开发，设计后置。
产品先写完所有需求，再把设计工作开始，设计完了再开始开发。每个阶段结束，交接，进入下一阶段。
这种模式的问题上面已经讲过：设计介入太晚，一旦进入开发，修改设计的成本极高；工程师只能被动接受，无法在早期影响产品方向；整个流程缺乏验证环节，错误会一直传到发布才被发现。
第五种：闭门造车，没有真实用户验证的"产品发现"。
这个模式比功能工厂更隐蔽，也更危险。
团队并不是不做产品发现，他们也在讨论用户，也在分析数据，也在做内部评审——但所有这些都是在团队内部完成的，没有真实用户参与。
等到产品做出来了，才去测试，才去收集用户反馈。
此时如果发现大问题，已经太晚，产品的基础架构已经固定，根本性的改变不可能了。
第六种：把产品管理等同于项目管理。
没有专职的产品经理，由项目经理兼任产品职责，或者反过来，产品经理花大量时间做项目管理的事。
项目管理的核心是确保按计划交付，产品管理的核心是确保做了正确的事。
这是两种完全不同的思维方式，长期混淆会让团队变成一个"按时交付错误产品"的机器。
第七种：一味追加功能的"功能工厂"心态。
上一节已经详细说过，不再重复，但值得在这里强调：这是一个可以摧毁好产品的慢性病，危险在于它的破坏性是隐性的，你会在功能越做越多的过程中感觉良好，但核心指标在缓慢下降。
这七种模式，在不同的公司里有不同的组合。
有些公司同时中了三四种，有些公司只有一两种，但任何一种单独存在，都足以让一个有才华的团队做出一个让用户失望的产品。
卡根在《启示录》之后，又写了一本书叫《赋能》，这两本书合在一起，构成了他完整的产品哲学。
《赋能》里引入了一个在他看来是产品工作核心矛盾的概念：功能团队和授权团队的区别。
功能团队是什么样的？
团队的工作来自路线图，路线图来自管理层或销售，团队的任务是把路线图上的功能做出来，做得又快又好。
他们被"交付的是功能"，问题是，交付的功能是不是真的解决了用户的问题，团队不负责回答这个问题。
授权团队是什么样的？
团队被"交付的是问题"。
管理层告诉团队，我们想提高三个月用户留存，但怎么提高，由团队来探索和决定。
团队对问题的解决方案有自主权，他们需要用自己的判断去探索最好的方案，而不是等待上级给出功能清单。
卡根认为，大多数公司是功能团队，但真正做出优秀产品的公司，是授权团队。
Amazon、Netflix、Stripe，这些公司的产品团队拿到的是目标，而不是功能列表。
他们对自己负责的业务区域有深度理解，有足够的自主权去探索解决方案，也需要对结果负责，而不是只对交付负责。
这个转变的难点在于管理层。
功能团队的存在，很大程度上是因为管理层不相信团队有足够的判断力，所以用功能清单来控制方向。
要转向授权团队，需要管理层在"确定性"和"自主权"之间做一个艰难的取舍。
卡根给产品评审委员会（Product Council）的设计，正是为了解决这个矛盾。
他建议大公司由关键部门高管组成产品评审委员会，人数控制在十人以内，只在四个关键节点做决策：评估机会是否值得投入，批准进入原型阶段，批准进入正式开发，批准发布。
这四个节点之间，产品团队有完全的自主权，管理层不介入具体方案。
这样既保证了管理层对方向的掌控感，又给了团队应有的探索空间。
说了这么多书里正确的东西，现在来说说它的问题。
这是《启示录》值得真正研究的地方：即使是一本好书，也有它的时代局限，读者有责任自己分辨。
第一个局限：书里的成功案例，几乎全来自美国大公司。
eBay、惠普、网景，这些公司的产品模式，是在特定的资源禀赋、市场环境和组织文化下形成的。
把这套方法论直接搬到一家资源有限的早期创业公司，或者搬到组织文化完全不同的中国互联网公司，需要大量的本土化翻译，而书里没有给出这个翻译的框架。
Reddit 上有一个很有意思的讨论，有人问"谁真的读过《启示录》"，高赞回复说：这本书讲的是产品经理"应该"怎么做，但现实生活远比理想复杂，产品管理是一个很模糊的工作，在大多数公司里，推动改变比学方法论难得多。
这个批评是准确的。
书里描述的是一个理想状态，真正的挑战是在一个不理想的组织里，怎么逐步往这个方向推。
第二个局限：对用户研究的深度不够，缺少可操作的节奏框架。
卡根强调要做产品探索，要做原型测试，要接触真实用户，这些方向都是对的。
但书里缺少一个具体的、可以每周执行的用户研究系统。
什么时候做用户访谈？怎么找用户？访谈用什么结构？结果怎么转化为产品决策？
这些操作层面的问题，在 2008 年的版本里几乎没有答案。
Teresa Torres 后来专门写了《持续发现习惯》来填补这个缺口，后面会详细说。
第三个局限：对 AI 时代的产品特殊性完全没有覆盖。
2008 年的产品，功能边界是清晰的，用户体验是可预测的，系统行为是确定的。
AI 产品不是这样：大模型的输出是概率性的，存在幻觉，响应延迟不可控，调用成本会随用户规模急剧上升。
这些特性，完全改变了可行性评估的内容，也改变了用户测试的方法。
卡根在 2025 年的采访和写作里，开始谈 AI 对产品团队的影响，但核心书籍还没有完全覆盖这个维度，需要读者自行补充。
第四个局限：对中国本土市场的特殊性无能为力。
中国互联网产品有很多在硅谷语境下不存在的约束：监管合规要求、流量获取逻辑、用户行为差异、微信生态的特殊性。
书里的很多建议，在这些背景下需要重新判断是否适用。
上面讲了书里没有的东西，现在来说 AI 时代的产品团队具体要补什么。
第一个：可行性评估必须升级为"算力经济学评估"。
传统软件的可行性问题是：这个功能技术上能不能实现？对于确定性系统，这个问题通常有清晰的答案。
AI 产品要多问一些问题：
大模型的响应延迟是多少？主流用户能接受等 3 秒吗？如果某个核心功能需要 5 秒以上，用户流失会有多严重？
这个应用场景的幻觉率是多少？如果大模型有 5% 的概率给出明显错误的输出，对这个应用来说是可接受的边界误差，还是会摧毁用户信任的灾难？
每次 API 调用的成本是多少？乘以预期的用户规模和使用频率，商业模型能不能跑通？
合规风险在哪里？内容安全、数据隐私、各垂直行业的监管要求，是否已经在产品设计阶段就考虑进去？
这几个个问题，在原型阶段就要拉入主程序员认真评估，而不是留到开发完成再发现问题。
第二个：用技术爱好者测 Bug，用真实用户测价值。
卡根对技术爱好者的警惕，在成熟市场是准确的。
但中国 AI 早期，情况有所不同。
技术爱好者的价值在于：他们愿意忍受产品的不成熟，有能力理解新技术的运作原理，能提出有深度的 Bug 报告，是早期阶段最高效的产品测试者。
你完全可以把他们当做"高级测试团队"来用。
但判断产品有没有真实市场，必须去找那些被具体痛点折磨、已经在主动搜索解决方案的普通用户。
他们不关心底层技术是大模型还是规则引擎，他们只关心自己的问题有没有被解决。
这两类用户的反馈，要分开处理，分开权重，不能混在一起评估。
第三个：AI 创业的极简起步阵型。
卡根在书里提到，创业公司初期最高效的配置是三人组合：产品经理、交互设计师、原型工程师，专注于产品探索，方向验证清楚再扩张团队。
这个建议在 2025 年的 AI 创业环境里更加有力。
一个会用大模型的工程师，可以在几小时内搭出一个功能级 Demo，一个懂 AI 产品的设计师可以快速迭代原型，三个人可以在一两个月内完成从想法到"有人真的愿意用并且愿意付费"的完整验证。
很多 AI 创业团队在验证阶段就招了十几个工程师，大量开发资源投入进去，结果发现方向不对，代价极高。
资源越有限，越需要在投入大规模开发之前，用最低的成本把方向验证清楚。
卡根的书给出了"应该做什么"，Teresa Torres 的《持续发现习惯》给出了"每周怎么做"。
这两本书是最好的配套，一个讲方向，一个讲系统。
Torres 的核心主张是：产品发现不应该是某个阶段的特定项目，而应该是持续的、固定节奏的日常习惯。
她给出的最小可行发现节奏是：每周至少做一次真实用户访谈。不是季度一次的大型用研项目，不是在重大节点前临时找几个用户，而是每周一次，持续进行，不中断。
为什么每周一次这么重要？
因为产品决策需要不断的信号更新。用户的反馈在变，市场在变，你对问题的理解也在随着每次访谈深化。
如果信号更新的频率太低，就会出现一种常见的问题：团队对用户的认知停留在三个月前的那次用研里，但用户早就不一样了，产品也走偏了方向。
Torres 引入了一个工具，叫"机会解决方案树"。
它的结构是这样的：
最顶层是你想达到的业务目标，比如提高 30 天留存；
中间一层是你从用户访谈里发现的机会，比如"用户觉得新功能上手太难"，"用户找不到某个关键功能的入口"；
最底层是针对每个机会的具体解决方案，比如优化新手引导，重新设计导航结构。
这棵树的价值，是把用户洞察、产品机会和解决方案之间的关系可视化。
它能帮团队看清楚：我们正在探索的解决方案，对应的是哪个用户机会？如果这个解决方案做出来了，它能解决的机会是不是足够重要？有没有更好的解决方案可以解决同样的机会？
对于 AI 产品团队，持续发现系统的价值更加突出。
大模型能力在快速迭代，用户对 AI 功能的预期也在快速变化，今天用户觉得 AI 能做这件事是令人惊喜的，三个月后可能变成理所应当的基础能力。
如果没有持续更新的用户信号，就很难判断什么时候应该投入资源去升级某个 AI 能力，什么时候应该转移注意力去解决其他问题。
Torres 还有一个观点值得在这里单独说：发现工作的质量，直接取决于产品三角里每个人参与的深度。
如果产品经理自己做访谈，不让设计师和工程师参与，这样收集到的信号经过了一次转述，信息密度和准确度都会下降。
最好的方式是产品三角一起做访谈，三个人看同样的用户，听同样的故事，各自带着自己的专业视角来理解，讨论时会更有深度。
读完《启示录》，一个很自然的问题是：知道了这些，我要怎么做？
先说入门阶段。
很多人做产品的第一年，主要工作是学会写需求，学会用 Axure 或 Figma 做原型，学会和开发、设计沟通，学会在评审会上讲清楚功能逻辑。
这些是基础技能，是必要的但不是充分的。
《启示录》里有一个建议，适合入门阶段的产品经理：找机会做用户访谈。不是等到公司安排，而是自己主动去找。
每周找一个真实用户聊 30 分钟，问他们在使用你负责的产品时遇到的最大困惑是什么，最常做的操作是什么，什么情况下他们会停下来不知道该怎么做。
这一步会改变一个新产品经理的思维方式：从"我觉得用户会这样用"变成"我知道用户是这样用的"。
这个转变，是从初级到中级最关键的一步。
中级阶段，产品经理面对的主要挑战，是开始要负责产品方向，而不只是执行别人的方向。
这时候机会评估的能力变得关键，你需要学会在大量输入中识别真正重要的信号，需要学会说"这件事我们不做，因为它不符合核心目标"，需要建立自己的优先级判断框架。
高级产品经理面对的主要挑战，是影响组织。
《启示录》里关于组织设计的那些建议，主要是给高级产品人和管理层看的：怎么建立独立的产品职能，怎么推动从功能团队向授权团队的转变，怎么建立有效的产品评审机制，怎么创造让创新发生的组织环境。
在这个阶段，理解书里的组织批判部分，比理解产品探索方法论更重要。
因为你自己的判断力可能已经够了，真正的障碍是系统性的组织问题。
说了这么多，最后说说这本书和其他书怎么组合在一起读。
第一本：《启示录》，作为基础框架
读这本书，不要读得太快，要带着问题读：我们公司现在的流程是什么样的？和书里的建议有哪些差距？差距的根源在哪里？
不要只是点头说"对对对"，要具体问：我们上一个失败的产品，在哪个环节犯了书里描述的哪种错误？
把书当防御手册来用，比当教科书来用收益更大。
第二本：《精益创业》，作为节奏框架
《精益创业》和《启示录》是互补的。
卡根告诉你产品探索为什么重要，精益创业告诉你探索的节奏应该有多快。
精益创业的核心是"构建-测量-学习"的循环：快速构建最小可行产品，快速测量关键指标，快速从结果里学到东西，然后决定是继续还是转向。
这个循环的速度，是精益方法的核心竞争力。
两本书合在一起，会让你对"产品探索应该长什么样"有更立体的理解：它是一个以周为单位的持续循环，不是一个季度启动一次的阶段性项目。
第三本：《持续发现习惯》，作为操作系统
前两本书都在讲方向，Teresa Torres 这本书给出操作系统。
具体内容已经在前面讲过了，这里补充一个读书建议：不要只是把这本书读完，要在读的过程中，设计出你自己的最小可行发现节奏。
你每周可以做一次用户访谈吗？如果一次不行，两周一次呢？
你的产品三角现在存在吗？如果不存在，可以从哪里开始建立？
你有机会解决方案树吗？如果没有，可以用一张白纸先画出来试试吗？
把书里的框架转化成你可以下周就开始做的事，才算真正读完了这本书。
读完这三本书之后，你会拥有一套产品工作的词汇表。
这件事听起来平凡，但它的价值被严重低估。
当你能说"我们现在正在做机会评估，这个阶段不讨论解决方案"，会议室里的讨论就会被重定向。
当你能说"这个需求属于特例产品，接了会把我们带离通用市场"，你就有了一个可以在会议上说出来的理由，而不只是内心的迟疑。
当你能说"我们的团队模式更接近功能团队，但我们希望往授权团队方向转变"，组织讨论就有了一个可以锚定的方向。
名词是权力。
你有了准确的词汇，就可以精确地描述问题，精确地描述问题，才有可能推动有意义的改变。
有一件事值得说一下：《启示录》在中国产品从业者里的名声非常响，豆瓣八点几分，书单必推，很多产品面试会直接问"你读过《启示录》吗"。
但真正读进去、读出东西的人，远比声称读过的人少。
这不是批评，是一个观察。
这本书不是很难读，但它的很多观点和我们工作中习以为常的方式是相反的，所以"读进去"需要一种特别的意愿：允许自己被说服，允许承认自己公司的流程有根本性的问题。
最后一件事：
有人在 Reddit 上问，这本书在现实工作里真的有用吗？高赞回复是这么说的：
"书里讲的很多东西，在大多数公司里你根本推不动，因为组织阻力太大。但这本书最大的价值，不是给你一套马上能用的操作手册，而是让你知道问题在哪里，知道更好的方式是什么。当你知道了这些，你会对公司里的坏模式更加敏感，更有意愿去推动改变，哪怕只是一点点。"
这个回复，我觉得是对这本书最诚实的评价。
读完《启示录》，你未必能立刻改变你的公司，但你会开始清楚地看到，问题出在哪里，更好的方式是什么，以及下一步你可以做什么。
这已经足够。