书 · 2008-06 · 马蒂·卡根（Marty Cagan）

《启示录：打造用户喜爱的产品》

商业与管理书单第 41 名

一句话结论

产品工作的关键，是在投入大量开发资源之前，弄清用户需要什么，并验证一个有价值、好用且做得出来的解决方案。

值不值得读完整本？

值得读完整本，尤其适合软件产品经理、设计师和技术负责人建立共同的工作方法。它是一本实践指南，长处是把产品判断变成可以讨论和检验的问题；但应按2008年初版理解，不能把后续版本的全部主张算进来。

先读第1至5章，弄清产品管理、项目管理、营销、设计和开发各自解决什么问题，再读第11至22章，抓住机会评估、探索、原型和验证这条主线。
接着读第23至30章，看探索怎样衔接已有产品的改进、部署，以及不同规模公司的工作；第31至39章则帮助你理解不同产品环境中的取舍。
第6至10章的招聘和管理建议，可以初读时略读，承担管理责任后再细看；第40至41章适合读完后用来检查自己的项目。
最好配合一个真实产品练习：写出目标用户、待解决的问题和成功标准，再制作原型并观察用户使用。只背流程，很容易错过本书强调的判断能力。

核心观点

1. 产品管理负责判断做什么，不能被进度管理代替

产品管理要决定什么产品值得做，项目管理则帮助团队把工作组织和交付好。产品经理需要与设计、开发和营销合作，不能只做需求传递和进度协调。

为什么：按时交付只能说明执行顺利，无法说明交付的东西有人需要。用户问题、商业目标、体验和技术条件分散在不同角色手里，需要有人把它们放在一起作取舍。如果产品经理只盯排期，团队就可能高效地完成一个没有价值的方案。明确责任，是为了让关键判断有人承担，同时让各专业参与判断。

2. 先评估产品机会，再承诺具体功能

决定投入之前，要说明解决什么问题、为谁解决、机会有多大，以及怎样判断成功。机会评估首先澄清问题和投入理由，而不是提前写满解决方案。

为什么：一个功能建议往往已经夹带了对用户和市场的假设，直接排期会让这些假设逃过检查。先评估问题，才能比较不同机会，判断团队是否有竞争优势、时机是否合适。提前约定成功标准，还能让上线后的评价不再只靠各方印象。这样，资源分配才有机会围绕价值，而不是围绕谁的要求更强势。

3. 把产品探索与开发交付区分开，提前处理主要风险

探索回答该做什么，交付回答怎样把它做好。初版强调在大规模开发前检验方案是否有价值、是否易用，以及是否可行。

为什么：产品失败可能来自用户不需要，也可能来自不会用，或者团队无法在现实约束下实现；这些问题不能互相替代。越晚发现方向错误，已经投入的开发、测试和协调成本就越高。探索用较小投入提前暴露不确定性，让团队有机会修改或放弃方案。敏捷开发能够改善交付过程，但不能自动保证团队选择了正确的产品。

4. 理解用户的问题，不等于照单实现用户的要求

用户是理解需求和检验方案的重要伙伴，但用户提出的功能要求不能直接当成最终产品定义。产品团队仍要判断哪些方案能服务目标市场。

为什么：用户熟悉自己的困境，却未必知道技术能提供哪些新办法。不同用户的要求也可能冲突，逐项满足容易让产品失去重点。与真实目标用户持续接触，可以帮助团队理解使用环境和问题背后的原因。再由产品、设计和开发共同提出方案，才能把局部诉求转化为适用于更多目标用户的产品。

5. 用原型和使用观察，把产品设想变成可以检验的东西

初版主张用能逼真呈现体验的高保真原型，作为产品说明和用户测试的重要载体。测试应关注目标用户实际怎样使用，而不只是听他们是否喜欢。

为什么：文字说明容易让产品、设计、开发和用户各自想象出不同的东西。可交互原型让操作过程显现出来，使误解和体验问题更早暴露。观察用户完成任务，比泛泛询问喜好更容易发现他们在哪里理解错误、哪里无法继续。原型修改通常比正式产品返工便宜，但原型测试仍不能单独证明真实市场中的商业成功。

6. 基本产品要保留完整价值，不能只是删剩下来的功能

首发版本应包含产品成功所必需的最少功能，而不是把所有想做的东西一次做完。减少范围的前提，是仍能兑现核心价值。

为什么：增加功能会增加开发和验证的负担，也可能让用户更难理解产品。可是，为赶期限随意删功能，也可能切断完成核心任务所需的环节。团队必须先识别哪些能力共同构成一个有用的整体，再移除不影响这个整体的部分。这样缩小的是投入范围，而不是把产品的成立条件一起删掉。

反对意见

先定型再交接，可能低估工程师的创造力（David Ron）

David Ron在《Book Review: Inspired by Marty Cagan》中批评初版某些安排过于强调产品与体验角色先定义方案，再由工程实现。他认为技术约束和工程师的创造力本身就会改变产品方向，主张更早让工程师参与，并用短周期的可运行产品检验方案。这是对初版的直接批评；它针对的是分工可能形成的交接模式，不能据此说卡根完全排斥工程师参与。

用户喜欢、用得了、做得出，仍不足以保证生意成立（马蒂·卡根）

卡根在《Strong Opinions, Loosely Held》中反省，初版把商业可持续性放在可行性之下，明显低估了它的重要性。成本、变现以及其他经营约束，可能让一个受用户欢迎的方案仍然无法持续。因此，读初版的风险框架时，需要认识到它在商业判断上的不足。这是作者后来的修正，不是初版已经充分展开的论点。

过早细化界面，也可能压缩团队的解决空间（Ryan Singer）

Ryan Singer在《Shape Up: Stop Running in Circles and Ship Work that Matters》中主张，开发前应把问题和方案边界塑造清楚，同时保持表达粗略，给实施团队留下设计空间。他认为过早进入线框图或高保真稿，会提前锁定太多细节。它与初版强调高保真原型的做法形成对照：降低沟通歧义的收益，需要与保留创造空间的收益一起权衡。这不是对《启示录》的直接书评。