SaaS 的前 100 位使用者，不是資料庫裡的 100 個信箱。這份指南會協助技術創辦人定義啟用、選擇管道、向早期使用者學習，並建立可重複的推廣路徑。
SaaS 的前 100 位使用者，不該只是資料庫裡的 100 個信箱。只有當使用者完成一個能證明產品價值的關鍵動作，才應計入「啟用使用者」。
對開發者工具來說，這個動作可能是第一次成功呼叫 API；對帳務工具來說，可能是第一次完成發票核對；對監控產品來說，可能是第一次收到有效的檢測結果。
選管道之前，先寫清楚你的啟用單位：
一個符合目標輪廓的新帳號，在 [時間範圍] 內完成 [關鍵動作]，就算啟用。
這個定義能讓使用者取得資料更誠實。它也能幫你判斷：某個管道帶來的是潛在使用者，還是只會點一下連結的人。
從 0 到 100 不是一次行銷活動，而是三個連續的診斷階段。是否進入下一階段，要看證據，不要只看日期。
| 檢查點 | 核心問題 | 主要動作 | 可以進入下一階段的訊號 |
|---|
| 最初幾位使用者 | 目標使用者能否在不依賴創辦人全程救場的情況下獲得價值？ | 直接觀察、人工引導 | 多位目標使用者完成啟用；重複問題已記錄 |
| 早期小規模使用者 | 一兩個管道能否持續帶來意圖相近的使用者？ | 先回答問題，再參與社群和小範圍接觸 | 同一管道連續多週帶來啟用使用者 |
| 朝 100 位推進 | 有用內容能否持續帶來自然發現，而非依賴一次次上線活動？ | 技術內容、上游免費工具 | 新使用者能從可重複的入口完成啟用 |
這些是診斷階段，不是適用所有產品的硬門檻。企業級產品需要更多觀察；簡單工具可能更快進入下一階段。
管道是否合適，取決於使用者在哪裡討論問題，以及他們如何判斷方案是否可信。
| 產品情境 | 更適合的起點 | 通常不適合作為第一步 | 原因 |
|---|---|---|---|
| 基礎設施、API、CLI 工具 | GitHub Discussions、技術論壇、相關 HN 討論 | 泛消費社群平台 | 使用者需要技術細節、限制和實際證明 |
| B2B 工作流程 SaaS | 直接聯絡第一線操作者、小型產業社群 | 泛創業社群 | 使用者更在意流程適配、風險和交接 |
| 小型開發者工具 | 可搜尋的免費工具、針對具體問題的教學 | 泛展示廣告 | 需求通常出現在排查問題的當下 |
產品目錄可以創造一次集中曝光，但按讚不等於啟用。Product Hunt 的官方上線指南把平台定位為接觸廣泛社群和收集回饋的機會。使用者進入產品後做了什麼，才是需要持續追蹤的資料。
如果你還在選擇首發管道，可以參考 Product Hunt、Reddit 與 Hacker News 比較。
在最早階段，效率來自更短的回饋迴圈，而不是自動化。
預設先用非同步文字和可執行範例。只有即時觀察能回答關鍵問題時，再邀請對方通話。
主動說明限制更容易建立信任。例如：「目前支援 PostgreSQL 14–16，尚不支援唯讀副本路由。」這比「適用任何資料庫環境」更有用。
這一階段的目標不是追求漂亮的回覆率，而是確認真實使用者能否獲得價值。需要具體範本時，可以查看面向開發者的冷啟動接觸指南。
當產品的基本使用路徑已經可用，再進入相關社群。不要把求助貼文當成廣告位。
可以遵循以下做法：
這也符合 Reddit 社群禮儀與 Hacker News 社群規範：優先貢獻有用內容，盡量引用原始來源，不要把社群參與變成單純的自我推廣。
可以這樣揭露關係：
我做了一個處理這個流程的工具。上面的手動方法不依賴工具也能完成；如果你需要反覆執行同一項檢查，工具會更省時間。
讀者先得到完整答案，再決定是否了解產品。
「用工程能力做行銷」能否有效，關鍵看免費工具是否緊接在付費產品之前的使用情境。
Webhook 產品可以提供瀏覽器端 HMAC 簽章除錯器；資料庫代理可以提供連線池容量估算表。免費工具處理眼前的小任務，SaaS 處理反覆出現的正式環境問題。
需要守住三個邊界：
不要為了流量做與主產品無關的「熱門計算器」。只有能帶來潛在啟用使用者的流量，才有長期價值。
更完整的判斷方法見工程化行銷：為 SaaS 做免費工具。
假設一位獨立創辦人正在做輕量級 PostgreSQL 連線代理，目標是幫助容器化應用避免連線數耗盡。
啟用單位： 符合目標輪廓的團隊在 7 天內，讓一個測試工作負載透過代理完成一次有效查詢。
最初幾位使用者： 創辦人在公開討論中看到部署期間連線耗盡的問題。三位工程師測試了二進位程式，其中兩位因為環境變數說明不清而失敗。創辦人先改善 CLI 錯誤訊息和安裝文件。
早期小規模使用者： 後續遇到類似問題時，創辦人先解釋手動連線池方案，再把開源代理作為可選工具。即使讀者不點連結，回答本身也成立。
朝 100 位推進： 創辦人發布一個連線池容量估算表，並寫清楚假設條件。只有需要排隊和執行階段控制的團隊，才會被引導到代理產品。
同一個真實問題，由此形成產品改進、公開答案和長期取得使用者的入口。
選擇一批使用者和一個固定時間範圍：
同期啟用率 = 在範圍內完成關鍵動作的合格新帳號 ÷ 同期合格新帳號總數 × 100%
| 產品 | 較弱的訊號 | 更合適的啟用動作 |
|---|---|---|
| 開發者 CLI | 下載次數 | 第一次成功執行指令並得到有效結果 |
| 帳務 SaaS | 註冊帳號 | 第一次完成真實發票或 webhook 核對 |
| 網站監控 | 建立帳號 | 第一次設定目標並驗證檢測成功 |
| API 產品 | 瀏覽文件 | 第一次帶有效憑證完成 API 請求 |
建議用 7 天或 14 天作為清楚的時間範圍。留存率、付費轉換和收入要分開追蹤。Amplitude 的免費增值與試用產品指標指南也採用同樣思路：先定義代表首次價值的動作，再統計新使用者中有多少人完成它。
接近 0 的啟用率不代表產品一定沒有價值。它表示你需要先檢查管道匹配、使用者預期、引導流程和事件追蹤，再決定是否增加流量。
獨立創辦人的 30 分鐘日常行銷流程提供了一套輕量節奏。
最初幾次使用者溝通應由創辦人親自參與。你需要聽懂使用者如何描述問題，也需要看到產品在哪裡失效。
當資訊來源變多後，Tomako可以協助整理經過選擇的市場訊號，把產品背景轉成可審核的 GTM 草稿，並讓後續事項保持可見。事實是否正確、內容是否送出、何時發布，仍由團隊決定。
當協調工作開始占用大量時間時，再使用 Tomako。不要用工具跳過最重要的早期學習。
不需要。本指南統計的是完成核心啟用動作的合格使用者。試用轉付費和收入應作為獨立指標。
不應該。先去目標使用者已經討論真實工作問題的地方。小型產業論壇可能比大型綜合平台更有效。
當目標族群、訊息和引導流程已經透過手工方式驗證後。過早自動化只會放大雜訊，也會讓你更難學到東西。
先檢查路徑，不要先加流量。核對管道意圖、著陸頁承諾、設定步驟、產品錯誤和事件追蹤，再與受影響的使用者直接溝通。
Tiny
學習循環