【顧問觀察】⦨企業做 MVP 時，最難的可能不是測試，而是決定「要驗證什麼」

企業準備推出一項新產品或新服務時，起點通常不是「我們有哪些假設需要驗證」。

更常見的情況可能是：

• 創辦人看到一個市場機會。
• 業務發現客戶最近一直在詢問某件事。
• 公司累積了一項技術，覺得應該可以發展成新的產品。
• 團隊想到一個很好的服務方式，也相信它確實能替客戶解決問題。

於是公司很自然地開始往下一步走：

• 產品怎麼做？
• 價格怎麼訂？
• 要賣給誰？
• 行銷要怎麼說？
• 業務要怎麼讓客戶買單？

這些問題當然都需要回答。但企業一路往後思考時，有時候反而會跳過更前面的一層：

我們認為自己正在解決的問題，客戶也認為那是一個問題嗎？

甚至還可以再往前問：

客戶知道自己有這個問題嗎？

• 這個問題對客戶而言，嚴重到需要現在處理嗎？
• 客戶理解企業提供的方案與這個問題之間的關係嗎？
• 還是只有企業自己非常清楚「這個產品很好」，客戶卻還沒有理由認為自己需要它？

這些差異看起來很細，最後卻可能決定一項產品究竟是在回應需求，還是在努力說服市場接受一個已經做好的答案。

因此，如果把 MVP（Minimum Viable Product，最小可行產品）放回中小企業的經營情境來看，除了「先做一個比較小的版本」之外，也許還有另一個值得討論的問題：

下一筆錢、人力與時間投入以前，企業究竟需要先知道什麼？

本文在此並不試圖重新定義產品開發中的 MVP，而是想從中小企業的決策情境出發，討論：

當資源有限、資訊又不完整時，企業能不能透過 MVP，提早發現自己真正需要確認的是什麼？

<轉引本文／改編本文請標註作者（Hsiao-Hsuan Chang, 2026）並附上本文連結>

一、企業很容易從「這是好產品」，直接走到「怎麼讓客戶買」

一家企業準備推出新的 B2B 服務時，內部通常不會先坐下來討論：

「我們目前有哪些假設？」

更常出現的可能是：

• 「這個服務應該有市場。」
• 「客戶一定會需要。」
• 「現在大家都在做這個。」
• 「我們本來就有這項能力，只差把它包裝成產品。」
• 「這明明可以幫客戶省很多成本，客戶沒有理由不要。」

這些判斷不一定錯。

很多好的產品，本來就來自企業長期累積的產業經驗與客戶理解。但當「這個東西應該有市場」很快成為組織內部的共識，後面的工作就會開始圍繞著它展開。

• 產品開始設計。
• 行銷開始思考怎麼溝通。
• 業務開始想怎麼賣。
• 經營者開始估算可以創造多少營收。

這時候，整個組織可能已經從：「客戶有沒有這個問題？」

直接走到了：「我們要怎麼讓客戶買？」

可是中間其實還隔著很多問題。

客戶有沒有這個痛點？客戶自己知不知道？他認為這個問題重要嗎？重要到願意現在處理嗎？他能不能理解企業提供的方案和這個問題之間的關係？最後才是他願不願意付費？

因此，「客戶沒有買」這個看似簡單的結果，背後可能代表完全不同的事情：

• 沒有這個痛點。
• 有痛點，但沒有意識到。
• 知道有問題，但優先順序不高。
• 想解決，但不理解企業提供的方案。
• 理解方案，但認為價格高於價值。

這些情況最後都會呈現成：沒有成交。

但對於企業下一步該做的事情完全不同。

有時候企業會把所有「沒有成交」都解讀成：行銷還不夠、業務還不夠努力、客戶還不懂。

於是開始加廣告、改文案、做教育市場、增加業務獎金。

但也許還有一個值得先確認的可能：不是客戶還不理解企業的答案，而是

企業認為自己正在解決的問題，客戶是否也認為那是一個需要被解決的問題？

