新創驗證框架：12個專案教會我哪些證據真正重要

CB Insights分析了101份新創公司事後檢討報告，發現42%的失敗原因是市場不存在需求。我親身經歷了同樣的失敗模式——只是規模較小：我把SureInsure（一款保險分析工具）開發到功能完備，卻從未問過任何使用者是否需要這個產品。沒有人需要。開發花了三週。而原本能省下這三週的驗證工作，只需要一個下午。¹這屬於更廣義的品味基礎設施，它決定了我如何判斷一件事究竟值不值得動手去做。

TL;DR

新創驗證遵循特定的順序：需求性（人們想要這個解決方案嗎？）、可行性（團隊能打造這個解決方案嗎？）、以及永續性（這個解決方案能支撐一門生意嗎？）。在9個月內推出12個專案之後——這段歷程後來被Past Year Review確認為我職涯中能量最充沛的時期——Ace Citizenship、Return (941)、ResumeGeni、Banana List、Water、Reps、Design Gallery、Sorting Visualizer、Starfield Destroyer、SureInsure、amp97，以及我的個人網站——我親身經歷了每一種驗證反模式。那些在開發前先做驗證的專案上線更快，也找到了使用者。那些先開發再驗證的專案，則讓我付出了昂貴的代價。

---

我的驗證成績單

專案	開發前是否驗證？	結果
ResumeGeni	是（到達頁面＋候補名單）	活躍使用者、有營收
Ace Citizenship	是（社群研究＋訪談）	使用者持續成長
個人網站	部分（內容有驗證，設計沒有）	Lighthouse 100/100分，穩定流量
Banana List	否（解決自己的需求）	對我有用，但無市場吸引力
SureInsure	否（先開發到功能完備）	零使用者，已擱置
Sorting Visualizer	否（週末專案）	作品集展示，而非產品

模式非常明顯：那些在寫程式碼之前投入驗證證據的專案找到了使用者。那些先開發再驗證的專案從未產生成果。²我用來把關程式碼品質的證據閘門，在不同的尺度上貫徹著同樣的原則：先有證據，才有投入，絕不能反過來。

---

驗證順序

為什麼順序很重要

工程師預設先驗證可行性：「我們能打造這個東西嗎？」產品經理預設先驗證永續性：「我們能從這個東西賺錢嗎？」兩者都跳過了那個導致42%新創公司失敗的問題：「到底有沒有人真的想要這個東西？」³

正確的順序是先測試驗證成本最低的假設：

1. 問題驗證（這個問題是真實的、令人痛苦的嗎？）
2. 解決方案驗證（提出的解決方案能解決這個問題嗎？）
3. 通路驗證（能觸及目標客戶嗎？）
4. 營收驗證（客戶願意付費嗎？）
5. 規模驗證（單位經濟效益在規模化後成立嗎？）

每個階段的測試成本都比前一個階段更高。跳過步驟會浪費資源去測試昂貴的假設，而這些假設依賴的是尚未驗證的低成本假設。同樣的原則也主導著決策時機：分析的投入應與逆轉成本成正比，並且永遠先測試成本最低的假設。

---

我跳過步驟的專案

SureInsure：功能完備的陷阱

我打造了SureInsure——一款由LLM驅動的保險保單分析工具——因為我覺得保險文件很難理解。我的驗證方法：沒有。我假設自己的個人困擾可以推論為市場需求。

三週的開發產出了一個能運作的工具，能夠解析保險保單、標示保障缺口，並用白話解釋除外條款。技術層面運作正常。問題在於：保險保單持有人並不會主動尋找分析工具。痛點是真實的，但屬於潛伏性的——人們在理賠失敗之前不知道自己的保障不足。再好的產品品質也無法解決潛伏痛點的通路問題。

驗證本可揭示的事實： 與十幾位保險持有人的對話就能發現，沒有人搜尋「保險保單分析器」。問題發生在理賠時，而非保單檢閱時。通路（搜尋）與問題發生的時機（危機時刻）不匹配。⁴

