打造好产品，不足以成为一个企业的核心竞争力，而是打造出能创造高收益的好产品——掌握产品经营模式。马蒂·卡根提醒我们：不是以产品上市时间为目标，而是以产品创收时间为目标。拥有40多年产品经验的马蒂·卡根，结合自己20多年实战经验，在书中进行了凝练总结。3大方式、5大要素、7大步骤、9大案例，解决企业经营痛点的有效路径。对比传统模式和产品经营模式，针对那些想要转型，但不知道该如何转型的管理者，提供了一套行之有效的方法。
在技术投资方面，为用户和公司创造价值是核心目标。创造价值涉及很多方面，但归根结底，开发产品所依赖的主要是工程师。对于许多科技公司而言，产品工程师是成本构成中最大的单项支出。传统模式通常把每项技术工作视为一个项目。每个项目都会获得资金、配备人员并且完成规划、执行和交付。项目完成后，人们转而从事其他工作。
请注意，在所有开发产品的工作中，我们都在创造两种价值：我们开发的产品和在这一过程中积累的经验教训。在传统的项目模式中，这些经验教训没有正真获得足够的重视和有效的留存。这导致如果我们再次在这样的领域开展工作，就要重新花费时间和金钱学习。或者更有可能什么都没学到，我们因为缺乏必要的知识，犯下代价高昂的错误。
此外，在对待代码的态度上，需要长期维护自己编写的代码的团队与项目结束后会离开的团队是截然不同的。这就是项目模式下技术债务如此普遍的原因。这就像翻修房子是为了出售还是自己居住的区别。如果是前者，简单地粉刷墙面更快、更省钱，即使以后油漆剥落也无所谓。
这就是外包公司常用的方式。我们大家常常说，如果这是你想要的工作方式，不如直接聘请埃森哲咨询公司，因为它比你更擅长以这种模式工作。但在产品经营模式中，仅仅以完成项目为目标的工作模式成本过高。更重要的是，它不足以满足用户和公司的持续创新需求。
因此，转型始于改变开发产品的方式。这在某种程度上预示着公司将重点从以项目为中心转变为以产品为中心。在产品经营模式中，产品需要持续不断的改进。在优秀的产品型公司中，产品每周都在改进，甚至是每天多次，而且通常会持续数年。
你可以将团队的工作从开发新功能转为创收变现、降低运维成本或任何公司所需的其他任务。总而言之，团队将持续对产品做投资，直到企业决定停止投入仅维持产品目前收入，或者企业决定产品进入生命周期结束阶段，直至从产品组合中被完全淘汰。在这种持续开发模式中，你需要小型、高频、可靠的发布机制。
优秀的产品型公司早在几年前就认识到，产品开发的次数越多，交付的变更就越多。对公司，尤其是对公司的用户而言，高频发布比低频发布的效果更好。这一点在《加速：公司数字化转型的24项核心能力》一书中作者妮科尔·福斯格伦（Nicole Forsgren）等做了详细解释。尽管这听起来有违常理，但数据很清楚地证明了这一点。
如果你想为用户更好的提供可靠的服务，那么确定保证产品少量变更能够正常运行，并且不引入任何意外问题，这要比将大量变更集中在一起并试图一次性发布容易得多。也就是说，如果你的产品团队没做到至少每两周发布一次，那么你就无法按需服务好你的用户。关于公司没办法做到这一点的常见借口，我们将在第六部分中加以揭示。
更重要的是，对于你部署的所有内容，你都需要确定保证产品的新功能经过充分的测试，以便懂产品运作状况和用户实际使用情况。你还需要持续监测产品，以便在用户察觉缺陷之前及时有效地发现并解决。对于产品的许多重要更改，你需要在全量发布之前证明新功能提供了必要的价值，目前的标准做法是通过A/B测试。
你可能认为这并不适用于你的产品类型，或者指出用户希望你减少发布频率，而不是增加发布频率。但在第11章中，我们将深入讨论为什么这样的做法对你和你的用户至关重要，驱动这种工作模式的原则以及采用的机制是什么。
你应该听说过敏捷。在过去20年里，许多公司转向敏捷方法的根本原因之一是，它为产品团队提供了一种推动力，让其实现持续、小型、高频的发布。
诚然，转向小型、高频的发布可能需要大量投入，大多数都用在测试和部署自动化。但是，对那些使用敏捷方法让其发布频率不低于每两周一次的公司来说，这确实为它们和用户更好的提供了真正的价值。
不过，需要说明的是，实现小型、高频的发布不一定需要敏捷方法。事实上，世界上许多顶级产品团队已拥有了以持续集成和持续部署（CI/CD）的方式发布极小版本的能力，但他们并未遵循任何正式的敏捷方法。
相反，一些公司在敏捷教练、敏捷仪式、敏捷角色、敏捷方法和敏捷流程上花费了巨额成本和时间后，产品仍然只能实现按季度发布，让它们的用户产生了不好的体验。
这里需要讲清楚一个关键点：若公司的产品仍然按照年度、季度或者月度发布，那么你遵循多少敏捷仪式或聘用多少敏捷教练都没用。因为你并没有在本质上实现敏捷，甚至连表面上的敏捷都没有实现，也没获得相应的收益，并且无法像你所期望的那样为你的用户更好的提供服务。
许多公司花费了数百万美元转向敏捷流程，因为它们认为这是转型的必经之路，但它们为此付出的努力却很少，或者没取得任何有意义的成果。如果这正是你所在公司的情况，我们始终相信你一定感觉到很沮丧。
无论你是否选择采用敏捷方法，你都需要让每个产品团队能够至少每两周一次地进行高频、小型、可靠的发布。如果你的现有团队没办法做到这一点，那就需要引进经验比较丰富的研发主管、工程师或真正的产品交付教练来指导他们。
「夜读好书」栏目往后将每日晚间更新，由编辑们从数百本经典书目中精选呈现。在纷繁的世界中，让好书陪你度过一段深邃、宁静的晚间时光。好书夜读，让生活松弛有度～
