文 / Marty Cagan 译 / 林航，王烨，吉绚

Marty Cagan是享有世界声誉的产品管理专家，曾担任网景副总裁、eBay产品管理及设计高级副总裁。本文是他回顾自己二十多年来从事软件产品管理工作和经验的总结，分享了探索产品的流程和方法。

产品开发宁缺勿滥​

有没有见过这样的情形？开发团队刚刚完成手头上的项目闲了下来，可产品经理一想到程序员们自在逍遥，就怎么也坐不住了。为了让他们马上开始新项目，产品经理没日没夜地制作新项目的产品需求文档（PRD），以求速成。这样的事情在产品团队里时常上演，成为产品失败的罪魁祸首。

开发团队就像“嗷嗷待哺”的婴儿，胃口特别大，却分不清哪些该吃，哪些不该吃。只要产品需求文档到位，不论产品好坏，他们就马不停蹄地开始新一轮的产品开发。后果可想而知。

追根溯源，这种现象的产生是因为产品开发团队里的程序员聘金不菲，公司不乐意看到他们闲着，只有“物尽其用”，才会让公司觉得安心。可聪明反被聪明误，这种短视的行为，给产品的失败埋下了祸根。这种行为还会掩盖开发团队真正的价值。开发团队被公司异化成生产代码的机器，而不是共同探索、打造出成功产品的“战友”。

只让开发人员负责软件的开发，明显低估了他们的价值。正确的做法是先通过产品探索定义出基本产品，确定产品是有价值的、可用的、可行的，然后再交给程序员去开发。强迫开发团队满负荷工作的公司，显然是管理理念出现了问题：代码好不等于产品好。当然，这种现象和企业文化也脱不开关系。

不可否认，好的项目经理确实能保证产品的交付进度。但不能因此就盲目地让项目管理在公司里唱主角。进度安排合理、资源得到了优化配置不意味着产品就能取得成功。通常，我会建议项目经理在产品探索阶段安静地坐在“观众席”上，等到确信设计的产品值得开发了，再粉墨登场率领团队开发产品。采取这套方案后，收效不错。但如果产品探索阶段，团队里缺少能一统全局的主帅，这套方案就不适用了（在今后的文章中我再讨论这种现象）。

如果开发团队闲了下来，而新一轮产品探索还没完成，该怎么办？其实选择很多。

让开发团队利用“余量（headroom）”完善软件架构。

让开发团队着手修复产品缺陷，改善产品性能。

让开发团队参与产品探索活动。

产品经理给开发团队预留一个月左右的任务。这样即使手头的项目卡了壳（比如原型测试中，用户的反馈意见很糟糕），在想到新方案之前，你的开发团队都有事可做。

开发团队无事可做，还有可能是项目团队里开发人员和产品经理及设计师的比例失衡造成的。如果开发人员过多，那么产品设计团队永远跟不上进度，开发团队必然会“档期”不满。

要记住，产品经理的使命是确保团队开发有价值的产品。让开发团队盲目开发未经验证的产品，也是一种浪费。

产品探索计划

为了不让程序员闲着，产品经理把本该花在产品探索上的时间都花在了赶写产品需求文档上。可这样的产品探索毫无价值。时间再紧迫，也不能牺牲那些创造价值的关键步骤。而有些公司非常重视产品探索，却没有对这个过程做出合理的规划，不能保证每天做的都是有用功，自然无法快速开发出基本产品。所以，宝贵的时间就这么白白浪费了。

产品探索规划是否详细，取决于公司的文化氛围和产品探索人员的能力。很多公司（特别是大规模公司）中，团队需要一个产品探索计划，明确项目必须实现的内容、需要的资源，并给出粗略的进度安排。

我将列出常见产品探索计划的组成部分。但这不是模板，不要照着里面的内容生搬硬套，做些不需要做的事情。我列举的每个部分分别解决不同的问题，你可以根据你要解决的问题，选择合适的探索计划。作为产品经理，你要审查这个计划并确保团队按计划执行。

