在这篇文章中，我想讨论这么多产品失败的根本原因。
我看到大多数公司的基本工作方式相同，我不禁注意到，这与最好的公司实际工作方式并不接近。
让我提醒你，这个讨论可能会有点令人沮丧，特别是如果它触及要害，所以如果是这样的话，我会请你坚持在那里。
让我们首先从绝大多数公司仍然用于创建产品的过程开始。我会尽量不评论;让我先描述一下这个过程：
一切从想法开始。在大多数公司中，他们来自高管、关键利益相关者或企业主，或大客户（或潜在客户），但无论如何，总有一大堆事情需要我们去做。
现在，大多数公司都希望将这些想法按优先级排列成路线图，他们这样做的主要原因有两个。首先，他们希望我们先做最有价值的事情，其次，他们希望能够预测事情什么时候准备好。
为此，几乎总会有某种形式的季度或年度计划会议，在会议上领导们考虑想法并协商产品路线图。但为了区分优先级，他们首先需要为每个项目提供某种形式的业务案例。
有些公司做正式的商业案例，有些则是非正式的，但无论哪种方式，归根结底都需要了解关于每个创意的两件事:1)它能赚多少钱?2)要花多少钱或时间?这些信息会被用来制定路线图，通常是下个季度的路线图，但有时会长达一年之久。
在这一点上，产品和技术组织有它的行军命令，他们通常从最高优先级开始工作。
一旦一个想法进入列表的顶部，要做的第一件事是让产品经理与利益相关者交谈，并充实想法，并想出一套"要求"。
这些可能是用户情景，或者它们可能更像某种形式的功能规范，但它的目的是与设计人员和工程师沟通需要构建的东西。
一旦需求收集起来，用户体验设计团队（假设公司拥有这样的团队）被要求提供交互设计、视觉设计以及物理设备中的工业设计。
最后，要求和设计规范使工程师。这通常是敏捷最终进入画面的地方。
无论如何，工程师们通常会将工作分解成一组迭代，在Scrum过程中称为"冲刺"。因此，也许它需要1-3个冲刺建立的想法。
希望 QA 测试是这些冲刺 （sprint） 的一部分， 但如果没有， QA 团队将跟进此测试， 以确保新想法像广告宣传的那样工作， 并且不会引入其他问题 （称为回归）
一旦我们从 QA 获得绿灯，新想法最终将部署到实际客户。
在绝大多数我第一次见面的公司，无论大小，这基本上是他们多年以来一直持续的工作方式。然而，同样是这些公司，却不断抱怨缺乏创新，以及从想法到客户手中需要很长时间。
你可能会认识到，虽然我提到敏捷，虽然今天几乎每个人都声称自己是敏捷，但我刚才描述的是非常瀑布的过程。公平地说，对于工程师来说，他们通常会在更广阔的瀑布环境下尽可能多地进行敏捷开发。
好吧，所以大多数团队可能都是这么做的，但是为什么这一定是造成这么多问题的原因呢？
我现在想做的是把这些点联系起来，告诉你们为什么这种非常普遍的工作方式导致了大多数产品的失败。
现在我可以花一整天的时间来谈论这个过程的问题，但是我在这里要做的是分享我认为在这种工作方式中“十大”最严重的问题。需要澄清的是，我认为这十个问题都是非常严重的问题，任何一个问题都可能使一个团队出轨，但实际上很多公司都有大部分甚至所有这些问题。
让我们从最顶端开始——想法的来源。这种模式导致了销售驱动的特价产品和利益相关者驱动的产品。关于这个关键的话题还有很多，但现在我只想说，这不是我们最好的产品创意的来源。这种方法的另一个后果是团队缺乏授权——在这个模型中，他们只是在那里实现。雇佣兵
接下来我们来谈谈这些商业案例中的致命缺陷。现在要澄清的是，我实际上是支持做商业案例的，至少对于需要更大投资的想法。但在这个阶段，大多数公司为了制定一个优先顺序路线图而采取的方式真的很荒谬。这是为什么。还记得每个业务案例的两个关键输入吗?你能赚多少钱，要花多少钱?嗯，冷酷的事实是，在目前阶段，我们没有任何线索，我们不能知道。
我们不知道我们能赚多少钱，因为这在很大程度上取决于解决方案的好坏。如果团队做得很好，这可能会非常成功，并真正改变公司的进程。另一方面，事实是，许多产品的创意最终完全没有成果。这并不是夸张的效果。真的什么都没有。在任何情况下，关于产品最重要的一课就是知道我们不知道的东西，在这个阶段我们只是不知道我们能赚多少钱。
同样，我们也不知道建造它的成本。在不知道实际解决方案的情况下，这对于工程学来说是很难预测的。在这个阶段，大多数有经验的工程师甚至都拒绝给出估计，但有些人迫于压力，只能按照旧的“t恤尺寸”妥协——只要告诉我们这是“小号、中号、大号和特大号”就行了。
但是公司真的想要那些优先的路线图，为了得到一个，他们需要某种系统来评估想法，所以人们玩商业案例游戏。
- 接下来还有一个更大的问题。公司对他们的路线图非常兴奋。我见过无数的路线图，其中绝大多数本质上都是按优先级排序的功能列表。营销活动需要这个特性。销售人员需要为新客户提供此功能。有人想要一个贝宝集成。你懂的。
但问题是，这可能是最大的问题。我称之为“关于产品的两个难以忽视的事实”。
第一个事实是，我们至少有一半的想法是行不通的。一个想法不成功的原因有很多。最常见的是，客户对这个想法并不像我们一样感兴趣。所以他们选择不使用它。有时他们想使用它，但他们尝试了，它是如此复杂，它只是比它的价值更多的麻烦，最后的结果是一样的-用户不选择使用它。有时，问题是客户会喜欢它，但构建过程比我们想象的要复杂得多，我们决定我们根本没有时间和金钱来实际交付。
所以我向你保证，你的路线图中至少有一半的想法不会实现你的希望。顺便说一句，真正优秀的团队会认为至少有四分之三的想法不会像我们希望的那样实现。
如果这还不够糟糕，那么第二个不方便的事实是，即使那些被证明具有潜力的想法，通常也需要几次迭代才能实现该想法，从而真正交付必要的业务价值。我们称之为“时间到金钱”。
关于产品，我学到的最重要的一点是，无论你多么聪明，都无法逃避这些事实。我有幸与许多真正优秀的产品团队一起工作。真正的区别在于你如何处理这些事实。
接下来让我们谈谈产品在这个模型中的角色。事实上，我们甚至根本不会把这个角色称为产品。这是项目管理的一种形式。在这个模型中，更多的是为工程师收集需求并记录它们。现在我假设这距离现代产品管理有180度的距离。
设计的角色也是如此。现在要获得设计的真正价值已经太迟了，而我们所做的大部分事情就是我们所说的“猪身上的口红”模型。损害已经造成，现在我们只是试图给混乱涂上一层漆。用户体验设计师知道这样做不好，但他们会尽量让它看起来更好、更一致。
也许在这种模式中最大的错失的机会就是工程技术的引入太迟了。我们说，如果你只是让你的工程师来编写代码，你只能得到他们一半的价值。产品的小秘密是，工程师通常是创新的最佳来源，但在这个过程中，他们甚至没有被邀请参加聚会。
不仅工程引入得太迟，而且敏捷的原则和关键好处也太迟了。以这种方式使用敏捷的团队可能获得了敏捷方法实际价值和潜力的20%。你真正看到的是敏捷交付，但组织和环境的其余部分却绝非敏捷。
整个过程是以项目为中心的。公司通常为项目提供资金，为项目提供人员，并推动这些项目在公司内部进行，最终启动项目。不幸的是，项目是产出，而产品完全是结果。可以预见，这个过程会导致孤立的项目。是的，有些东西最终发布了，但它没有达到它的目标，所以真正的重点是什么?无论如何，这是一个严重的问题，与我们需要如何构建产品相去甚远。
旧的瀑布流程的最大缺陷一直是，并且仍然是，所有的风险都在最后。这意味着客户验证发生得太迟了。
你可能听说过精益创业方法，它是替代方法的核心。关键的原则是减少浪费，而最大的浪费形式之一就是设计、构建、测试和部署一个特性或产品，却发现它不是所需要的。具有讽刺意味的是，许多团队认为他们正在应用精益原则，然而他们却遵循了我刚才描述的这个基本过程。然后我向他们指出，他们实际上是在用一种我们知道的最昂贵，最慢的方法来试验想法。
- 最后，当我们忙于完成这个过程并浪费我们的时间和金钱时，最大的损失通常是组织本来应该做的事情的机会成本。我们无法收回时间和金钱。
对我来说，这么多公司花了这么多时间和金钱，却得到的回报这么少，一点也不奇怪。我警告过你这可能会令人沮丧。
好消息是，我向你保证，最好的团队不会像我刚才描述的那样运作。
我写过很多关于优秀团队如何工作的文章。产品发现是我们找到解决问题的方法。Discovery是产品、用户体验设计和工程之间的一种积极的、持续的协作。持续发现和持续交付是并行发生的。路线图上的特性(输出)被需要解决的业务问题(结果)所取代。目标是产品/市场适配。
如果您的公司仍然在运行这个老旧的、过时的流程，那么希望您能对此有所了解，并开始向未来过渡。希望在你发现自己被一个比你更快更有效的初创公司或竞争对手打断之前，你可以这样做。
