应用创意验证：公司在投资前应决定什么

大多数企业应用程序不会因为代码错误而失败。它之所以失败，是因为在签订合同之前没有人验证该产品是否解决了有人愿意付费解决的问题。

我见过这个脚本在不同规模的公司中重复出现。总监提出令人信服的想法，团队确定范围，技术领域估计截止日期和成本，然后批准预算。六个月后，一款实用、美观的应用程序如期推出，但几乎没有人使用它。该项目在执行上是成功的，但在产品上却是失败的。

这篇文章是写给那些做出决定的人的。如果你在季度末批准预算、需求结果或帐单，[想法验证0不是产品团队自行解决的技术手续。这是一个资本配置决策，它应该像任何其他相关投资一样严格。

为什么验证是一项财务决策，而不是产品细节

构建软件很昂贵，但构建软件的成本很少是最大的风险。最大的风险是机会成本：分配给没人想要的应用程序的每个团队都是一个没有为公司解决另一个实际问题的团队。

当一个组织在没有验证想法的情况下决定投资一个应用程序时，它就是在下赌注。投注是任何生意的一部分。问题是在没有任何证据的情况下下大注，当可以先下注低，购买便宜的信息，然后才决定是否值得下大注。

从这个角度来看，验证就是风险管理。在提交全部预算之前，你花很少的钱来查明问题是否存在、公众是否关心以及模型是否关闭。这就是测试水温和一头扎进去的区别。

我的立场很简单。在批准构建应用程序之前，公司应该要求提供三件事的证据：问题是真实的且相关的，有受众愿意改变他们的行为，并且有可行的返回路径。

这三个答案都不需要构建整个应用程序。所有这些都可以通过较小的投资和较短的时间来解决。任何颠倒这个顺序的人，先构建，后发现，都是将一个他们可以在办公室回答的问题外包给市场，而成本只是一小部分。

这并不意味着官僚主义会阻碍创新。这意味着创意发起人的热情在成为预算线之前需要有证据。

第一个问题不是“这个应用程序是个好主意吗？”，而是“什么问题，谁的问题，多久一次以及花费多少？”。困扰您的问题很少能证明产品的合理性。一个成本高昂、经常发生且没有好的解决方案的问题就是回报所在的地方。

在公司中，这意味着在任何模型之前与遇到问题的人、客户、操作员、内部区域进行交谈。如果这些对话中没有一致地出现疼痛，则应用程序不会创建它。

这里常见的错误是验证解决方案而不是问题。问“您会使用具有 X 功能的应用程序吗？”出于礼貌，几乎每个人都答应了。问“你今天如何解决这个问题，花了多少钱？”真相就出现了。

每个应用程序都需要使用它的人改变习惯。即使解决方案更好，改变习惯也很困难。验证意味着了解痛苦是否足以克服惯性。

一个诚实的测试是观察人们是否已经尝试通过电子表格、消息组、临时手动流程自行解决问题。这种自发的努力是真实需求的最可靠标志。有甘比亚拉的地方通常就有市场。

这就是企业决策与热情不同的地方。应用程序可以解决实际问题，但仍然没有经济意义。验证需要估计（即使是粗略地）投资回报如何：新收入、成本降低、客户保留、内部效率。

如果桌上没有人能够解释应用程序如何在合理的时间范围内支付自己的账单，那么这不是稍后要解决的细节。这就是尚未批准的原因。

与构建相比，验证成本较低。与真实客户的访谈、衡量兴趣的捕获页面、背后没有代码的可导航原型、团队在幕后运行应用程序的手动试点，所有这些策略都以边际成本生成证据。

目的不是证明这个想法是好的。它试图以尽可能少的费用来降低它。一个能够在诚实的无效尝试中幸存下来的想法是一个值得投资的想法。通过验证来确认他们已经想听到的内容的团队并不是在验证，而是在赢得掌声。

一个只有有限的真实用户群体的小型试点项目通常会进行长达数月的内部讨论。这也是公司发现隐藏成本的地方：与遗留系统的集成、支持、培训、维护，以及很少出现在初始估算中并影响实际预算的项目。

验证可以降低风险，而不是将风险归零。诚实地面对限制是值得的。

第一个风险是令人信服地验证了错误的问题。有影响力的赞助商可以引导对话找到您想要的答案。这就是为什么验证需要独立性：收集证据的人不可能是最想听到“是”的人。

二是精度不准确。具有漂亮数字的研究给人一种确定性的感觉，但产品决策更多地基于一致的定性信号，而不是最初夸大的指标。小心那些充满百分比的幻灯片，这些百分比经不起推敲。

三是文化。在质疑老板想法存在风险的组织中，验证就变成了戏剧。团队假装测试，每个人假装相信，只有当产品已经上市并且钱已经花完时，真正的学习才会到来。只有当公司尽早接受“不”的声音（包括来自提出该想法的人的声音）时，验证才有效。

还有数据和合规性问题。如果应用程序将收集客户或公民的信息，[LGPD1] 通过验证输入帐户，而不是在最后作为印章。较晚发现数据模型在法律上不可行的代价高昂，但这是可以避免的。

对验证最常见的反对意见是验证需要时间。在实践中，真正拖延创新的是构建了错误的东西并且必须重新开始。良好的验证是获得正确投资的最快方法，因为它消除了早期的赌注，这些赌注成本高昂，但收效甚微。

领导者在批准应用程序预算之前应该问的问题不是“构建成本是多少？”问题是“我们需要知道什么才能确信它值得建造，以及找出答案的最便宜的方法是什么？”任何学会问这个问题的人都会停止为孤儿产品提供资金，并开始为有证据的赌注提供资金。

如果您的公司即将投资一款应用程序，并且对话是从技术范围而不是业务问题开始的，那么可能值得首先暂停并验证。我的博客上还有关于验证和产品构建路线图的其他文本，我可以在这个决策点与任何人交换想法。