許多軟體創辦人失敗的原因很簡單：產品太晚才上線。他們花了好幾年閉門造車，結果第一次交到真實顧客手上就徹底瓦解。

Indie Hackers podcast 裡有許多這樣的故事。這個節目的宗旨是幫助聽眾從新創創辦人的錯誤中學習，但主持人 Courtland Allen 卻常常對這到底有沒有可能感到深深的焦慮：

……有些事情就算你講到口乾舌燥、講到臉都發青了，別人還是聽不進去，也無法真正理解你在說什麼，直到他們親自去犯錯，用最慘痛的方式才搞懂你的意思。

-Courtland Allen，Indie Hackers Podcast

我以前總想：「不會吧，Courtland。這也太沒效率了。我直接撿現成的教訓，才不要去犯那種代價高昂的錯誤，謝謝。」

從這篇文章的標題，你大概就猜到我的如意算盤沒打成了。

產品的構想

這個點子是在我盯著自己寫過最醜的程式碼時冒出來的。那是我去年做的一個食譜搜尋工具裡的程式碼。那個 App 從來沒有紅起來，但偶爾做一下還算有趣。程式碼庫中有個角落一直讓我很頭痛：食材解析。

舉例來說，給定像 "2 cups finely chopped red onions" 這樣的字串，App 必須判斷出 2 是數量、cups 是計量單位，以此類推：

一開始解析很單純，但隨著各種邊界案例不斷冒出來，邏輯變得越來越脆弱、越來越複雜。久而久之，這段邏輯退化成一座由正規表示式構成、令人抓狂的迷宮——這種處理文字的指令既強大又出了名的難以閱讀。

我很想把這一切砍掉重練，改用機器學習的解法，但那將會是個浩大的工程。我不可能為了一個完全不賺錢的網站上的小功能，投入好幾個月的開發時間。

然後，我靈光一閃：如果食材解析本身就是一門生意呢？如果這對我是個問題，那其他開發者肯定也為此苦惱。希望其中有些人是有賺錢的，而且如果我幫他們解決這個問題，他們會願意分一點錢給我。就這樣，Zestful，我的食材解析服務的點子誕生了。

那個稱不上 MVP 的 MVP

在精實創業的世界裡，大家常把「MVP」，也就是最小可行性產品掛在嘴邊。MVP 是點子最精簡的版本。你應該盡快把它做出來，交到潛在顧客手上，從他們的反應來判斷它是否真的解決了問題。

最常見的失敗故事之一，就是創辦人對自己的點子過度自信，因而忽略了打造 MVP。結果他們投入數個月甚至數年，做出一個根本沒人想要的完整產品。

做 Zestful 時，我確實打造了 MVP。我甚至預先定義好了驗收標準，以免自己掉進無止盡微調與改進的兔子洞裡。

投入大約 120 小時的開發後，我的原型就滿足了驗收標準。

然而，我又拖了兩個月才正式上線。這段時間，我都在寫更多的程式。

沒關係，這是為了銷售而寫的程式

你可能會好奇，為什麼我在 MVP 已經「完成」之後，還原地打轉了這麼久。以下是我那兩個月來的心路歷程總結：

第 1 天：已達成驗收標準

服務能跑了！但顧客只能在命令列上輸入複雜的指令才能使用。

在 Web 3.1 的時代，還要讓顧客受委屈去寫 curl 指令，怎麼說得過去？加個簡單的 HTML 前端，就能讓顧客直接在瀏覽器裡測試服務。

5 天後

基本的前端做好了，但在沒有任何說明的情況下，放一個孤零零的 HTML 表單在那裡感覺很奇怪。

我得在表單外圍建一個網站。不過這會是個超簡單的網站——只要一天就能搞定。

4 天後

太好了！服務有網站了。

……不過網站還沒有說明每個欄位的說明文件。我今天下午就能把它生出來。

2 天後

現在頁面太多了，導覽列在手機上會超出畫面。

我來讓導覽列支援響應式設計。用我的網頁框架 Angular，這應該只要一個小時就好。

8 天後……

