我给大家讲个案例，这个案例其实在中国企业中特别常见
我的一个朋友最近挺郁闷的，他主导的一个新产品项目刚刚被公司叫停了，投入了大半年时间和不少资源，最后发现方向根本不对，市场完全不买账
他问我，项目失败了，现在该干什么
老实说，听到这事，我的第一反应是，这太常见了，几乎每个做产品的都会遇到吧，但后来仔细一想，又觉得不对劲，很多失败，其实本不该发生
就像他说的这个项目，围绕AI技术做探索，听起来挺前沿，但团队用的还是那套传统的瀑布式开发流程，需求、设计、开发、测试，一步接一步，按部就班地走
等到产品终于做出来，推到市场上去试，才发现用户压根不需要，或者他们理解的需求从一开始就是错的
这让我想起埃里克·莱斯在《精益创业》里反复强调的那个核心观点，对于高度不确定的创新项目，你得用最小可行产品去快速验证假设，而不是闷头造一辆没人要的“完美汽车”
换而言之讲，这个项目选择了错误的产品开发流程和方法。说白了，这就是用成熟软件开发的思维去做AI创新，焉能不败。这属于已知的问题，是一个原本可以避免的错误，
这显然是一个管理决策的失误，它暴露了这支团队的真正问题：他们做过软件开发，以为自己懂软件开发。但其实他们的产品管理知识并不系统，并不知道每种流程、方法的边界在哪里。也就是说表面上是项目失败，但实际上是团队在创新赋能上的缺失。
这就是中国企业创新的通病，没有对创新赋能就让员工去做创新的工作。这就像让一个从没学过开枪的士兵直接上战场，失败几乎是注定的
那么问题来了，仗打输了，接下来怎么办
大多数人，包括我那位朋友，第一念头肯定是复盘，开个会，大家讨论一下哪里做得不好，下次注意
但说实话，如果团队连最基本的产品创新方法论都没掌握，复盘能复出什么来呢，大概率就是互相指责，或者归咎于“市场变化太快”、“用户需求太难捉摸”这些似是而非的原因
这种复盘，除了让大家心里好受点，或者找个背锅的，真的有什么价值吗
在我看来，这时候最该做的，根本不是复盘，而是补课
军队打了败仗，不会就地解散，也不会只开个检讨会就完事，他们会退回后方，重新整编，加强训练，学习新的战术，补充弹药，然后才有机会赢回下一场战斗
对产品团队来说，这个“训练”是什么，就是系统性地学习如何做产品创新，如何管理不确定性，如何定义问题，如何验证假设
比如，是不是该了解一下什么是设计思维，什么是第一性原理，什么是用户故事地图，什么是增长黑客
这些东西听起来像理论，但在真实的创新项目里，它们就是实实在在的工具，能帮你少走很多弯路，少浪费很多资源
我见过不少团队，项目失败一次，就换一批人，或者换个方向继续蒙眼狂奔，结果就是一遍又一遍地掉进同一个坑里
相反，我曾接手过一个失败的团队，但我选择了让团队一起学习UCPM，让大家一起系统掌握产品管理知识，结果他们在学习中自己开始主动复盘，意识到许多抱怨别人的问题其实自己身上也存在，这时候改变就开始出现了。这支团队后来开发了一个非常成功的产品，现在已经成为公司最主要的核心产品。
但我还是想强调彼得·德鲁克说过的一句名言，管理的本质，不仅是把事情做对，更重要的是做对的事情
当我们缺乏判断“什么是对的事情”的能力时，无论我们执行得多努力、多完美，最终都可能走向失败
显然，下次万一你的项目也失败了，先别急着开复盘大会
不妨问问自己和团队，我们真的懂怎么做一个新产品吗，我们掌握的方法论，是适用于确定性的软件维护，还是不确定性的创新探索
有时候，承认自己“不会”，比假装“会了”然后重复犯错，需要更大的勇气，但也更有价值
毕竟，失败本身不是最可怕的，最可怕的是，我们从未从失败中学到任何真正有用的东西