我对一本好书的评判标准是：说出读者一直想说，但未说出的话。可能是最近心情抑郁，大脑也想找个东西转移注意力吧，昨天一下午加晚上竟然就这么对外界无知无觉地读完了Marty Cagan的《启示录》。之所以使我如此专注的原因是，读这本书我充满了激动，书中很大一部分正契合我这两年作为程序员工作经历时所生发的关于产品管理的想法，例如就像程序员的代码需要测试，产品经理设计的产品原型也应该通过测试，证明这样的设计是用户想要的、需要的。尤其是Marty Cagan提出的“基本产品”概念，这不正是在创业公司工作时我一直想要说的东西吗！记在这里，希望看到此文的现在或未来的中国产品人可以理智、内敛、富有长远眼光地对待产品管理，不要无畏地拿产品实验你凌乱的“点子”，不要折腾公司，尤其是创业公司，更不要折磨可怜的程序员们。
我号召产品团队放弃老式的产品设计方式。比如，不再试图定义最终产品，转而定义只满足基本要求（价值、可用性、可行性）的产品，简称基本产品。一旦基本产品定义完成，通过了用户测试，它就是一个不可分割的整体，去掉任何元素，都不可能获得预期的效果。
你见过这样一幕吗？产品经理制作了完善的产品说明文档，详细标注了各项产品功能的重要等级。然后，开发部门根据这份文档估算开发成本和开发时间。虽然剔除了开发团队力不能及的功能，但得到的进度表还是比产品经理设想的多几个月时间。于是双方开始协商，先是争论估算是否准确，然后不得不消减功能，缩小测试范围，减少公开测试时间，要求雇佣额外的开发人员……不知不觉时间已经流逝。我猜测你多半见过这一幕，即使没有见过，也能猜测到结果：最后开发出来的产品完全不是有机的整体，产品经理不满意，开发人员不满意，用户更不会满意。很多团队把这种情况看成是理所当然的、不可避免的，其实这是不合理的流程造成的结果。因此，我建议采用另一种产品设计方式。
- 产品经理与设计师合作设计产品的高保真原型，这个原型只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力。只设计基本功能的产品可以把复杂度降到最低，把开发时间减到最少，因而是非常重要的。
- 邀请一位开发人员（比如架构师或主程序员）参与设计原型。请他检查原型，帮助产品经理和设计师估算各种功能的直接产本和间接成本，指出设计上的误区，并分析、评估尚不确定是否可行的功能。等产品原型确定时，他详细估算出所有产品功能的时间成本。这样一来，各项功能孰去孰留已经明了，而且对各方都是透明的，开发团队心里也有底了。
- 请真实的用户验证（测试）产品原型，这一点至关重要。在产品团队全力开发产品前，产品经理和设计师必须确信产品是用户需要的，然而仅仅相信还不够，必须通过用户测试来验证。这好比不能仅仅因为开发人员相信代码没有问题，就允许发布代码一样，必须对代码展开测试。
- 一旦基本产品确定，通过了目标用户的测试，就不可能再削减任何功能。如果还能削减，那说明你定义的不是基本产品。当然，根据产品原型估算的开发时间也不是完全准确，比如，对某些功能的开发时间的估计可能过于乐观。如果出现这种情况，只能延长工期，不能削减功能，因为你已经没有东西可削减了。尽管如此，由于估算的依据从一纸文档变成了精减功能的原型，精度还是大大提高了。即使延长工期，情况也远没有以前严重。
由于开发的是基本产品，一旦进入软件开发环节，产品经理就不能再随意修改设计。过去产品经理经常要求更改产品设计，主要是因为一开始构思不全面、不彻底。设计高仿真原型能够迫使产品经理改掉这个坏毛病。因此，设计产品时一定要考虑哪些功能是最重要的，争取设计出只满足基本要求的、不可删减的产品。就像我从前的老板常说的——断腿的狗打不了猎。