這就像九頭蛇一樣。每當我完成「再加一個簡單的功能」，就會冒出兩個新的、非做不可的功能。最後，自從宣告程式完成以來已經過了兩個月，我竟然還什麼都沒上線，自己也感到難以置信。

這很重要，但可以等等再做

我非得上線不可了。然而，我的關鍵任務清單還是沒完成。我估計那些還要五天才能做完。

然後，一件有趣的事發生了。在承諾要盡快上線之後，我意識到「必須要有」和「上線前必須要有」是不一樣的。

一個例子是我的使用條款。如果我先上線，過幾天再補上會怎樣？最糟的情況就是萬一發生法律糾紛時，我會比較站不住腳，但在上線後短短幾天內就有人要告我的機率有多高？

別廢話，快上線

對於待辦清單上的每一項，我都問自己：「如果少了這個就上線，會怎樣？」用同樣毫不留情的標準檢視每一項任務後，就像檢視我的使用條款一樣，真正的上線檢查清單才浮現出來。不到 24 小時後，我就把 Zestful 發布到了 RapidAPI，一個 API 市集。我的服務上線了！

現在就是見真章的時刻了。我的服務已經準備好向真實顧客收費。我只需要說服他們掏錢購買。

我是為了逃避被拒絕才拖延上線嗎？

在「完成」和「上線」之間那兩個月的空窗期，有個朋友問我是不是害怕把產品拿給顧客看。那些拖延上線的任務，是不是只是在逃避被拒絕？

這個念頭我也曾閃過，但很快就否定了。我以前做過業務，每天打陌生開發電話，被拒絕 40 次。被拒絕才嚇不倒我。

上線當天，我坐下來寫第一封陌生開發信：寄給一位不認識我的食譜 App 開發者。我得解釋為什麼他們應該把我的食材服務整合進他們的 App。

我盯著空白的螢幕，整整半小時寫不出任何東西。我已經向朋友解釋過我的服務幾十次了，但這次不一樣。每當我想出一個可能的賣點，就會想像顧客毫不留情的反駁：

為什麼這值得你開的這個價錢？

這怎麼幫我增加獲利？

我為什麼需要你？

糟了。我確實害怕被拒絕。

一種不一樣的被拒絕

這跟做業務完全不一樣。那份工作是要我去賣光纖網路給企業，但光纖不是我鋪的，網路也不是我設計的。所以被拒絕時，我很容易就一笑置之。

現在，我賣的是自己創造的東西。而且，那是我寫的軟體。寫軟體是我自我認同中很重要的一部分。沒有其他事是我更擅長、也更引以為傲的。如果我把產品拿給顧客看，他們可能會想：「這東西不怎麼樣。你還敢拿出來賣，表示你覺得它很好。所以，你這個人也不怎麼樣。」

殘酷的現實

在寄出幾十封開發信、聊了幾次、卻一筆交易都沒成交後，我才恍然大悟，我已經成了那個花了數個月投入在一個顧客根本不想要的產品上的開發者。

有些企業確實用得上像我這樣的服務，但最需要它的那些，早就自己做了一套。剩下的則認為這是個不錯的服務，但就算一個月只要 20 美元，也無法說服自己掏錢。

而就在那時，我發現了策略中的致命缺陷。對我的顧客來說，最大的成本不是我每個月的月費，而是為了整合我的服務而修改他們 App 所需的成本。

除此之外，他們還得權衡增加一個外部依賴的成本。如果我的服務當機了會怎樣？他們的 App 會跟著掛掉嗎？還是他們得為我的服務故障時，打造一整套備援的運作模式？

我把順序搞反了

回頭看，我的流程完全反了。向顧客進行陌生開發是我最後一步，但我應該在寫下一行程式碼之前就先做。

一開始，我為自己先做產品的決定找了理由。顧客或許會對點子說好，但之後卻永遠不會真的掏錢買產品。我想要的「好」是真實的成交，也就是顧客透過購買服務來表示同意。

雖然這個邏輯現在想起來還是覺得合理，但我卻沒考慮到「不好」的價值。如果顧客在概念階段就拒絕了產品，他們在產品做好之後也不會改變心意。如果每個人都說不，那大概就是一條死路。

編輯：Samantha Mason。插圖：Loraine Yow。