獨立開發：我以為需求驗證是必須的，直到我做完第一個產品
整理版優先睇
獨立開發者要識分「搬磚型機會」同「認知型機會」，先決定使唔使做需求驗證
呢篇文章係一個獨立開發者嘅親身經驗分享。佢一開始跟網上課程學咗套好完整嘅需求驗證方法——先做搜索、數據分析、用戶訪談去確認需求存在，先至開始開發。但佢發現呢套方法對自己想做嘅一啲題目完全用唔到，例如「支付封裝」、「消費抽象」呢類技術痛點，市場上冇人討論，但佢自己每日做嘢就親身感受到。
佢反思之後，將機會分為兩種：「搬磚型機會」係可以透過外部信號驗證嘅，例如睇到人哋抱怨某個問題，然後整一個更好嘅方案；而「認知型機會」係你自己成日浸喺個領域入面，你知道邊度痛、邊度現有方案做得差，你本身就係最好嘅需求來源。佢選擇咗後者，冇再做用戶訪談，直接做咗 Pay4SaaS 同其他支付解決方案。
結論係：工具要分場景，如果你自己喺某個領域浸咗好耐，請先信自己嘅判斷，唔好盲目信曬外部驗證方法。
- 傳統需求驗證方法假設「真需求一定有人喺市場表達緊」，但呢個假設唔適合認知型機會
- 搬磚型機會可以用搜索同評論區驗證；認知型機會要靠自身行業經驗同親身痛點
- 作者用自己做例子：佢寫獨立開發相關文章反應好好，但用驗證方法去搜就揾唔到證據
- ShipFast 嘅 Marc Lou 同 Nomad List 嘅 Pieter Levels 都係靠自身經驗做產品，冇做需求驗證
- 先判斷自己係咪「浸喺個池入面」：係嘅話，直接開工好過浪費時間做外部驗證
一套驗證方法，點解對某啲需求完全無效？
作者喺014個月前開始做獨立開發，跟咗一套好完善嘅需求驗證課程，諗住嚴格執行。佢發現有啲自己覺得「肯定存在」嘅需求，用嗰套方法點都驗證唔到出嚟。
課程嘅邏輯係「先驗證再做」——透過搜索、數據、訪談去確認需求
核心假設係：如果一個需求係真，市場上一定已經有人喺度表達緊。但作者去搜「支付如何封裝」、「把消費如何抽象出來」，結果零零散散，無一個係爆款評論。按課程標準，呢條路就該停。
佢心知呢件事係真，因為自己寫嘅相關文章每一篇嘅反響都比預期好，讀者會轉發俾朋友
搬磚型機會 vs 認知型機會
作者後來諗通咗：嗰套課程對應嘅係「搬磚型機會」——可以透過外部信號驗證、按流程推進。見到有個池有人抱怨，就做個更好嘅方案入去。
仲有另一種機會係「認知型機會」——自己就成日浸喺呢個池入面
你知道邊度痛、邊度假裝唔痛但其實好痛、邊度現有方案做得敷衍。ShipFast 嘅 Marc Lou 就係呢條路：佢做咗幾個 SaaS 之後煩咗，發現每次寫一樣嘅 code，所以整咗 ShipFast。
Pieter Levels 做 Nomad List 時，冇人搜「數字遊民城市推薦」，佢自己想要所以做咗一個
直接從業務砌問題，唔再做用戶訪談
作者最終揀咗認知型機會嘅路徑：唔做搜索同用戶訪談，直接從業務入面揾問題並解決。佢做咗 Pay4SaaS，仲寫咗一系列支付同消費嘅解決方案。
呢條路嘅代價係前期投入大，冇任何外部信號俾安全感，做完之前唔知會唔會有人買
但佢認為值得，因為自己嘅痛點係真實嘅。
手裏只有錘子，乜都似釘子
作者引用咗一句好到位嘅話：如果你手裏只有一把錘子，你會將所有問題看成釘子。嗰份課程係佢初學獨立開發時嘅錘子，但當要做嘅嘢唔係釘子，就要用另一個框架。
工具唔分高低，分場景
如果你都喺某件事上浸咗好耐，請先相信你自己嘅判斷。
01
4個月前，我啱啱開始做獨立開發。我整理過一套好完整嘅「需求驗證」方法，準備嚴格跟住做。
但好快我發現一件奇怪嘅事——有啲我明明覺得「應該存在」嘅需求，用呢套方法點解就係驗證唔到？
最初我以為係自己做錯，後來先發現，唔係執行問題，而係方法唔適合。
02
嗰套課程嘅邏輯係「先驗證再做」，透過搜索、數據、訪談去確認需求是否存在。
即係核心假設係：「如果一個需求係真嘅，市場上一定已經有人喺度表達緊佢」。
但我跟住呢套思路諗問題嗰陣，總有一種奇怪嘅感覺。
我去搜「支付如何封裝」「將消費點樣抽象化」，搜出嚟嘅結果零零散散，冇幾個稱得上「爆款評論」。按課程標準，呢條路就應該停咗。
但我心知肚明，呢件事係真嘅，睇數據就知。
每一篇嘅反應都好過預期。讀者係同行，佢哋讀完會轉發畀朋友。
呢個先係呢個池子真實嘅樣。佢唔喺小紅書嘅留言區，而係喺每一個獨立開發者嘅 commit history 度。
我後來諗通咗——嗰套課程本質上對應嘅係「搬磚型機會」，即係嗰啲可以透過外部信號驗證、按流程推進嘅機會。
見到一個池子度有人喺度抱怨，我哋做一個更好嘅方案入去。
03
但仲有另一種機會，係「認知型機會」，即係自己成日浸喺呢個池子度。自己知道邊度痛、邊度扮唔痛但其實好痛、邊度現有方案做得求其。
ShipFast 嘅 Marc Lou 都係呢條路。
佢冇做需求驗證，佢做咗幾個 SaaS 之後覺得煩，發現自己每次都在寫一樣嘅 code，所以就做咗 ShipFast。
Pieter Levels 做 Nomad List 嗰陣，冇人喺度搜「數碼遊民城市推薦」，佢自己想要一個所以就做咗一個。
呢啲路徑共同嘅特徵係——當你本身就喺呢個池子度嗰陣，你自己就係驗證。
而去搜留言去驗證自己每日經歷嘅事，就好似醫生透過睇人哋微博嚟確認自己得咗咩病。
所以我後來揀嘅，係呢條路徑。
我冇去做搜索同用戶訪談，而係直接從業務度揾問題，並解決佢。所以，我整咗 Pay4SaaS，亦寫咗一啲支付同消費嘅解決方案。
例如，類似呢啲嘅，仲有試用期避免無限循環嘅呢啲。
呢條路都有佢嘅代價——
前期投入大，冇任何外部信號俾我安全感，做完之前唔知會唔會有人買。
04
有句說話講得好到位——如果你手上面得一把錘，你就會將所有問題睇成釘。
嗰份課程係我初學獨立開發嗰陣嘅錘。但有時候，做嘅事唔係釘，係另外嘅嘢，就要靈活啲，用另一個框架喇。
工具唔分高低，分場合。
如果你都喺某件事上浸咗好耐，請先信任自己嘅判斷。
01
4 個月前，我剛開始做獨立開發。 我整理過一套很完整的「需求驗證」方法，準備嚴格照着執行。
但很快我發現一件奇怪的事—— 有些我明明覺得「應該存在」的需求，用這套方法為什麼就是驗證不出來？
一開始我以為是自己做錯了，後來才發現，不是執行問題，是方法不適合。
02
那套課程的邏輯是「先驗證再做」，通過搜索、數據、訪談去確認需求是否存在。
也就是，核心假設是，「如果一個需求是真的，市場上一定已經有人在表達它」。
但我按這套思路想問題時，總有一種奇怪的感覺。
我去搜「支付如何封裝」「把消費如何抽象出來」，搜出來的結果零零散散，沒幾個能稱為「爆款評論」的。按課程標準，這條路就該停了。
可我心裏清楚，這件事是真的，看數據。每一篇的反響都比預期好。讀者是同行，他們讀完會轉發給朋友。
這才是這個池子真實的樣子。它不在小紅書的評論區，它在每一個獨立開發者的 commit history 裏。
我後來想明白了——那套課程本質上對應的是「搬磚型機會」，也就是那種可以通過外部信號驗證、按流程推進的機會。
看到一個池子裏有人在抱怨，我們做個更好的方案進去。
03
但還有另一種機會，是「認知型機會」，也就是自己就整天浸在這個池子裏。自己知道哪裏痛、哪裏假裝不痛但其實很痛、哪裏現有方案做得敷衍的。
ShipFast 的 Marc Lou 也是這條路。
他沒做需求驗證，他做了幾個 SaaS 之後煩了，發現自己每次都在寫一樣的代碼，所以做了 ShipFast。
Pieter Levels 做 Nomad List 時，沒人在搜「數字遊民城市推薦」，他自己想要一個所以做了一個。
這些路徑共同的特徵是——當你就在這個池子裏時，你本身就是驗證。
而去搜評論驗證自己每天經歷的事，就像醫生通過看別人微博來確認自己得了什麼病。
所以我後來選擇的，是這條路徑。
我沒去做搜索和用戶訪談，而是直接從業務裏找問題，並解決它。所以，我做了 Pay4SaaS ，也寫了一些支付和消費的解決方案。
比如，類似這種的，還有試用期避免無限循環的這些。這條路也有它的代價——
前期投入大，沒有任何外部信號給我安全感，做完之前不知道會不會有人買。
04
有句話講得很到位——如果你手裏只有一把錘子，你將會把所有的問題看成釘子。
那份課程是我初學獨立開發時候的錘子。但有時候，做的事不是釘子，是另外的東西，就要靈活一點，用另一個框架了。
工具不分高低，分場景。
如果你也在某件事上泡了很久，請先信任自己的判斷。