商業計畫寫好了，哪些事情還只是我們相信？

商業計畫書裡，很多內容都是假設。

我們假設客戶有這個需求，願意付這個價格；假設供應商能交貨，團隊能完成；也假設客戶增加以後，收入會比成本成長得更快。

這些假設不一定錯。要做一件還沒做過的事情，本來就不可能一開始什麼都知道。

我擔心的不是有假設，而是寫進計畫之後，我們就忘了那是假設。

預估的訂單變成業績目標，預估的工時變成交付承諾，預估的需求變成擴編與採購的理由。大家開始照著計畫執行，卻沒有先確認：支撐這份計畫的幾個條件，究竟成立了沒有？

計畫應該幫我們看見未知

Rita McGrath 與 Ian MacMillan 提出的「發現驅動式規劃」，處理的正是這個問題。McGrath 在回顧這套方法時，明確提出：記錄假設、制定測試計畫，並隨著學習重新規劃，而不是努力證明原本的預測一定正確。作者說明

我認為，這才是商業計畫有用的地方。

不是把未來寫得很確定，而是讓我們知道：現在掌握了什麼，還不知道什麼，下一步要怎麼取得答案。

例如，「已經有客戶付費」是發生過的事；「其他客戶也會願意付同樣的價格」仍然需要確認。

「這次成功交付」可以證明我們在這次條件下做得到，但不代表同時接十倍的訂單，工時、品質與成本都能維持。

證據不是沒有價值，而是要知道，它支持到哪裡。

所以才需要 MVP，也需要試單

MVP 的重點，不在 MV，也不在 P，而在於你要做什麼實驗。

如果想確認客戶願不願意付錢，就不能只看他聽完介紹後有沒有點頭。如果想確認交付能力，就不能只看展示版本能不能操作。

Steve Blank 也指出，測試客戶、價格或功能，可能需要不同的 MVP；做出的東西必須對應想驗證的假設。作者原文

在實際生意裡，試單也是一種做法。

先用有限的數量，確認品質、交期、溝通與實際成本。如果出了問題，還有機會調整，不必一開始就承擔大量庫存或完整交付的壓力。

但一筆試單成功，也不代表所有問題都驗證完了。

它可能確認了這批貨能交，卻還沒確認客戶會不會再買；確認了少量生產的品質，卻還不知道量增加之後能不能維持。

每一次測試，都應該清楚知道自己回答了哪個問題，而不是只留下「成功了」三個字。

正式環境，不會讓假設自動變成事實

我尤其擔心一種情況：測試版本還沒弄清楚，就決定把規格加大、設備買齊，直接搬進正式環境。

看起來更完整了，問題卻可能只是被放大。

假設每筆訂單都需要大量人工修正，訂單增加後，修正的人力也會跟著增加。如果原本沒有把這些時間算進成本，營收變大，不一定代表生意變好。

假設服務成功，是因為有人一直在背後補救，那就需要知道補救了什麼、花了多久，以及這樣的做法能不能持續。不能只因為客戶最後收到結果，就認為整套流程已經成立。

Blank 在談新事業時，也區分了產品首次推出與商業模式得到驗證：產品出貨了，並不表示支撐生意的假設都已經通過檢驗。作者論述

正式上線當然可以取得新的證據。但環境叫「正式」，本身不是證據。

放大之前，先把測試講清楚

我會先把幾件事情寫下來：

• 我們假設什麼？ 不只寫「客戶有需求」，而是哪些客戶、在什麼情況下，需要完成什麼事情。
• 怎麼確認？ 看實際使用、付費、再次購買，還是交付時間與成本？觀察要對應問題。
• 這次承擔多少？ 先限制客戶數、訂單量、預算或測試時間，並安排出錯時的處理方式。
• 什麼結果會改變決定？ 哪些證據支持繼續，哪些結果需要調整，什麼情況下應該停止。

不必等到所有事情都確定，才採取行動。但也不能每次結果不如預期，就換一個說法，繼續按照原計畫投入。

如果任何結果都不能改變決定，那我們做的可能不是驗證，只是在替原本的決定找理由。

控制風險，不是降低基本要求

小範圍測試，不代表可以輕忽品質、資料安全或對客戶的承諾。

可以先不做完整後台，先由人工協助；但不能把漏單、錯帳或交接失敗，都說成「現在還是測試」。

我們要控制的是投入範圍，不是把能控制的事情也隨便做。

而且，就算某個假設曾經成立，也不代表永遠成立。Drucker 提醒，企業對市場、使命與能力的假設，必須持續接受檢驗，因為客戶與環境一直在變。Drucker Institute 官方改編教材

對我來說，商業計畫不是一張保證未來的紙。

它應該幫我們把相信的事情攤開，知道哪些已經有依據，哪些還需要測試，再決定下一步願意承擔多少。

真正危險的，不是計畫裡有假設，而是不知道那是假設，就把它放大成成本與承諾。

— Adam｜metabiz 創辦人