二、比起一次確認所有事情，也許更需要找出「哪一個假設最不能錯」

假設一家設備維修公司，累積多年技術經驗後，準備推出「設備預防維護顧問服務」。

公司認為：客戶最大的問題，是不知道如何做好預防性維護。於是開始設計服務流程、教育教材、診斷報告與報價方案。這些都很合理。

但真正接觸客戶之後，可能出現另一種情況。

現場工程師非常認同這項服務，甚至覺得公司早就應該導入。可是他沒有採購權。

真正掌握預算的工廠主管則認為：「設備現在又沒有一直壞，為什麼我要多花這筆錢？」

這時候需要處理的，就不只是企業的服務內容夠不夠完整。因為企業可能還沒有確認：

• 誰認為這是一個問題？
• 誰有權決定要不要解決？
• 這個問題對決策者而言有多重要？
• 重要到願意付多少錢？

而上述這些，其實都還是企業在投入以前需要確認的事情。但企業當然不可能等到所有問題都有答案，才開始行動。尤其對資源有限的中小企業而言，更重要的可能不是「把所有事情都研究清楚」，而是先判斷：

現在最需要確認的是哪一件事？如果這件事和原本想的不一樣，後面的投入是不是也會跟著改變？

例如，一家企業準備花三個月把新的顧問服務完整做出來，但目前其實還不知道：真正掌握預算的人，是否認為這個問題值得花錢處理。如果答案是否定的，那麼企業現在最需要處理的，可能就不是把服務流程做得更完整，而是先理解：

決策者在意的問題到底是什麼？現有的服務構想，有沒有回應到那個問題？

這時候，MVP 要驗證的也就不一定是「這個服務做得夠不夠好」，而可能是更前面的：

我們現在準備解決的問題，是否值得客戶採取行動？

三、MVP 不一定只是把產品做小，而是讓「最關鍵的未知」變小

談到 MVP，很容易聯想到比較簡單的產品版本。

• 完整產品需要十個功能，先做三個。
• 正式系統需要半年，先做簡易版本。
• 完整服務需要建立所有流程，先推出測試方案。

這些當然都可能是 MVP。

但產品變小，不一定代表企業面對的不確定性也跟著變小。

例如，一家傳統食品公司想推出新的健康食品系列。原本準備推出十種口味，後來決定：「既然不知道市場反應，那我們先做三種。」確實降低了第一次生產的成本。

可是如果這家公司最大的未知根本不是：「消費者喜歡哪個口味？」而是：「原本購買傳統食品的客群，會相信這個品牌有資格賣健康食品嗎？」

那麼十種變成三種，測試的可能還不是最關鍵的問題。企業也許更適合先透過既有會員、小規模預購、通路訪談或概念頁，確認消費者對品牌延伸的接受程度。

這也是為什麼「把產品做小」和「降低不確定性」並不完全是同一件事。

有時候企業急著測的是：客戶喜歡哪一個答案？（喜歡零食或健康食品）

更前面需要確認的卻可能是：客戶是不是正在問這個問題？（生產零食又生產健康食品？）

先知道要確認的是什麼，才比較容易知道應該怎麼測。

四、原本以為在測產品，最後發現的可能是「問題本身需要重新定義」

產品推出之後如果反應不好，企業很自然會開始找原因：

• 是不是功能不夠？
• 是不是價格太高？是不是業務不會賣？
• 是不是廣告沒有說清楚？
• 是不是品牌知名度不夠？

於是開始增加功能、調整價格、重做素材、增加廣告，或者要求業務更加努力推廣。這些當然都有可能是原因。

但還有另一種可能：企業正在努力優化一個答案，卻還沒有確認前面的問題是不是定義對了。

例如，一家中小企業想導入 AI 客服。

一開始設定的問題很直接：「客服人力成本太高，所以需要 AI 幫忙回答問題。」

公司開始比較系統、整理 FAQ、串接網站，甚至設定 KPI：AI 要處理多少比例的客服問題？

