一句话点评：如此美好的产品探索过程，我想，在很多公司根本不存在吧，哈哈~~~
Marty Cagan发表于2008年11月12日，原文链接，译者：吉绚 / 审校：林航 徐定翔
产品经理和设计师们放弃原有的线性、瀑布式的开发流程，转而采用我倡导的这种更具迭代性、探索性的流程后，通常需要花一些时间才能适应它的快节奏，掌握产品探索的韵律。
这篇文章将再现产品探索的情景，让大家了解其核心内容。
因为产品的开发过程涉及的因素太多（如产品类型、投入的精力等），做这样的概括并不容易。我尽量使用比较典型和普遍的情景。为了覆盖尽可能多的要点，我构思了以下情景。
l 为了明确商业目标，我和项目的主要负责人一起进行了产品的机会评估与讨论。
2 与项目的首席设计师及主程序员开第一次讨论会，制定出产品原则。
3 紧接着，我们进行了头脑风暴，想到不少好点子。
4 与首席设计师一起创建第一轮关键人物角色。
====== 周二
l 和首席设计师继续优化前一天完成的用户角色，确定主要和次要角色；讨论用户使用产品的情景，并列出主要情景和次要情景。
2 与用户研究员一起明确潜在特约客户名单；通过电话联系特约客户，筛选候选人。
3 首席设计师根据讨论结果快速创建产品原型。
====== 周三
l 我、首席设计师以及主程序员一起检查前一天完成的产品原型，看它是否符合我们最初模拟的几个用户情景。讨论非常激烈，原型远比我们设想的要复杂。
2 我们回顾之前提出的产品原则，再一次明确了重点，之后大幅简化了产品原型。
====== 周四
l 我、设计师和项目的主要负责人一起查看产品原型。这个原型还在初期，但是已经包含了三个最重要的使用场景。通过讨论，我们意识到我们和项目负责人的想法有些脱节，因为双方对用户的理解不同。
2 继续电话联系目标客户，确认6家公司成为我们的特约客户。最棒的是，他们似乎对我们的产品将解决的问题有极大的兴趣，因为他们的公司都还没有找到好的解决办法。如果我们的产品能够解决这个问题，那么他们会非常看好我们的产品。
====== 周五
l 我们和主程序员一起评估修改后的原型。他对主要功能的可行性持谨慎乐观的态度，并提出了两个重要的问题。第一，其中一项功能的开发成本可能颇高，而且执行 速度很慢。他需要点时间研究这个问题。另外，他认为我们可以省去一些收集数据的工夫，因为我们需要的数据可以从数据库提取。
2 咨询有关法律人士，向他展示原型，确保模型没有和法律相冲突的地方。他们认为其中一处需要进行详细评测，检查结果会在下周给出。
============ 第二周 ============
====== 周一
l 早上，我、首席设计师以及项目负责人一起拜访第一个客户，请四位潜在用户试用产品原型。这次测试收获颇丰。可惜原型的表现与我们的期望还有很大的差距。我 们发现自己此前对用户的理解还很肤浅，项目负责人的理解也不完全正确。现在我们对用户的理解又进一了步，而且达成了基本的共识。
2 回到公司后，我们立刻讨论如何修改原型。我们简化了自以为重要的场景，修改了术语，去掉了那些根本不会被用到的高级功能。
====== 周二
l 主程序员在研究完高风险的技术问题后，确定他之前的担心是有道理的。他提出了新的可行方案，可以实现同样的效果，而且开发难度更低。于是我们根据他的意见对原型进行了调整。另外，他确认了我们本来要收集的数据在数据库中都能找到，这就进一步简化了原型。
2 下午我们拜访了另一个客户，请三位用户参与了测试。今天的情况比昨天要好很多。我们仍然不确定原型的交互设计是不是足够好，但是至少用户能够完成主要任务 了。之前去掉高级功能的这一步棋确实走对了，因为用户并不关心它们。我很高兴我们坚持了以客户为中心的价值观。有两位测试用户希望我们第一时间通知他们产 品完成的消息。
====== 周三
l 与首席设计师、主程序员碰头，讨论目前的成果和接下来的工作。主程序员又提出了一项针对关键流程的优化建议，恰好解决了首席设计师面临的几个棘手的问题。
2 我和首席设计师向视觉设计师提出了我们对视觉设计的几点想法。经过先前的用户测试，我们认为必须将产品中的两个基本概念用某种方式清晰地传达给用户，并且 给出了关键状态和用户可能做出的动作。视觉设计师说她已经有了可以表达这些概念，提升产品价值的想法。她会在接下来的一两天内给我们一些具体的方案，之后 我们可以为这些方案提建议。
====== 周四
l 我们仍然在努力定义基本产品。我们相信已经把最关键的功能都涵盖在内了，但是不确定到底要不要再加上一个比较酷的功能，不知道它是不是必需的。我们计划暂时从模型中删除这个功能，看看测试的效果如何。
2 下午，我们拜访了另一位客户，请三位用户测试了产品原型。原型的可用性已经很棒了，但是，删除了之前说的那个功能后，原型没有得到用户的热烈响应。我们又 展示了之前的版本，这次他们表现出了极大热情。我们得出的结论是，这个功能确实非常重要。我们的原型中已经尽可能地删掉了所有不需要的部分，但是仍然能激 发人们的购买欲望。我们去除了很多高级的功能，简化了关键流程，应该能在主程序员估计的时间内完成开发任务。
====== 周五：
l 我、首席设计师与可视化设计师一起讨论了她设计的方案，我们特别喜欢其中的一个方案。稍做调整洁后，我们把它用在了原型上。
2 主程序员根据现有（也可能是最终）的原型估计出了产品开发的周期。这个时间可以接受，并且有风险的技术问题已经排除。
============ 第三周 ============
====== 周一
l 我们将包含最新的产品原型展示给项目负责人，并且总结了最终的产品设计（包括最新的界面设计），以及所有来自测试客户的反馈。她很喜欢这个产品，希望旁观下午的测试。她也想就价格和定位询问客户的意见。
2 下午，我、首席设计师以及项目负责人带着最终原型去见另一个客户。我们请四、五位用户进行了测试，得到了理想的反馈——没有遇到使用问题，对功能和价值的反响也很好。所有用户都很期待这款产品的问世，也愿意推荐给朋友或者同事使用。
====== 周二
l 继续完善原型，并将这些天来了解到的关键点录入项目维基。
2 向给更多的项目参与人展示了产品原型，包括法律顾问、市场部、产品管理和工程方面的副总。他们提出了一些问题，但都认可用户测试的反馈。
====== 周三
l 我、首席设计师以及主程序员碰头，讨论如何撰写产品文档，方便开发人员、测试人员、部署人员开展工作。
2 我和首席设计师分工撰写文档，我们将各自负责的部分写到项目维基里，并添加了一些对产品原型的链接和注释。
看完以上的日记，希望你能明确以下这10点。
1. 在项目开始时，确定你对目标有清晰的理解（产品机会评估）。
2. 从产品探索最开始时就建立和首席设计师、主程序员的密切合作。
3. 注重真正的协作交流，而不仅仅满足于写那些没人看的文档。
4. 迅速的将关键的产品理念融入到原型的制作中。
5. 设法验证自己对产品的假设，不要纸上谈兵，尽快判断哪些假设正确，哪些不正确。
6. 尽早反复地将产品原型提供给目标客户测试，及早发现问题。
7. 记住要确定基本产品。
8. 产品探索的目标：确定产品是有价值的、可用的、可行的。
9. 在产品探索的过程中不断保持和相关部门的信息互通，向大家展示不断更新的产品原型，让他们了解进度。
10. 不要把时间花在为开发人员写文档上，等到产品确定后再写。
当然了，实际项目不一定完全与我的描述相同，我希望传达这样一种观念：在把产品理念展示给真正的用户之前，不应该花两周时间撰写产品文档，更不能花三周时间制作初期产品原型。
产品探索有特定的节奏和规律，它以构思产品设计、原型制作、用户测试，以及最重要的一点，反复学习为基础。如果你还没有亲身体验过探索产品的过程，那么我希望这篇文章可以让你大致了解产品探索是什么，以及它与直接开始撰写产品文档的做法的区别。
本文节选自《启示录：打造用户喜爱的产品》作者Marty Cagan的博客。该书从人员、流程、产品三个角度介绍了现代软件（互联网）产品管理的实践经验和理念。特此感谢Marty Cagan先生授权。