舞台搭好了，猴子還不會表演

有一個故事我很喜歡。

假設我們要讓一隻猴子站在高台上，背出莎士比亞。應該先搭高台，還是先教猴子？

高台比較容易。可以畫設計圖、買材料、安排施工，每天都有東西能拿出來看。有人問進度，也很容易回答：台已經搭好了，接下來就等猴子。

但如果猴子始終學不會呢？

我們完成了很多工作，卻沒有解決那個決定整件事能不能成立的問題。

這是 Astro Teller 在 Google X 提出的「猴子與高台」比喻，提醒團隊先處理最關鍵的不確定性，而不是把資源花在容易展示的進度上。原文來源

我想到的，不只是創業，也包括我們每天在做的產品與客戶專案。

很忙，不一定離答案更近

想做一個新服務，我們很快就會開始討論網站、介面、會員功能、後台、付款流程。

這些都需要做，也不是沒有價值。

只是，客戶真的需要這個服務嗎？它能不能幫客戶完成原本做不好的事情？客戶願不願意改變現在的做法？

這些問題可能還沒有答案，我們卻已經開始搭台。

因為做出東西比較安心。畫面能展示，功能能操作，工作項目能打勾。相較之下，去確認一個想法可能不成立，往往沒有那麼好看。

但我覺得，提早發現不成立，也是一種重要的進度。至少我們知道，不必再把後面的時間與成本一起投進去。

AI 讓舞台搭得更快，猴子的問題還是在

現在有 AI，很多東西確實可以更快做出來。

有些第一版，現在可以更快看到畫面。這很好，但也讓我們更容易跳過前面的問題：既然做得出來，那就先做吧。

可是，做得快，不代表做的是對的事情。

假設我們想讓 AI 協助處理客戶訊息，介面、通知、報表都能很快完成。但真正需要先確認的，可能是它能不能理解客戶的問題，分辨哪些可以回答、哪些需要交給人，以及交接後有沒有真的被處理。

如果這些還沒弄清楚，一個漂亮的後台，不會讓服務自然變可靠。

MVP 的重點，不在 MV，也不在 P，而在於這次究竟要做什麼實驗。產品做得小，不代表驗證了關鍵問題；舞台搭得快，也不代表猴子學得會。

先找出我們自己的猴子

我會先把問題寫得直接一點：

哪一件事如果不成立，其他東西做得再好，也沒有用？

如果不確定客戶願不願意用，就先找少量客戶，讓他們實際試一次，而不只是聽完介紹說「不錯」。

如果不確定能不能省時間，就拿一段真實工作流程比較。把人工修正、例外處理和後續交接也算進去，不只看 AI 產出的那幾秒。

如果不確定成本能不能負擔，就先跑小規模服務，把每次完成工作的成本記下來，不要等客戶增加後才發現，做得越多，負擔越重。

實驗之前，也要先說清楚：看到什麼結果，我們會繼續；看到什麼結果，我們要調整，甚至停下來。

不然，測試也可能變成另一座舞台。做了很多次，卻始終沒有任何結果能改變我們的決定。

先驗證，不是先隨便做

這也不是「先求有，再求好」的另一種說法。

可以先縮小範圍，但不能把實驗需要的基本品質一起省掉。測試本身如果不可靠，最後得到的答案也可能是錯的。

我們可以暫時不做完整後台，卻不能把訂單弄丟；可以先用人工協助服務，卻不能忽略客戶的資料與承諾。

要省的是這次還不需要的東西，不是讓這次實驗值得相信的條件。

我喜歡猴子與高台的故事，是因為它讓我重新看待「進度」。

不是今天完成了多少項目，而是我們比昨天更清楚：這件事能不能成立，接下來應該怎麼做。

舞台終究要搭。

但在把它搭得更高、更漂亮之前，我想先知道，猴子到底能不能表演。

— Adam｜metabiz 創辦人