產品開發

兩週做完一個 MVP：我怎麼決定什麼不做

發佈於 2026-03-12 ．約 8 分鐘閱讀

我給自己的規則是：一個 MVP，兩到六週，做不完就砍功能，不延長時間。三年下來我發現，會爆掉的專案幾乎沒有一個是因為「寫得太慢」，全部都是因為在第三天默默答應了自己一個不該答應的功能。

這篇寫的是我實際用來砍範圍的方法。不是理論，是我在每個專案第一天真的會坐下來做一次的事。

先寫「一句話的失敗條件」

多數人開專案時會寫目標：「做一個幫報關人員檢查文件的工具」。這句話的問題是它永遠不會被違反——你做什麼都符合這個目標。

我改成寫失敗條件：

如果使用者上傳三份文件之後，還是得自己逐欄對照一次，這個產品就是失敗的。

失敗條件的好處是它會直接產生一份「必須做」的清單，而且清單很短。以上面那句話來說，必須做的只有：接受三份檔案、抽出可比對的欄位、把差異列出來。就這樣。

而「帳號系統」、「歷史紀錄」、「多語系」、「匯出 Excel」——這些東西不做，失敗條件都不會成立。所以第一版全部不做。

四道切割規則

寫完失敗條件之後，我拿四個問題去問每一個冒出來的功能。任何一題答「是」，就砍掉或延後。

規則一：這個功能是為了「第二次使用」而做的嗎？

歷史紀錄、儲存草稿、我的最愛、通知設定——這些全部都是為了讓人第二次回來用得更順。但 MVP 要驗證的是第一次有沒有價值。如果第一次沒價值，第二次根本不會發生。

這一條砍掉的東西最多，而且砍掉之後幾乎不痛。

規則二：這個功能可以用「人工」暫時代替嗎？

第一版的 GrantPilot 沒有任何提醒功能。使用者建立案件時填截止日，然後……就沒有然後了。

我當時的做法是自己每週看一次資料庫，手動寄信提醒那幾位早期使用者。醜，但它讓我用一週而不是三週知道了一件事：使用者根本不缺提醒，他們缺的是「一個案子到底卡在哪個節點」的可見性。如果我先花三週做排程與通知系統，那三週就是純浪費。

能用人工撐過去的功能，就先用人工撐。 前二十個使用者的規模，人工幾乎都撐得住。

規則三：這個功能的失敗，使用者會自己發現嗎？

會的話，就先不用做防呆。

ClearSync 的第一版沒有做檔案格式檢查。你丟一個 Word 檔進去，它就壞掉。但使用者會立刻知道「喔，不能丟這個」，然後換一個檔案。這個體驗很爛，但它不會讓使用者對「這個產品有沒有用」產生錯誤的判斷。

反過來，如果錯誤是靜默的——例如欄位對映錯了但報告照樣產出，使用者會以為文件沒問題——那就一定要在第一版做好。靜默錯誤會直接摧毀信任，而信任只有一次機會。

規則四：不做這個，我會不好意思給人看嗎？

這一題很重要，因為它是唯一一個承認情緒的問題。

大部分「捨不得砍」的功能，理由其實是面子，不是價值。深色模式、精美的載入動畫、漂亮的空狀態插圖——我很清楚它們對驗證假設沒有幫助，但沒有它們我就不想把連結傳給別人。

我的處理方式是：允許自己留一個這種功能，而且必須在其他所有事情做完之後才做。留一個是為了讓自己有動力把東西送出門；留兩個以上就是在自我欺騙。

一份真實的取捨清單

這是 ClearSync AI 第一版的清單，我原封不動貼上來：

十項裡面做了六項。第一版花了 11 天。

砍掉的東西後來怎麼樣了

這是最有意思的部分。清單上被砍掉的四項功能，一年後：

• 帳號登入：做了。但不是為了 ClearSync，而是因為做到第三個產品時需要一組共用帳號。
• 歷史查核紀錄：做了，但形式完全不同。早期使用者要的不是「我查過哪些」，而是「同一票貨改版之後，跟上一版差在哪」。如果我在第一版就做，我會做出一個沒人要的列表頁。
• 批次多票處理：到現在還沒做。問過的使用者裡，真正有這個需求的比例低於預期。
• 檔案格式檢查：做了，第一版上線後三天就補上，因為它便宜。

四項裡面，有一項永遠不需要，有一項如果先做就會做錯。這個比例每次都差不多，也是我持續相信這套方法的原因。

兩週的時間怎麼分配

我的大致節奏是這樣：

• 第 1 天：寫失敗條件、跑四道規則、列出取捨清單。不寫任何程式碼。
• 第 2–3 天：把最不確定的技術點先試出來。以 ClearSync 來說是 PDF 表格解析——如果這件事做不到，整個產品就不成立，那我寧可在第三天知道。
• 第 4–9 天：實作核心流程。介面先醜著沒關係，但流程必須從頭到尾能跑完。
• 第 10–11 天：自己當使用者跑十次真實資料。這一步幾乎每次都會發現一個根本性的誤解。
• 第 12–13 天：修那個誤解，加上規則四的那一個功能。
• 第 14 天：部署、寫產品頁、送出門。

注意第 10–11 天佔了兩天，只是「自己用」。這是我從失敗裡學來的——跳過這一步的專案，上線後第一週收到的回饋幾乎都是「我不知道這個要幹嘛」。

最後一件事

砍功能會讓人有罪惡感，好像交出了一個不完整的東西。但完整不是目標，可判斷才是。

一個做了六項功能的產品，如果沒人用，你可以很有把握地說「這個問題不夠痛」。一個做了二十項功能的產品沒人用，你什麼都不知道——可能是問題不痛，可能是介面太複雜，可能是那二十項裡有一項嚇跑了所有人。

範圍越小，得到的資訊越乾淨。這才是砍功能真正的理由。

文中提到的產品

其他文章

回到文章列表 →