但在真正整理客服紀錄之後，可能發現：大量客服詢問集中在「訂單進度」、「交貨時間」與「庫存狀態」。問題不一定是客服回答得太慢。而是公司的訂單資訊散落在不同系統，客服自己也必須不斷向其他部門確認。

如果直接導入 AI，最後可能只是讓 AI 更快速地回答：「我們正在為您確認。」這時候，原本以為正在處理的是「客服效率」。真正浮現的卻可能是「後端資訊流程」。

MVP 在這裡產生的價值，就不只是確認 AI 客服好不好用。而是讓企業提早發現：原本的問題定義可能需要往前再看一層。

所以一次測試沒有證明原本的方案成立，不一定代表沒有價值。

有時候，發現自己正在解錯問題，本身就是非常重要的資訊。

五、對中小企業而言，「太晚發現」本身就是一種成本

對資源有限的中小企業而言，一個方向判斷錯誤所產生的成本通常非常具體。

• 可能是一名員工幾個月的工作時間。
• 一筆原本可以投入業務開發的預算。
• 一套買回來之後沒有真正使用的系統。
• 為了一項新服務增加的人力。
• 甚至是經營者幾個月最重要的注意力。

例如，一家公司花了 30 萬元建立新的電商網站。

網站準時完成、商品全部上架、金流、物流都串接好了。從專案管理角度來看，它是「完成」的。

但上線三個月之後，公司才發現：原本的 B2B 客戶根本不習慣直接在線上下單。真正影響成交的仍然是業務詢價、規格確認、交期協調與後續服務。

這時候問題就不是網站做得好不好。而是：公司在投入 30 萬以前，有沒有先確認「客戶願不願意用這種方式購買」？

因此，中小企業需要管理的不只是「專案有沒有做完」。還有：

企業是在投入多少資源之後，才取得足以重新判斷方向的資訊？

產品完成、系統上線、網站做好，當然都是進度。但每一次完成，也代表更多資源已經被投入某一個答案。

如果底層假設需要調整，完成度越高，後續改變方向的成本往往也越高。

六、從決策角度看，MVP 也可以是一個降低錯誤投入的過程

如果不從產品開發流程，而是從企業做決定的角度來看，MVP 可以放進另一條比較簡單的路徑：

問題辨識｜Problem Discovery

↓

問題拆解｜Problem Framing

↓

◆ 關鍵判斷｜What needs to be known first?

現在最需要先知道什麼？

↓

低成本驗證｜Minimum Test

用相對可承擔的方式取得資訊

↓

◆ 下一步判斷｜What does this change?

得到的資訊，改變了什麼？

↓

投入選擇｜Next Investment Decision

繼續投入／調整方向／重新確認／暫不投入

這條路徑和一般產品開發流程關注的事情不太一樣。

重點不是產品接下來應該開發到哪一個版本，而是：

企業在投入更多資源以前，還缺少哪一項足以影響決定的資訊？

例如，一家顧問型企業準備推出新的標準化服務。此時可以討論的事情很多：

• 服務內容怎麼設計？
• 價格怎麼訂？
• 網站怎麼呈現？
• 業務怎麼銷售？
• 流程能不能標準化？

但如果目前連「客戶是否認為這個問題值得另外付費處理」都還不確定，那麼企業也許不需要同時把後面的事情全部做完。

它可以先用一個相對簡單的方式取得資訊。而測試之後，更重要的也不只是「成功或失敗」，而是：

• 原本哪一個判斷被支持了？
• 哪一個判斷需要修改？
• 有沒有出現原本沒有看到的問題？
• 這些資訊是否足以支持下一筆投入？

如果客戶願意付費，但每一案都需要高度客製化，企業得到的就不只是「有人買」。

新的問題可能變成：這項服務還適合往標準化發展嗎？

如果使用者很喜歡，真正掌握預算的人卻不認為值得採購，那麼企業需要重新確認的，也可能不是產品功能，而是：企業原本認定的價值，是否也是決策者願意付費的價值？

