可靠的市場進入流程，應從已確認的產品事實出發，將市場訊號轉成可驗證的定位假設，再用發布結果指引下一步決策。這套手冊讓技術創辦人不必建立複雜的行銷工具組合，也能運作一套小而完整的執行系統。
每個階段都應產出一個能直接交給下一階段使用的成果。
| 階段 | 要回答的問題 | 產出 |
|---|---|---|
| 1. 產品事實 | 產品目前能被確認地完成什麼？ | 產品事實表 |
| 2. 市場研究 |
一套持續運作的 GTM 系統
可免費試用，從你的真實產品開始
| 證據中出現哪些問題與說法？ |
| 證據筆記與待驗證問題 |
| 3. 定位 | 哪個範圍明確的主張值得測試？ | 首屏文案與定位假設 |
| 4. 發布準備 | 使用者能否避開可預防的故障並獲得價值？ | 發布清單與管道計畫 |
| 5. 學習循環 | 發生了什麼，下一步要改變什麼？ | 每日紀錄與每週決策 |
順序很重要。產品事實讓研究維持在真實邊界內；研究為定位提供依據；定位決定發布方式；發布結果則為下一輪研究帶來更好的問題。
將下面的範本存進專案儲存庫或工作筆記，檔名可使用 GTM_RUNBOOK.md。
Tiny
SEO/GEO
學習循環# 技術創辦人 GTM 執行手冊
## 1. 已確認的產品事實
- 產品名稱：
- 目標使用者與使用情境：
- 核心輸入或觸發條件：
- 可驗證的功能結果：
- 目前設定或部署方式：
- 已確認的限制：
- 不在範圍內 / 明確不做的事情：
- 目前還不能提出的主張：
## 2. 市場研究
- 研究問題：
- 已查看的來源：
- 在本次樣本中重複出現的訊號：
- 單一觀察：
- 重要矛盾：
- 缺少的證據：
- 下一步驗證行動：
## 3. 定位假設
- 使用者：
- 要完成的工作：
- 目前阻礙：
- 候選標題：
- 補充說明：
- 已確認的證明點：
- 需要測試的主要假設：
## 4. 發布準備
- [ ] 已使用真實輸入完成主要啟用流程。
- [ ] 可以在分析工具中看到啟用事件。
- [ ] 已透過一次刻意觸發的錯誤測試例外遙測。
- [ ] 計費測試環境涵蓋成功、拒付、身分驗證和退款流程。
- [ ] Webhook 已完成驗證，並採用冪等處理。
- [ ] 已檢查遙測工具中的敏感輸入遮罩。
- [ ] 已記錄並測試復原或回復路徑。
- [ ] 已檢查發布管道規則和揭露要求。
## 5. 學習循環
- 主要管道：
- 兩個已儲存的問題搜尋：
- 每天 30 分鐘執行時段：
- 本週有價值的對話：
- 已啟用使用者與觀察到的障礙：
- 無法確認的來源：
- 繼續：
- 調整：
- 停止：
研究競品或撰寫文案前，先把產品事實與市場假設分開。
| 事實類型 | 要回答的問題 |
|---|---|
| 使用者 | 誰現在就能使用這項產品？ |
| 輸入 | 使用者必須安裝、連接、上傳或提供什麼？ |
| 結果 | 使用者能完成並驗證什麼工作？ |
| 機制 | 產品透過什麼方式產生這個結果？ |
| 限制 | 哪些情況不適用，或哪些環節仍需人工處理？ |
| 非目標 | 產品明確不是用來做什麼的？ |
| 證明 | 哪些主張已有測試、示範、紀錄或目前產品行為支持？ |
不要把未經驗證的客戶痛點寫進產品事實表。創辦人可能認為使用者不喜歡某種手動流程，但在證據出現前，這仍然只是一個研究問題。
假設有一個 CLI 工具，可以在預備環境的紀錄檔上傳前移除常見密鑰。這個例子只假定以下事實已經確認：
這些事實不能證明它能找出所有密鑰、符合某項法遵標準、節省固定時間，或取代安全性審查。
公開資料可以協助你提出有價值的問題，但不能代表完整市場。
| 來源 | 適合了解什麼 | 單獨使用時不能證明什麼 |
|---|---|---|
| 客戶評論 | 工作流程中的阻礙，以及使用者描述問題時採用的說法 | 這個問題在所有使用者中有多普遍 |
| 定價頁 | 目前限制、計費單位和功能門檻 | 某項限制是否不合理，或是否會為另一項產品創造需求 |
| 更新紀錄 | 某家公司在一段期間內選擇公開了什麼 | 完整的研發投入、維護程度或產品路線圖優先順序 |
| 社群討論 | 問題出現的情境、常用術語和嘗試過的替代方法 | 市場規模，或你的產品能否解決這個問題 |
只有在你查看的樣本範圍內，才能稱某個問題「重複出現」。兩則相似評論足以支持繼續追問，但不足以代表大多數客戶。
你正在協助一位技術創辦人分析市場證據。
只使用下方提供的來源文字。不要使用關於公司、產品、市場或使用者的外部知識。
研究問題：
[問題]
來源類型與擷取日期：
[評論、定價頁、更新紀錄或社群討論]
[日期]
來源文字：
"""
[貼上簡短且相關的來源資料]
"""
先從 10–15 則簡短且相關的摘錄開始。更大的來源集合應拆成多次分析，
不要把彼此無關的資料混在同一次處理中。
規則：
1. 將直接觀察與解讀分開。
2. 只有至少兩個獨立項目支持同一個底層問題時，才能標記為「在本次樣本中重複出現」。
3. 只有一個項目支持的發現，標記為「單一觀察」。
4. 每項發現附上一段簡短原文或一個準確的文件欄位。
5. 不要推斷市場規模、使用者意圖、產品品質或付費意願。
6. 使用者抱怨可以支持某個痛點存在，但不能證明我們的產品能解決它。
7. 如果資料不足以支持結論，寫明「證據不足」。
輸出：
- 有證據支持的觀察
- 在本次樣本中重複出現的訊號
- 單一觀察
- 矛盾或缺少的背景
- 這些證據不能支持的主張
- 接下來最小的三個驗證問題
對這個紀錄檔遮蔽 CLI 來說，一個有用的研究問題是：「開發者是否反覆提到，維護自訂遮蔽規則是一項維運負擔？」研究應驗證這個問題，而不是一開始就認定產品已經找到市場需求。
定位應連接一位使用者、一項工作、一個阻礙，以及一個已有事實支持的相信理由。
可以用下面的模型起草：
定位假設 = 使用者 + 要完成的工作 + 目前阻礙 + 已確認的證明
標題不必塞入全部資訊。主標題、副標題和證明點可以共同完成表達。
| 模式 | 公式 | 範例 |
|---|---|---|
| 移除已知阻礙 | [完成工作]，不必[替代做法] | 驗證資料庫還原，不必維護自訂復原指令碼。 |
| 轉換輸入 | 把[輸入]轉成[輸出] | 把 Webhook 事件轉成可對帳的帳本紀錄。 |
| 說明服務對象 | 為[使用者或環境]設計的專用[產品類別] | 為單一容器家用伺服器設計的運作狀態監控工具。 |
| 取代脆弱流程 | 停止[脆弱流程]。[取得結果]。 | 不再手動清理正式環境紀錄。匯出前先移除常見密鑰。 |
| 劃分工作 | 你負責[高價值工作]，我們處理[系統工作]。 | 你負責寫查詢，我們處理連線池、快取和容錯移轉。 |
對貫穿全文的例子，一個謹慎的初始假設可以是：
每句話都來自產品事實表。文案沒有聲稱它能完整偵測所有風險、符合特定法遵要求，或節省經過測量的時間。
你正在協助一位技術創辦人起草定位假設。
只使用下方已確認的產品事實和有證據支持的研究觀察。
不要捏造效能、隱私、法遵、客戶、價格、整合或設定方面的主張。
已確認的產品事實：
[貼上產品事實表]
有證據支持的研究觀察：
[貼上具有證據邊界的發現]
要求：
1. 起草三個明顯不同的首屏方案。
2. 每個方案提供 H1、副標題、CTA 和證明點。
3. 寫明每個方案背後的受眾假設。
4. 指出一位不夠謹慎的寫作者最可能加入的、最嚴重的無依據主張。
5. 缺少證明的地方寫「缺少證據」。
6. 最後提出一個最小使用者測試，用來判斷目標讀者最容易理解哪個方案。
提示詞只能產生候選方案，不能驗證定位。應將完整首屏展示給相關使用者，再詢問他們理解到的工作、受眾和差異點是什麼。
發布是一段連續過程，不是一則公告。
| 時間 | 重點 | 準備完成的證據 |
|---|---|---|
| T-14 至 T-7 | 啟用、錯誤處理、計費、隱私 | 核心流程和失敗流程都已測試 |
| T-6 至 T-1 | 訊息、素材、管道規則、支援負責人 | 發布資料已審查，支援計畫已有負責人 |
| 第 0 天至第 2 天 | 冒煙測試、回覆、問題分級 | 產品維持可用，新問題有明確負責人 |
| 第 3 天至第 30 天 | 流失診斷、留存、質性回饋 | 已記錄下一步產品與推廣決策 |
更完整的執行安排請見七天產品發布指南。選擇第一個社群時，可以比較 Product Hunt、Reddit 與 Hacker News各自的優勢與限制。
日常安排的目標不是在所有平台發文，而是在不占滿工作日的前提下，持續推進有價值的對話、產品學習和後續聯繫。
| 時段 | 行動 | 產出 |
|---|---|---|
| 00–10 分鐘 | 查看兩個已儲存的問題搜尋；如果有合適討論，提供一次有幫助的回覆 | 一則有用回覆，或一個更準確的搜尋詞 |
| 10–20 分鐘 | 把真實的產品變更、錯誤修正或經驗寫成簡短更新 | 一則已審查的貼文或草稿 |
| 20–30 分鐘 | 聯繫一位使用者，或調查一個啟用障礙 | 一項有負責人的下一步行動 |
計時結束就停止。如果沒有合適的對話或聯繫對象，就改進搜尋、記錄一個問題，或回到產品工作。
星期五用檢視取代中間十分鐘：
獨立創辦人每天 30 分鐘的行銷安排提供可複製的每日清單和更完整的每週檢視方法。
這個假設的紀錄檔遮蔽 CLI 可以這樣貫穿整套系統：
| 階段 | 範例決策 |
|---|---|
| 產品事實 | 確認本機執行、支援的密鑰類型、標準輸入/輸出和授權條款。 |
| 研究 | 驗證開發者是否反覆將維護自訂遮蔽規則描述為負擔。 |
| 定位 | 起草一個關於「匯出前遮蔽已支援密鑰」的窄範圍主張，避免完整安全或法遵承諾。 |
| 發布準備 | 測試真實紀錄資料流、失敗行為、文件、遙測和復原方案。 |
| 學習循環 | 記錄誰理解了使用情境、誰完成第一次遮蔽匯出，以及設定在哪一步失敗。 |
一次發布的結果可能改變定位。如果使用者更在意本機處理，而不是指令碼維護，下一版標題就應測試這項發現。當證據能改變下一次決策時，這個循環才真正發揮作用。
起步階段的人工工作很有價值，因為它能顯示哪些背景、證據和判斷真正重要。當流程開始重複時，Tomako可以把已連接的產品與市場背景整理成有優先順序、可審核的成長工作。方向、發布、外部聯繫、支出及其他重要決定仍由人掌控。
檢查你的 GTM 準備度
使用免費的 GTM 準備度檢查清單，在推廣產品前找出產品、定位、發布與衡量環節仍需解決的問題。
從產品事實表開始，選擇一個研究問題，再提出一個能用真實使用者驗證、範圍盡可能小而誠實的主張。
根據目前流程的下一步決策或任務，繼續使用合適的工具。
