【译文】产品发掘

1. 读后感

几乎所有公 司都没有按照我所描述的产品发现过程来做一个原型系统，他们使用了全部开发团队资源，按照正式发布周期建设和测试，然后部署到生产环境中。这就是为什么许 多公司通常需要在一到两年，3个以上的版本发布后，才能拿到一些可用和有用的东西。他们使用整个开发团队构建了一个非常非常昂贵的原型，然后利用不知情真 实用户来做测试对象。

多么可怕的场景，做为一个普通用户，不知道被多少公司当成了试验品。但其实这是一个两败俱伤的结局，为什么不想办法避免呢？

2. 翻译

产品发掘

标签：产品发掘，产品管理

你以前见过这种情况吗？你的老板有了一个很棒的点子，作为产品经理的你，被要求写出产品定义。你被告知，项目组将在4周后做完当前项目，因此这意味着你可以做你想做的事情，只要在4周内完成产品定义即可。

没问题，你说（毕竟，有时候你只有几天时间，因此四周听起来不错）。你甚至可以使用我一直强调的所有的最佳实践。你开始做机会评估（产品发掘过程的第一 步，note by twoTwo），了解这个点子要解决用户的什么问题，然后你需要花大时间和真正的用户交流，并确定了一套初步的要求；第二个星期，你开始做互动原型设计； 在第三周，把原型拿出来做用户测试；在第四个星期，你会出的用例进一步的细节，并检讨工程原型和规格说明书。

这 些都是伟大实践。但通常发生的事情不是很理想。在最初的用户讨论中，你发现用户没有被你老板的点子打动，并且/或者你百般努力的搞出一个用户能体验的原 型，并且/或者用户在测试过程中，对原型里面的点子不感兴趣。但时间已到，开发团队已经就绪，结果是，在接下来的3到6个月里，工程师们接着开发这个无用 又无趣的产品，就象你看到的原型一样。这个产品管理过程让人感到失望。

问题不在于软件不可靠性，因此不能责怪研发团队-毕竟，他们只是开发你要他们做的-每个人都知道这是你这个产品经理的过错。

你知道，如果你不根据学到的来调整过程，仅仅和用户交谈，建立原型和开展用户测试是无用的。

在我们的行业中，这种主张在产品开发过程中，需求和设计有序、可预测和预先要安排好的概念是如此根深蒂固，以至于它成为产品组织中最难打破的习惯之一。

但这是一道必然要过的关卡。产品组织需要向事实妥协，即产品发明的过程基本上是一个创造过程。这是艺术而不是科学。

我更愿意认为这个过程是“产品发现”而不是“需求和设计”。我觉得这个术语强调了两个极其重要的点：

首先，你需要去发现是否存在着真的需要这个产品的用户。换句话说，你需要进行市场识别，验证机会客户。

其次，你需要发现一个产品来解决这个问题，这个产品必须是可用的，有用的，可实现的。换句话说，你需要设计出产品，然后在用户和开发团队中验证。

有时，这种产品发现是直接的。而有时候却是及其困难的。根据我的经验，发现和验证市场机会不是很难，但发现解决方案往往非常具有挑战性。即使有伟大的设计师和工程师帮忙，有些问题只是很困难的（但至少还是值得追求的）。

制药行业提供了一个极端的例子。市场发现通常不会很困难；不是缺乏需要解决的好问题（例如挽救和延长你的生命，或改善你的生活质量）。困难的部分是发现一个 产品解决方案。制药公司进入这个“发现”阶段，充分认识到，由于没有志愿者，他们将不能保证会做出什么，或者需要多长时间。作为一个产业，他们必须和不明 朗因素妥协（而这种风险就是产品价格）。

而在软件行业，尽管我们都知道产品发现的困难行--有大量的软件发布未能达到其目标，我们仍然坚持要象造房子那样先出完整的设计蓝图。

管理和产品发现观念特别冲突。我认为有两个基本原因：

首先，产品发现过程是不可预测的。管理者担心，你可能可能会花费数月时间，但最终什么也拿不出来。而如果他们象造房子那样工作下去，总会搞出来点儿东西。基于同样的原因，许多管理者不喜欢Scrum。他们想明确的知道把东西搞出来需要多少个30天冲刺。

其次，几乎所有软件产品的组织管理者认为，开发团队是有限的资源，如果一个开发团队可能会无所事事或做一些和生产无关的事情，会令管理者发狂。

具有讽刺意味的，正是基于这一考虑，直接导致开发资源浪费。

要 知道，几乎所有公司都没有按照我所描述的产品发现过程来做一个原型系统，他们使用了全部开发团队资源，按照正式发布周期建设和测试，然后部署到生产环境 中。这就是为什么许多公司通常需要在一到两年，3个以上的版本发布后，才能拿到一些可用和有用的东西。他们使用整个开发团队构建了一个非常非常昂贵的原 型，然后利用不知情真实用户来做测试对象。

这也是为什么有这么多的创业失败。大多数创业公司根本没有足够支撑两年的资金来做产品发现。因此，他们聘请了开发工程师，让他们卖劲儿的干，看看会发生什么。

因此，对大公司和初创公司一样，我都极力让他们集中全部精力在更快的产品开发过程中，一旦发现有效的解决方案-一个可用、有用、有益且可行的的解决方案-然 后才是开发团队的活儿了。在那之前，他们没有必要马上聘请这么多的工程师，他们现有的工程师可以而且应该积极的参与到产品发现过程中去，并在一定程度上开 发团队可以一边准备基础架构，一边参与产品发现。

你可以帮助你的管理人员来了解产品发现过程的性质。如果产品经理一直强调自己的义务-确保开发团队实现的产品必须是有用和可用的，并尽最大的努力来发现最棒的解决方案，产品经理就会开始将重心转向这一产品开发过程中最关键的阶段了。

3. 原文

Product Discovery

Posted by Marty Cagan on September 24, 2007

Tags: product discovery, product management