《启示录 : 打造用户喜爱的产品》[美] Marty Cagan 2011

这本书要论证的核心命题：“市场上绝大多数软件产品无人问津，不是技术不行、不是执行不力，而是从’做什么’这一步就错了——好产品不是设计出来的，是’探索’出来的。”全书按”人员—流程—产品”三部分展开：人员部分讲产品团队怎么配——产品经理不是”程序员的经理”，而是”定义正确产品”的人（”产品经理负责定义正确的产品，开发团队负责正确地开发产品”），讲清楚产品经理与设计师、开发、上司的协作关系，以及”对上司要说方案而不是抱怨现状、要学会要资源”；流程部分是全书核心，给出”评估调研→定义设计→开发上线”三阶段产品开发流程：先评估产品机会（产品要解决什么问题、为谁解决、凭什么我们做）、物色至少六位目标用户组建特约小组、用高保真产品原型取代传统纸质文档（原型做完必须让真实用户验证）、上线时新旧版本并行/区域逐步部署；产品部分总结卓越产品的共性——”成功的产品往往是’新瓶装老酒'”，谷歌之于搜索、iPod之于MP3都是把老需求做得更好，而不是发明新需求。

我是被同行推荐读的——带我的前辈说”做产品先读这本”，于是我从《人人都是产品经理》直接跳到了这本书。说实话，第一次读我有点懵：它不像苏杰那本”手把手教你怎么做”，反而像一本”产品管理的世界观”——每章都短，但每章都像把一面墙推倒，让你看见墙后面更大的问题。书评人snailchenyijun（156赞）说得极准：”对于初入行者来说，可能过于宏大了些，很多篇章看过去没有什么感受，只能说道理上是不错的。”我第一遍就是这个感受。但隔了半年、自己真正带过一个功能从0到1之后，我再翻这本书，脊背一阵发凉——书里写的每一个坑，我都踩过。

让我最难受的，是”产品需求不能用户说了算”那条。我刚入行时特别爱做”需求搬运工”：客户说要个导出功能，我就排期做导出；老板说要个会员体系，我就设计会员体系——然后被改需求改到崩溃。书里说：你以为你在”满足需求”，其实你在”听写用户的想象”。真正的产品经理要往下一层挖：用户要”导出”，是因为他每周要花两小时手动整理报表——他要的是”别让我花这两小时”，导出只是他想到的一种解法。这让我想起《精益创业》里的”验证而不是假设”，也想起《人人都是产品经理》里”需求是伪命题、问题才是真命题”的说法。原来这几位大师说的是同一件事：别听用户说要什么，要看用户为什么想要。

“高保真原型代替纸质文档”这章，我读完直接改了团队的工作方式。以前我们开会讨论需求，靠的是几十页的PRD，开发看文档靠脑补，做完才发现理解全错。书里给的三步法我原样照搬：产品经理和设计师先做”只含基本功能”的高保真原型 → 请架构师评估成本、指出设计误区 → 拿原型给真实用户验证。第一次用这方法，开发看到原型的一瞬间说”哦，原来是这个意思”，那一周我们没吵过一次需求架——而这在以前是不可能的事。微信书评（苏冰清-安迪）把这段复述得极清楚：”二流的产品经理会说那就增加客服人手吧；一流的产品经理会想，是否可以改善客服系统的易用性，在降低成本的同时提高用户满意度。”这个例子我记了很久。

但我也要说实话：这本书不是没有缺点。豆瓣23赞长评（章浅白）吐槽”美中不足的是例子不够详尽具体”——确实，卡根是”启示录”式写法，每条启示一两页讲完，案例点到为止，不像《精益创业》那样有完整故事；还有读者说”逻辑性不太强”（云生原）、”翻译有待增强，有条件看原版”（虾米）、”读起来有点过时”（子珂，指2017英文版）——它更像”产品管理的武功心法”而不是”招式图解”，适合有过真实产品经验的人反复读（豆瓣书评：边读书边回顾自己的工作经历，”既是一本指导书，也是一本反省书”），没做过产品的纯新手反而容易”道理都对，但没感觉”。

最后说个有意思的事：豆瓣122赞短评居然不是书评，是”在读”栏的吐槽——”终于读完了我草，我的’在读’栏终于空了”——可见这本书多容易”读一半放下”（每章独立、随时可断，确实适合碎片化读）。我的建议是：第一遍快读建立地图，第二遍带着你正在做的产品精读。读完后我把”评估产品机会的十大问题”打印出来贴在工位上——每次想开新功能前先过一遍，半年下来，砍掉的坏需求比做出来的功能还多。这大概就是”启示录”这个名字的意义：它不是教你做产品，是帮你”看见”哪些产品根本不该做。