核心探索团队：确认项目的产品经理、首席设计师和主程序员，并且确保这些人员在探索产品的过程中随叫随到。

探索扩展团队：谁将给这个核心团队提供支持？你是否需要视觉设计师？你需要原型设计师的协助吗？需要可用性测试资源吗？需要有特定开发经验的开发人员吗？需要QA团队提供人手吗？需要市场部的人员支持吗？

关键参与人员：这个项目必须得到谁的批准（即谁拥有“否决权”）？此外，还可以写上你认为能够对这个项目发表独到见解的聪明人名单。

客户发展计划：这个项目需不需要特约用户？如果需要的话，谁是牵头人？如果不需要的话，你会请哪些客户（用户）验证你的产品理念？

主要风险：这个项目的主要风险有哪些？你将如何解决这些问题？

用户研究工具：这个项目需不需要创建一些人物角色？需要做网站检查和商业分析吗？

用户测试计划：你打算如何让实际用户测试产品？初步测试计划是什么？

产品战略（愿景）：是否需要在制定项目细节之前，考虑项目所在领域的长期发展？

产品原则：产品的所在领域是否需要独创一些产品原则？

支持文档的程度：核心团队需要在以下方面达成一致意见：在这个项目中，需要哪些额外文档、需要做到什么程度，包括用户故事、用例、测试计划等。

制订计划只是产品开发中的一步，更重要的是保证产品探索确实是朝着满足基本要求的产品方向努力。另外，将这两步结合起来后，什么时候能真正开始构建产品也是关键。这个过程的监督工作包括两个部分。

首先，我认为，产品的负责人（如产品经理或首席用户体验师）需要对这项活动尽到监督责任，他们积极的监督会对定义产品起到积极的作用。这里要说明一点，这里的“监督”指的是每周至少询问一次产品探索团队下面这些问题。

你这周与什么样的客户和用户进行过比较有效的沟通？

你从你们的讨论中了解到了什么？在你了解它们的过程中，有什么事情使你感到惊讶吗？你有了什么新的见解？

你是否遇到了潜在关键点？【注：参见http://www.svpg.com/your-business-plan-is-wrong】

根据你所了解到的内容，下一次你会进行哪些新的尝试？

开发人员最后一次评估产品设计和客户反馈信息是什么时候？

开发人员在项目可行性和可能的解决方案上有什么意见和反馈？

用户认可这种想法的价值吗？如果不，那么为什么他们不认可？

目前原型最主要的可用性问题有哪些？你打算如何纠正这些问题？

从可行性的角度来讲，开发人员最关心原型的哪些方面？针对这些问题，你有哪些应变措施？

最后，你认为在两周之内完成一个满足最低要求的产品的可能性有多大？如果有困难，那么团队是应该继续努力还是考虑开发其他产品？

其次，产品经理也有监督其他事务的职责，比如在项目管理方面，需要确保产品探索计划的实施情况，做好开发的一切准备工作。具体来讲，这包括保证开发团队有足够的资源开展工作，明白项目时间限制及做好时间管理，确保开发者、产品管理者和设计者之间的良好沟通，根据计划从整体上推动进度，以及确保项目中的时间都被有效利用。

项目经理的确可以督促大家完成项目，但要确保先确定基本产品，而不能仅写些开发文档。

不管怎样实施计划，如果公司很开明，允许你在探索产品上花时间，而不是仅仅撰写需求文档，那么我希望你不要浪费产品探索中的每一天。如果你已经花了很多工夫，但仍感觉到很难开发出好产品，你应该尝试制订产品探索计划。

产品探索日记​

产品经理和设计师们放弃原有的线性、瀑布式的开发流程，转而采用我倡导的这种更具迭代性、探索性的流程后，通常需要花一些时间才能适应它的快节奏，掌握产品探索的韵律。

这篇文章将再现产品探索的情景，让大家了解其核心内容。

因为产品的开发过程涉及的因素太多（如产品类型、投入的精力等），做这样的概括并不容易。我尽量使用比较典型和普遍的情景。为了覆盖尽可能多的要点，我构思了以下情景。