所以在這個視角下，MVP 可以是一組訪談、一場工作坊、一份簡易工具、一次人工服務，也可能是一個尚未完整建立的服務方案。形式並不是這裡最想討論的事情。更值得問的是：

這一次驗證，讓企業少了哪一個未知？而這個未知的減少，有沒有改變下一步的投入判斷？

七、沒有得到「可以繼續」，不一定代表 MVP 失敗

企業花時間做測試，當然會期待得到正面的答案：

• 市場有需求。
• 客戶願意買。
• 方向是對的。
• 可以繼續投資。

但如果測試只能接受「原本的想法是對的」，它很容易變成替既定方案尋找支持證據的過程。

假設一家製造業者正在考慮開發新的環保材料。

公司原本預期：客戶有減碳需求，所以應該願意為低碳材料支付較高價格。

如果直接進入完整開發，後面可能牽涉研發、材料測試、設備調整、認證與業務資源。

但在正式投入以前，公司先拿初步規格與幾個主要客戶討論。

結果發現：客戶確實在意減碳。

可是採購端能接受的價格增加幅度非常有限。

這個結果不是：「永續產品沒有市場。」

而是得到了一個更精確的資訊：需求可能存在，但目前設定的成本與價格假設不成立。

接下來企業可以重新思考材料、製程、客群或產品定位。

所以一次 MVP 最後可能得到三種答案：

• 繼續。
• 修改之後再測。
• 現在暫時不要投入更多。

第三個答案看起來最不像「成功」。但如果它讓企業在投入大量研發、設備與人力以前發現問題，仍然可能是一個有價值的結果。

因此，評估 MVP 時，除了問：「最後有沒有把產品做出來？」

或許還可以多問：「這次測試，有沒有讓下一個決定變得更清楚？」

八、下一筆資源投入以前，可以先問五個問題

企業永遠不可能等到資訊百分之百完整才做決定。

市場會變。客戶會變。競爭條件也會變。

所以 MVP 不是為了消除所有未知，也不是為了保證企業不會失敗。

如果回到最前面的情境——當企業覺得自己有一個很好的產品、一項很好的技術、一個值得發展的新服務，準備開始投入資源以前，也許可以先問五個問題：

第一，我們到底想替客戶解決什麼問題？

先不要從產品功能開始，而是把企業認為自己正在處理的問題說清楚。

第二，客戶自己也認為這是一個需要處理的問題嗎？

他是否意識到？有多重要？現在需要解決嗎？誰最在意？

第三，我們現在認為是真的事情，有哪些其實還只是尚未確認的假設？

「客戶需要」、「客戶會買」、「這個人會決定採購」、「這個功能最重要」，都可能還只是推論。

第四，其中哪一個如果判斷錯誤，會讓後面的投入受到最大影響？

不是每一個未知都需要用一樣的成本確認。一句文案錯了很容易修改，但設備、人力、系統與長期合約投入之後，改變方向就完全不同。

第五，有沒有比直接做完整更低成本的方法，可以先取得足以支持下一步決策的資訊？

然後，再根據結果決定：繼續、修改，還是暫時不投入。

這五個問題不能保證企業一定找到成功的產品。

MVP 也不可能消除經營中的所有不確定性。

但它至少提供了一個機會：在企業還沒有投入太多以前，先確認自己和客戶是不是正在回答同一個問題。

因為很多時候，企業最焦慮的問題是：「我們明明做了一個很好的東西，為什麼客戶就是不買？」於是開始想辦法教育市場、增加曝光、調整價格、要求業務更努力。這些事情也許最後都需要做。

但在此之前，有沒有一種可能，不是客戶還不理解企業的答案，而是企業還沒有確認：客戶是否正在問同一個問題？

如果答案不同，接下來需要調整的，可能就不只是行銷。而是企業對產品、客戶，甚至對「自己究竟在解決什麼問題」的理解。

從這個角度來看，MVP 的價值也許不只是把一個產品做得更小。

而是讓企業在還有空間修改答案以前，先確認問題。