实践中的产品发现：在真实案例中测试的框架

构建产品最昂贵的部分不是工程。它正在有效地构建错误的东西。整个团队花了几个月的时间，以无可挑剔的技术质量交付了一个解决方案，没有人要求解决不存在的问题。

产品发现的存在正是为了避免这种情况。这套实践在建造之前回答了一个残酷的问题：值得建造这个吗？为了谁？为什么？

发现框架有助于构建这项调查。但他们的理论称赞容易，应用难。这就是为什么本文基于真实案例，在这些案例中，发现决定了产品的命运，无论好坏。

没有人使用该功能的情况

从最常见的错误开始。一家公司决定构建一项功能，因为“客户要求它”。团队的执行、发布、庆祝和采用率几乎为零。

发生了什么？客户确实问过，但他们要求的是解决方案，但没有描述问题。当你真正构建客户所要求的东西时，而不调查其背后的问题，你经常会交付他们错误想象的东西。

发现将会改变这里的游戏规则。一轮面试的重点是了解背景，而不是功能，而是痛苦，这将揭示真正的问题是另一个问题，有一个更简单的解决方案。教训：客户的要求是一种症状，而不是诊断。

在公共部门，这种模式重演并带来了更严重的后果。想象一下市政厅将服务数字化，例如安排预约或发布文件，投资强大的技术。

该系统上线，被宣布为现代化系统，现场排队保持不变。为什么？因为没有人验证真正的公民是否可以使用它。目标受众包括对数字熟悉度较低、连接不稳定以及对流量未预料到有疑虑的人群。

在这里，发现并不是初创企业的奢侈品。这可以避免将公共资金花在无法履行其社会功能的系统上。在建造之前与真正的公民进行一些对话，会发现任何内部会议都不会预料到的障碍。与将服务对象排除在外的服务成本相比，发现成本可以忽略不计。

真实案例表明，一些发现框架在压力下比其他框架表现得更好。

持续发现（持续访谈）。 不再是项目前的一次性研究，而是每周与用户进行一次对话。典型的成功故事是团队很早就发现了严重的异议，因为他们与使用该产品的人保持着持续的联系。
机会解决方案树。 在可见的树中连接业务结果、发现的机会和候选解决方案。它之所以有效，是因为它迫使团队证明为什么解决方案解决了真正的机会，而不是直觉。
在编码之前进行原型测试。 经典案例是使用可导航的原型验证一个想法，并在一个下午发现流程没有意义，从而节省了数周的开发时间。

这些成功框架的共同点是直接且频繁地接触现实。仅在会议室中进行的发现，通过对用户的假设而不是与用户的对话，在实际情况中通常会失败。

也有相反的一面，诚实地承认它。发现可能会导致瘫痪。我见过一些团队用“我们仍在探索中”作为盾牌，永远不会做出决定。

永不收敛的研究不是关心，而是恐惧。在一个初创公司的真实案例中，几个月的研究推迟了市场已经要求的发布，而一个不那么谨慎但更坚定的竞争对手占据了这个空间。

发现必须有期限和目的。我们的目标永远不是了解一切，而是减少不确定性，以便做出负责任的决定。当团队将发现与寻求绝对确定性混为一谈时，他们就会用犯错误的风险来换取同样真实的从不采取行动的风险。

值得通过一个案例来展示发现在另一个层面上的运作，不是为了决定功能，而是为了纠正整个赌注的过程。

想象一下，一家公司确信其受众想要一个更完整、功能更齐全的产品。领导层的直觉很明确：竞争太简单了，差异化需要通过深度来实现。整个路线图都指向这个方向。

一轮严肃的发现、持续的对话、对实际使用情况的观察，揭示了相反的情况。用户不想要更多的功能；他们希望现有的东西能够以更简单、更可靠的方式工作。该公司打算构建的复杂性正是让人们望而却步的原因。

在这种情况下，发现的价值并不在于节省几周的开发时间。这是为了防止公司花费数月时间制定自己的战略，但方向错误。认真对待发现，有时不会调整您构建的内容，它会质疑您是否应该构建它。

这是最困难也是最有价值的用途。它要求领导层愿意听到他们的信念可能是错误的。那些只是为了确认他们已经决定的事情而进行发现的团队并不是在进行调查；而是在进行调查。他们正在寻求掌声。掌声并不能保护任何人免受错误的赌注。

关于进行多少发现的决定本质上是风险分析。不确定性越大，犯错误的成本就越大，发现的合理性就越大。

构建一个小型、可逆且廉价的功能？有时值得冒险并在实际使用中学习，广泛的发现将是一种浪费。建立一个昂贵的、难以逆转的赌注来定义公司的战略或影响成千上万的公民？那么发现就不是成本，而是安全的。

成熟的领导者会根据具体情况进行调整。将发现视为所有事情的强制性就如同将其视为所有事情的可选一样天真。正确的问题总是成正比的：如果我错了，我会损失多少？首先找出答案要花多少钱？

真实的案例以不同的方式教导同样的教训。那些在建设之前调查问题的人会减少浪费，做更多正确的事情并睡得更好。那些跳过这个阶段的人稍后会通过返工和金钱来支付费用，有时会将那些最需要服务的人排除在外。

发现并不能保证成功。它确保当你犯错时，你可以尽早犯下错误，并且有机会纠正它。在产品中，这几乎就是一切。

如果您的组织倾向于先构建、后发现，那么在进行下一个大赌注之前可能值得颠倒顺序。这里还有其他关于发现和设计框架的文章，更深入地探讨了该主题。