工程師學創業：先別想做大市場，找到能聊遍的小圈子

編譯摘要 2026/4/28

編譯摘要：工程師學創業（系列第一篇）

AI 時代工程師創業的瓶頸從「能不能做出來」移到「能不能賣出去」
- 證據：Codotx 一年內四款產品，銷售失敗的兩款都不是技術問題，是一開始沒搞清楚要賣給哪些人。
- 證據：aiker 社群平台 AI 一天做完一個月的功能，上線後零使用者，是典型的「沒鎖定客群就開發」案例。
起點客群必須小到一週能聊遍——大市場讓你永遠在摸黑，小到能聊遍才能在三個月內聽到一致訊號
- 證據：四階段縮小範例（給創業者的工具 → SaaS 創業者 → 獨立開發者 → PTT Soho 版/FB 獨立開發者社團、自己一人開發、3-6 個月還沒收第一筆款的台灣 SOHO 工程師）。
- 標準：寫到能讓你「打開瀏覽器，今天下午就能列出 30 個名字」才算過關。
合格的起點客群必須同時回答三件事：誰／什麼時候痛／聚在哪——任何一個維度模糊都還沒鎖定
- 證據：三個常見錯誤（用需求代替人、用市場報告分類代替自稱、選碰不到的人）一一對應到三個維度的失誤。
- 證據：Codotx 第一款外掛初期定位為「給所有 WordPress 站長」，後來鎖定到「LINE Notify 被官方停用、急著找替代方案的中小型電商」才出現銷售訊號。

前提假設：AI 真的把建造成本壓到接近零。對純軟體 / 內容類產品成立。
反例與邊界：
- 醫療器材、金融合規、製造業——建造仍是主要成本，認證與測試耗時遠大於寫程式。
- 中大型團隊本來就有 PM/業務分工，鎖定客群是組織日常，「瓶頸轉移」說法主要對個人開發者/小團隊成立。
資料來源限制：Codotx 四款產品樣本量小，是個案經驗外推，並非市場研究結論。

前提假設：你接觸得到那群人——能用語言溝通、有公開可達的聚集地、有時間做 1-on-1。
反例與邊界：
- B2B 高階決策者（CFO、採購主管）通常沒有可點擊的聚集地，需要 cold outreach + 引薦，「一週聊遍」不適用。
- 大眾消費品市場可能太分散，反而要先用付費廣告/SEO 抓行為訊號，再從中找小圈子。
未提及的成本：「聊遍」隱含每週投入大量時間做訪談的成本，獨立開發者若還在接案養家可能撐不住。

前提假設：產品適合主動推銷模式（你去找客戶）。
反例與邊界：
- 搜尋驅動的工具產品（SEO 工具、生產力工具）——客戶會自己搜尋上門，「聚在哪」可能不是必要維度，反而是「他們搜什麼關鍵字」。
- 社群裂變的產品（內容平台、社交工具）——「聚在哪」可能會自然形成，鎖死反而限制傳播。
三維度的相對重要性會因商業模式漂移，文章把它說成普遍法則略嫌絕對。

軍事戰略的灘頭堡作戰 D-Day 不是攻佔整個歐洲，是先拿下諾曼第半島當補給基地。先鎖小圈子再擴張的商業思維跟軍事 beachhead 同源——都受限於「補給線/接觸頻率」決定行動半徑。
科學研究的對照組設計 好的實驗要排除混淆變數。「為什麼不選相鄰人群」這題就是在排除混淆——確保你打的是這個變數（例如「LINE Notify 停用」）而不是別的。沒做排除步驟，訊號好壞都不知道是誰造成的。
學術論文的 abstract 過濾 研究者讀 abstract 後決定是否往下讀。「能不能讓陌生人讀完想到一個符合的人」就是 product abstract 過濾——過不了，後面所有訪談、產品迭代都是浪費時間。
內容創作的「找你的 1000 個鐵粉」 Kevin Kelly 的 1000 True Fans 理論跟 beachhead 同邏輯——不是追求最多人，是追求最對的人能形成 critical mass。

招募人才：「找適合的工程師」失敗，往往是 JD 寫得太泛——把 JD 當 beachhead 縮，鎖到「3-5 年 React、做過 SSR、現在卡在團隊技術債的人」會比「想找好工程師」有效。
公益倡議：訴求對象越具體，動員力越強——「為地球發聲」遠不如「住在某流域、每年看著河被污染的居民」。
政治競選：選舉策略中的「基本盤定位」就是 beachhead——先鎖核心族群，再擴張到中間選民。
內部說服：跟主管推一個提案時，先想清楚「這個改變對誰最有感」也是同一個邏輯。