在创业公司的奇妙世界里，最令人兴奋的事情很可能是开发你的MVp，或者说最低可行的产品。你脑子里有一个伟大的想法，你想把它摆在世人面前。一些全新的概念，你正在培育成为存在。它可以是你网站上的新功能，也可以是你正在提供的新产品，甚至是一家全新的公司。
从第一天起就一直萦绕在你脑海里的想法让这件事既令人恐惧又令人兴奋：这个想法现在已经越来越接近它的顶端，在发射日它几乎会消耗掉你。
如果我失败了呢？
说实话，你可能会以某种方式失败。也许会有一些让用户恼火的bug。或者也许收养率并不是你所希望的那样。有时是大调，有时是小调。
第一次尝试没有什么是百分之百成功的，但这并不意味着它是坏的。事实上，世界上最成功的技术和产品领导者都有自己的座右铭。
很快就会失败。
这似乎是一种自我挫败的说法，但实际上是对积极进展的肯定。当你很快失败的时候，那意味着你已经发现了什么不起作用，并且可以调整以尽快找到通往成功的道路。这可能意味着把你的想法一刀切，但在大多数情况下，这意味着你必须在这里或那里调整它，使之恰到好处。
但我们如何快速做到这一点？
没有人想把自己的想法冲进这个世界，直到它完善为止。我们想孵化它，直到它是百分之一百一十为每个人准备！
但是你看到这个逻辑的问题了吗？你在构建你认为完美的东西，而不是你的客户认为完美的东西。
别这么自私！
你的创业只有在你为你的客户或客户做的时候才会成功。如果你把一个产品的想法压在他们的喉咙里，拒绝给他们任何意见，那你就是在为自己做。我的朋友，那是自我陶醉。这也是消耗金钱、时间和资源的最快方法。
采用敏捷方法。
敏捷开发是当今初创企业界的流行语，这是有充分理由的。敏捷就是你所认为的敏捷。这意味着你要迅速地把一些东西摆在客户面前，听取他们的反馈并进行调整。通过采用这种方法，您可以逐步发布您的光荣想法，其中每个迭代都建立在原始MVp的基础上，再加上一轮客户反馈、使用数据、转换数据和任何其他帮助您跟踪成功的相关数据。
但你还是要精力充沛。
把你的开发风格称为“敏捷”并不意味着你有权在第一轮中提出你想要的任何东西，然后要求反馈。如果你没有推出一个精益产品，你可能在每一次迭代中做的太多了。记住我们在这里的工作：最小可行产品。
在测试和发布之前，您应该在每个迭代中尽可能少地进行工作。如果你正在为你的应用构建一个新的特性，比如说一个简单的按钮来分享这篇文章，你的MVp应该尽可能的小一些，让用户参与进来。我再也做不到了，除了一个按钮上写着：“共享此文章。”
它看起来不错，放在一个合适的位置，但就是这样。如果没有人点击它，我在第一次迭代中失败了，人们可能不想要它。如果人们点击它，太好了！现在我可以通过在他们的个人资料中建立一个他们最喜欢的文章的列表来扩展他们的功能，并且我可以不断迭代，直到我根据他们喜欢共享的内容为他们生成特定的内容。
如果我完全从第一天开始建立，我会把所有的时间和金钱花在人们甚至不想使用的东西上。
开发商的困境。
现在，产品人员、项目人员和管理人员都喜欢MVp。
开发商，没那么多。
作为一个开发者，我明白。我们是完美主义者，我们不想在这里和那里偷工减料，只是为了得到一些东西，因为我们知道未来会发生什么：老板会说：“这太好了！不要回去清理代码和修复那些恼人的bug，继续新的迭代！”
这是一个现实，作为老板，你必须划出一条界限，在那里你清除了所有开发过程中不可避免的bug，在那里你要继续构建更多的特性。任何充满bug的东西都不会引起用户的共鸣，而另一方面，任何在开发中完善的东西都不会被发布。
如果您从一开始就计划好这一点，那么您就可以拥有一个干净的代码库，它具有一些基本的测试覆盖率，并且可以在每次迭代中以最少的开发人员费用轻松地进行扩展。这将有助于减轻开发团队在达到其严格的完美水平之前必须释放的痛苦。
缓慢的推出。
这就是事情变得有趣的地方。如果你已经有了一个庞大的应用程序或网站，你可能不想向大众发布一个微小的MVp特性。
没问题。在开始编写一行代码之前，您可以联系您的用户，让他们成为beta测试人员。
我们刚刚一起创建了一个多么有价值的用户群。
如果你有一部分用户选择为你测试新功能，你可以运行一些技术魔术，把他们标记在你的数据库中某个有意义的地方作为beta用户。
在编写代码时，可以使用以下简单语句：
如果(User.betaUser ==真）
{showNewFeature（）}
现在你有能力推出功能，只对那些想要这些早期宝石，你可以直接与他们交谈的反馈。我在现实世界中做过，每次都有出色的成绩，我总是向我建议的初创公司推荐这一点。
在我所有的经验中，在快速发展的科技初创企业中，甚至在拥有数亿用户的企业级公司中，快速失败是产品成功最安全的途径。还有其他方法可以达到这个目的，但从时间和现金流的角度来看，这消除了最大的风险。