"如果你对自己产品的第一个版本不感到尴尬，那你就发布得太晚了。" — Reid Hoffman 在Splits，我们遵循这种软件开发方法：先让它工作 → 再让它正确 → 最后让它快速。 顺序很重要。以下是我们在每个阶段交付中学到的经验：

让它工作 = 功能原型。 它应该是粗糙的。它应该是有点不稳定的。快速让用户看到它。 我们如何界定MVP： 1）列出我们认为可能对项目重要或相关的所有内容。 2）从这个列表中，我们能完成的*绝对最小*的内容是什么，以便拥有一个功能原型？

把它做好 = 修复所有损坏的部分。 在这个阶段进入市场时，要有明确的信号：持续的反馈，尽管存在明显的缺陷，但使用量仍在增长。 现在你已经赢得了投入更多资源的权利。

快速完成 = 优化性能。 老实说，我们仍在学习这个阶段。大多数团队目前处于“做好它”的模式 🤷‍♂️ 但这就是激励我们的灵感：

为什么这种方法有效： 顺序是策略。你今天学到的东西会影响你明天构建的内容。跳过某些步骤，你就没有解决问题所需的信息。 行动产生信息。但*有意*的行动会产生*更有用*的信息。

陷阱在于你试图在让它运作的同时让它变得正确。 不对。 “允许自己发布一些你知道不对的东西。” — @wminshew