"如果你對產品的第一個版本不感到尷尬，那麼你就發佈得太晚了。" — Reid Hoffman 在 Splits，我們遵循這種軟體開發方法：先讓它運行 → 再讓它正確 → 最後讓它快速。 順序很重要。以下是我們在每個階段發佈時學到的經驗：

讓它運作 = 功能原型。 它應該是粗糙的。它應該是有點不穩定的。快速讓用戶看到它。 我們如何界定MVP： 1) 列出我們認為可能對項目重要或相關的所有內容。 2) 從這個列表中，我們能完成的*絕對最小*的內容是什麼，以便擁有一個功能原型？

把它做好 = 修復所有的破損部分。 在這個階段進入市場時，要有明確的信號：持續的反饋，儘管存在明顯的缺陷，但使用量仍在增長。 現在你已經贏得了投入更多資源的權利。

快速完成 = 優化性能。 老實說，我們仍在學習這個階段。大多數團隊目前處於「做好它」模式 🤷‍♂️ 但這裡是驅動我們的靈感：

為什麼這種方法有效： 排序是一種策略。你今天學到的東西會影響你明天的建設。跳過某些步驟，你就沒有解決問題所需的信息。 行動產生信息。但*有意識的*行動會產生*更有用*的信息。

陷阱在於你試圖在讓它運作的同時讓它變得正確。 不行。 「給自己允許去發佈一些你知道不正確的東西。」 — @wminshew