Banana List：解決自己的需求

我打造了Banana List（一款SwiftUI + SwiftData購物清單應用程式），因為我想要一個特定的工作流程：快速擷取、iCloud同步，其他什麼都不要。驗證來自我自己的使用——這對於為自己打造的工具是有效的，但不會產生任何市場證據。

Banana List運作正常。我每天都在使用。這款應用程式完美地服務了一位使用者。錯誤不在於打造了這款應用程式，而在於假設「我想要這個產品」可以推論為「市場想要這個產品」。我的使用驗證了可行性和個人需求性，但對於市場需求性或通路完全沒有驗證。

---

我先做驗證的專案

ResumeGeni：先做到達頁面，再寫程式碼

ResumeGeni始於一個問題：求職者是否願意為針對ATS系統最佳化的AI生成履歷付費？在寫任何應用程式碼之前，我建立了一個描述價值主張的到達頁面，並加上了候補名單表單。

證據如下： - 透過Reddit和LinkedIn的定向貼文，2週內獲得340個電子郵件註冊 - 12位使用者回覆詢問「什麼時候可以使用產品？」 - 3位使用者表示願意付費取得早期使用權

候補名單驗證了需求性（人們想要針對ATS最佳化的履歷）和通路（Reddit/LinkedIn上的求職者社群）。只有在證據通過我的門檻之後，我才投入開發FastAPI後端、HTMX前端和LLM整合。⁵

Ace Citizenship：先做社群研究

Ace Citizenship（一款公民考試備考應用程式）始於社群研究，而非程式碼。我花了兩週時間在公民備考論壇、subreddit和Facebook社團中觀察： - 人們最常提出什麼問題 - 他們對現有解決方案有什麼抱怨 - 他們希望有什麼工具存在

研究揭示了一個缺口：現有的備考應用程式涵蓋了內容，但沒有涵蓋應試策略。策略缺口成為了產品的差異化優勢。只有在研究產出了一個現有產品未能解決的明確差異化優勢之後，開發才正式開始。⁶

---

30天框架（經驗淬煉版）

第1週：問題驗證

方法： 與10至15位潛在客戶進行結構化訪談。不要描述解決方案。專注於問題空間。

真正有效的問題： - 「請帶我回顧您上次遇到[問題]的經過。發生了什麼事？」 - 「您嘗試了什麼方法？哪些有效、哪些失敗了？」 - 「您目前花多少時間或金錢在處理[問題]上？」

證據產出物： 問題頻率與嚴重性矩陣。如果15位受訪者中少於7位將問題描述為頻繁（每週以上）且痛苦（花費金錢或時間在變通方案上），則問題缺乏足夠的市場拉力。⁷先有證據、才有投入的這條原則，同樣主導著品質迴圈：沒有產出物支撐的主張算不上證據。

第2週：解決方案驗證

方法： 向同一批受訪者展示解決方案概念（線框圖、到達頁面或口頭描述）。衡量反應強度，而非禮貌程度。

強烈訊號： 「什麼時候可以使用產品？」「可以付費取得早期使用權嗎？」「讓我介紹我的同事給您，他需要這個解決方案。」

微弱訊號： 「蠻有趣的。」「看起來不錯。」「我大概會試試看。」SureInsure時我從朋友那裡聽到了這三句話。沒有一位轉化為實際使用。

證據產出物： 承諾率。如果15位中少於3位採取了具體行動（註冊、付訂金、轉介），則解決方案與問題的匹配度不夠強。⁸

第3週：通路驗證

方法： 進行兩個小規模的客戶獲取實驗。每個通路花費200至500美元，測試是否能觸及目標客戶。

以ResumeGeni為例，我測試了兩個通路： - Reddit求職者社群：340個註冊，花費$0（有機貼文） - LinkedIn定向內容：45個註冊，花費$150（每次註冊$3.33）

Reddit勝出。通路驗證告訴我應該在哪個通路投入持續的客戶獲取資源。⁹

第4週：營收與單位經濟效益驗證

方法： 預售產品或接受早期使用權付款。

