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