产品发现

产品探索是指决定要开发什么产品，这与交付（即实际开发产品）截然不同。它涵盖理解客户问题、识别机会、生成和评估解决方案，以及在投入大量工程资源之前验证所提出的解决方案是否具有价值、可用性、可行性和有效性。

将探索视为一项明确的活动，其理由在于大多数产品失败并非源于产品开发质量差，而是源于产品本身不合适。如果团队直接从利益相关者的需求或路线图条目跳转到规范制定和交付阶段，他们往往会高效地开发出一些价值未经证实的功能。探索则在需求和开发之间引入了一个刻意的步骤，在这个步骤中，团队会仔细审视问题的根本原因，并以低成本的方式让真实用户测试所提出的解决方案。

马蒂·卡根提出的四项风险框架，为产品发现过程必须解决的问题提供了一个实用的清单。价值风险考察的是客户是否足够需要该产品，以至于愿意购买或使用。易用性风险考察的是客户是否能够弄明白如何使用该产品。可行性风险考察的是利用现有技术、技能和时间是否能够实现该产品。商业可行性风险考察的是考虑到企业的经济状况、法律限制、品牌和运营模式，该产品是否适合企业。每项风险都需要不同的证据支持，而仅仅关注团队认为容易接受的风险往往会导致失败。

相对于产品交付而言，高效的探索过程应该快速且成本低廉，这决定了探索方法的选择。客户访谈、概念测试、根据问题需求制作各种精度的原型、落地页测试、技术验证以及对现有行为数据的分析，所有这些方法都旨在几天内而非几个月内得出证据。如果探索过程耗时与功能开发一样长，那么它就变成了一个阶段而非一种实践，在压力之下很容易被忽略。

最常见的结构性错误是将探索阶段视为交付之前的一个阶段，然后就结束了。持续探索是指团队在交付过程中与客户保持定期联系，这样可以持续产生证据，为随时出现的决策提供依据，而不是像大型研究项目那样，在产品交付时结论已经过时。它还能避免由独立团队进行研究并移交给交付团队的模式，这种模式很容易导致大部分信息在传递过程中丢失。

为了确保探索过程的公正性，一个有效的方法是：首先明确提出一项工作方案背后风险最大的假设，并对其进行测试，而不是测试那些最容易测试的内容。团队往往会倾向于回答可用性问题，因为这些问题既轻松又能得出明确的答案，而忽略了价值和可行性风险，因为解决这些问题需要与客户进行一些令人不快的对话，讨论他们是否真的愿意付费或改变行为。如果探索活动是按风险而非便利性排序，就能避免出现这样的常见结果：开发出一个美观易用但却无人问津的功能，虽然它在所有方面都得到了充分验证，唯独缺少了真正重要的方面。

只有当探索能够改变最终的构建成果时，它才能创造价值，因此，探索既是一个方法论问题，也是一个治理问题。一个被要求交付一年前就已确定的固定路线图的团队，无法根据所学到的知识采取行动，在这种情况下，探索就变成了对已做决策的记录。实际上，研究方法存在于……之中。 产品研究 和 用户研究该解决方案在 产品设计而且，根据证据改变方向的权力必须明确确立，否则这种做法就成了作秀。