證據產出物： 合格潛在客戶到付費客戶的轉換率。如果B2B低於2%或B2C低於0.5%，則價值主張需要在投入正式開發之前進行修訂。¹⁰

---

我親身實踐過的驗證反模式

問卷調查陷阱

問卷調查衡量的是表述偏好。客戶訪談和承諾行為衡量的是顯示偏好。一份顯示80%「會使用產品」的問卷，轉化為實際採用大約只有5%。我在SureInsure上學到了表述偏好與顯示偏好之間的落差：每個朋友都說「聽起來很實用。」產品上線後，沒有任何一位朋友使用。¹¹

創辦人受眾問題

創辦人如果只在個人人脈圈內做驗證，會得到偏誤數據。心智的複利描述了來自多元來源的知識，如何比來自同質圈子的知識更有效地複利累積。朋友提供的是支持性回饋，無法預測市場行為。對陌生人的冷觸及能產生更高品質的驗證數據，因為陌生人沒有社交動機去鼓勵您。

我的ResumeGeni驗證之所以成功，是因為註冊來自Reddit上的陌生人，而非朋友。我的SureInsure「驗證」之所以失敗，是因為我只問了認識我的人。¹²

---

關鍵要點

給創辦人： - 在可行性之前先驗證需求性；最常見的失敗模式是打造了沒有人想要的產品，而非打造了無法運作的產品 - 衡量承諾行為（註冊、訂金、轉介），而非口頭上的熱情；禮貌性的興趣無法預測購買行為 - 一個帶有候補名單的到達頁面只需一個下午；開發到功能完備則需要數週甚至數月

給加入新創公司的工程師： - 在投入技術架構之前，先要求查看驗證證據；正確的技術投資取決於哪些假設已經被驗證 - 以學習速度為目標打造原型，而非以生產品質為目標；第一版的目的是產生證據，而非大規模服務客戶

---

常見問題

新創驗證的正確順序是什麼？

正確的順序是先測試驗證成本最低的假設：（1）問題驗證（問題是否真實存在且令人痛苦？）；（2）解決方案驗證（提出的方案是否解決了這個問題？）；（3）通路驗證（能否觸及目標客戶？）；（4）營收驗證（客戶會付費嗎？）；（5）規模驗證（單位經濟模型在規模化後是否成立？）。工程師預設先看可行性，產品經理預設先看永續性，但兩者都跳過了需求性——而正是需求性問題導致42%的新創公司失敗。

如何區分強驗證訊號與弱驗證訊號？

強訊號總是伴隨著承諾行為：「我什麼時候可以使用？」「我能付費取得早期使用權嗎？」「讓我把需要這個方案的同事介紹給您。」弱訊號則只是禮貌性的熱情：「挺有意思的。」「看起來不錯。」「我可能會試試。」作者在SureInsure專案中從朋友那裡聽到的都是弱訊號，沒有一個轉化為實際使用。相對地，ResumeGeni從Reddit上的陌生人那裡取得了強訊號：340次註冊，以及3個早期使用權付費意向。

什麼是創辦人受眾問題？

創辦人如果只在個人人脈圈內做驗證，會得到偏誤數據，因為朋友提供的支持性回饋無法預測市場行為。對陌生人的冷觸及能產生更高品質的驗證數據，因為陌生人沒有社交動機去給予鼓勵。作者的ResumeGeni驗證之所以成功，是因為註冊來自Reddit上的陌生人；而SureInsure的「驗證」之所以失敗，是因為他只問了認識自己的人。

這套驗證框架需要多久？

30天框架涵蓋四週：第1週做問題驗證（10-15次結構化客戶訪談）；第2週做解決方案驗證（提出概念並衡量反應強度）；第3週做通路驗證（兩次小規模獲客實驗，每個通路花費200-500美元）；第4週做營收與單位經濟模型驗證（預售或接受早期使用權付費）。一個帶有候補名單的到達頁面只需一個下午，開發到功能完備則需要數週甚至數月。

---

參考文獻