领先的产品努力伴随着津贴和相应的价格。 要付出的代价之一就是应对失败。 鉴于互联网时代的大规模分销渠道和近乎即时的客户群，生与死的周期大大加快了。 今天有新产品，明天有车库销售。
在产品上，观众很少像在产品上那样投入情感。 因此，对于建筑商而言，摆脱坠机事故并不像为仁慈的目击者庆祝奇观那样容易。
第一步是了解范围。 失败了—是测试，功能或产品？ 当我们仅有的是结果而不是事件序列时，很难对失败进行装箱。
第二步是收集症状。 我们如何知道“这”是失败—领先指标，代理指标或客户反馈？ 以我的经验，失败的定义通常比成功的定义更重要。
第三步是加深了解。 这怎么发生的？ 注意不要有深奥的答案。 诸如“我们没有花足够的钱”之类的答案适合所有问题，但很少是正确的问题。
第四步是最艰难的-接受它。
糖衣加剧了这个问题。 分享所收集的理解并使利益相关者进入同一页面。
当您在尝试时，请测量您的感受。 如果您感到惊讶，您可能会错过阅读标志的机会。 我有很多失败的经历，但是我们的团队很少措手不及。 我们可能会以度量标准停滞或用户反馈不佳导致失败的形式看到风暴云。 这是我们值得骄傲的。
总结： 定义故障范围-A / B测试？ 特征？ 产品？ 战略？
一旦证明了失败，这意味着什么？ 真的是失败吗？
吉布森·比德尔（Gibson Biddle）在视频演讲中说：“对策略要有耐心，对策略要紧”。 从那里拿一张叶子，如果战术没有奏效，请尝试其他方法。 如果该策略不起作用，则进行透视。
让我用一个例子来支持那个人。 我的最初产品之一-用于客户支持代理的信息仪表板失败了。 我们能够重构代码并将其作为聊天机器人公开给最终客户。 谈论回收，是吗？
到现在为止已经很明显了，随着我们缩小上下文范围，失败的重要性降低了。 A / B测试失败不如功能失败。 失败的策略并不像无关紧要的问题陈述那样糟糕。
较轻松地说，最近，当我的一款产品出现故障时，我的朋友发送了以下模因：
带走： 思考一下失败在更大范围内的含义。
走出一个没有学到任何东西的失败，这就是整个问题的关键。 你知道会更糟吗？ 学习错误的教训。
以以下示例为例：一个团队正在反思为什么他们不能实现季度路线图的50％以上。
情况1：为什么我们没有按计划执行？
我们应该更快地执行。
情况2：为什么我们没有按计划执行？
我们咀嚼的东西超过了我们的执行能力。
为什么会这样呢？
我们没有将故事范围扩大。 任务变化太频繁了。
…
显然，在第一种情况下，没有学习正确的课程，因为没有提出正确的问题。 我们如何提出正确的问题？
业务失败—远见与战略
商业模型画布有助于了解解决问题的高级方法以及我们如何将其推向市场。 在所有活动部件的环境中布置解决方案。 查看已做出的决定。 我们没有选择正确的客户渠道吗？ 我们的成本结构中有哪些因素被证明是有害的？
如果您使用过验证板，那么现在是查看假设和测试方法的好时机。
执行失败-UX和Engg
深入了解期望与现实。 我们是否承诺会超过咀嚼的范围？ 我们是否忘记了最好的公司会占用约50％到60％的带宽。
绘制事件时间表。 甘特图，燃烧率图等有助于轻松识别与过程相关的故障。 征集标有“什么”和“为什么”的问题。 与使用“谁”的问题相比，他们对我的内省提供了更多的见解。
进行分类的另一种方法是从资源角度进行理解。 假设存在市场与产品的契合关系，那么什么能够弥补执行方面的差距呢？ 我们应该在哪里争取更多的资源- 人员，金钱或时间 ？
失败后的UX研究与执行之前一样重要。 最讨厌产品的客户可能是了解导致失败的用户挫败感的最佳选择。
带走： 从失败中学习团队可操作的经验教训。
如果我在失败结束时没有感到心碎，那我可能就是失败的原因。
考虑到爱问题的驱使，PM往往会亲自承担失败的责任。 我们如何不使失败成为个人原因？ 首先要以失败本身为目标。 前面描述的步骤可以帮助您。 第二个要了解的是，我们很少有超过50:50的成功几率。 PM的主要作用是通过数据和直觉来提高这些几率。 第二部分，需要时间。
你会犯错误。 那是不可避免的。 诀窍是不要让这些错误破坏您将来的决定。
带走： 起床，除尘并开始前进。
