# 技術創辦人的 GTM 實作手冊：範本、提示詞與檢查清單

> 一套為技術創辦人設計的實用 GTM 方法，提供市場研究、定位、發布準備與日常檢視所需的可複製範本和提示詞。

Source: https://tomako.ai/zh-tw/blog/builder-gtm-playbook
Updated: 2026-09-18

可靠的市場進入流程，應從已確認的產品事實出發，將市場訊號轉成可驗證的定位假設，再用發布結果指引下一步決策。這套手冊讓技術創辦人不必建立複雜的行銷工具組合，也能運作一套小而完整的執行系統。

## 快速重點

- 先確認產品事實，再寫宣傳口號。
- 將評論、定價頁、更新紀錄和社群討論視為研究素材，而不是整個市場的結論。
- 在使用者證據和產品測試足夠之前，只提出範圍明確的定位主張。
- 導入發布流量前，先檢查啟用流程、計費、遙測和復原方案。
- 透過每日紀錄與每週檢視，決定哪些行動要繼續、調整或停止。

## 技術創辦人的五階段 GTM 系統

每個階段都應產出一個能直接交給下一階段使用的成果。

| 階段 | 要回答的問題 | 產出 |
| --- | --- | --- |
| **1. 產品事實** | 產品目前能被確認地完成什麼？ | 產品事實表 |
| **2. 市場研究** | 證據中出現哪些問題與說法？ | 證據筆記與待驗證問題 |
| **3. 定位** | 哪個範圍明確的主張值得測試？ | 首屏文案與定位假設 |
| **4. 發布準備** | 使用者能否避開可預防的故障並獲得價值？ | 發布清單與管道計畫 |
| **5. 學習循環** | 發生了什麼，下一步要改變什麼？ | 每日紀錄與每週決策 |

順序很重要。產品事實讓研究維持在真實邊界內；研究為定位提供依據；定位決定發布方式；發布結果則為下一輪研究帶來更好的問題。

## 複製完整 GTM 執行手冊

將下面的範本存進專案儲存庫或工作筆記，檔名可使用 `GTM_RUNBOOK.md`。

```markdown
# 技術創辦人 GTM 執行手冊

## 1. 已確認的產品事實
- 產品名稱：
- 目標使用者與使用情境：
- 核心輸入或觸發條件：
- 可驗證的功能結果：
- 目前設定或部署方式：
- 已確認的限制：
- 不在範圍內 / 明確不做的事情：
- 目前還不能提出的主張：

## 2. 市場研究
- 研究問題：
- 已查看的來源：
- 在本次樣本中重複出現的訊號：
- 單一觀察：
- 重要矛盾：
- 缺少的證據：
- 下一步驗證行動：

## 3. 定位假設
- 使用者：
- 要完成的工作：
- 目前阻礙：
- 候選標題：
- 補充說明：
- 已確認的證明點：
- 需要測試的主要假設：

## 4. 發布準備
- [ ] 已使用真實輸入完成主要啟用流程。
- [ ] 可以在分析工具中看到啟用事件。
- [ ] 已透過一次刻意觸發的錯誤測試例外遙測。
- [ ] 計費測試環境涵蓋成功、拒付、身分驗證和退款流程。
- [ ] Webhook 已完成驗證，並採用冪等處理。
- [ ] 已檢查遙測工具中的敏感輸入遮罩。
- [ ] 已記錄並測試復原或回復路徑。
- [ ] 已檢查發布管道規則和揭露要求。

## 5. 學習循環
- 主要管道：
- 兩個已儲存的問題搜尋：
- 每天 30 分鐘執行時段：
- 本週有價值的對話：
- 已啟用使用者與觀察到的障礙：
- 無法確認的來源：
- 繼續：
- 調整：
- 停止：
```

## 第一階段：建立產品事實表

研究競品或撰寫文案前，先把產品事實與市場假設分開。

| 事實類型 | 要回答的問題 |
| --- | --- |
| **使用者** | 誰現在就能使用這項產品？ |
| **輸入** | 使用者必須安裝、連接、上傳或提供什麼？ |
| **結果** | 使用者能完成並驗證什麼工作？ |
| **機制** | 產品透過什麼方式產生這個結果？ |
| **限制** | 哪些情況不適用，或哪些環節仍需人工處理？ |
| **非目標** | 產品明確不是用來做什麼的？ |
| **證明** | 哪些主張已有測試、示範、紀錄或目前產品行為支持？ |

不要把未經驗證的客戶痛點寫進產品事實表。創辦人可能認為使用者不喜歡某種手動流程，但在證據出現前，這仍然只是一個研究問題。

### 一個貫穿全文的例子

假設有一個 CLI 工具，可以在預備環境的紀錄檔上傳前移除常見密鑰。這個例子只假定以下事實已經確認：

- 它以單一執行檔在本機運作。
- 它從標準輸入讀取紀錄，並將遮蔽敏感資訊後的資料流寫入標準輸出。
- 它包含常見 API 金鑰和資料庫連線字串的處理規則。
- 它採用 MIT License 發布。

這些事實不能證明它能找出所有密鑰、符合某項法遵標準、節省固定時間，或取代安全性審查。

## 第二階段：把公開訊號轉成研究問題

公開資料可以協助你提出有價值的問題，但不能代表完整市場。

| 來源 | 適合了解什麼 | 單獨使用時不能證明什麼 |
| --- | --- | --- |
| **客戶評論** | 工作流程中的阻礙，以及使用者描述問題時採用的說法 | 這個問題在所有使用者中有多普遍 |
| **定價頁** | 目前限制、計費單位和功能門檻 | 某項限制是否不合理，或是否會為另一項產品創造需求 |
| **更新紀錄** | 某家公司在一段期間內選擇公開了什麼 | 完整的研發投入、維護程度或產品路線圖優先順序 |
| **社群討論** | 問題出現的情境、常用術語和嘗試過的替代方法 | 市場規模，或你的產品能否解決這個問題 |

只有在你查看的樣本範圍內，才能稱某個問題「重複出現」。兩則相似評論足以支持繼續追問，但不足以代表大多數客戶。

### 可複製的競品研究提示詞

```markdown
你正在協助一位技術創辦人分析市場證據。

只使用下方提供的來源文字。不要使用關於公司、產品、市場或使用者的外部知識。

研究問題：
[問題]

來源類型與擷取日期：
[評論、定價頁、更新紀錄或社群討論]
[日期]

來源文字：
"""
[貼上簡短且相關的來源資料]
"""

先從 10–15 則簡短且相關的摘錄開始。更大的來源集合應拆成多次分析，
不要把彼此無關的資料混在同一次處理中。

規則：
1. 將直接觀察與解讀分開。
2. 只有至少兩個獨立項目支持同一個底層問題時，才能標記為「在本次樣本中重複出現」。
3. 只有一個項目支持的發現，標記為「單一觀察」。
4. 每項發現附上一段簡短原文或一個準確的文件欄位。
5. 不要推斷市場規模、使用者意圖、產品品質或付費意願。
6. 使用者抱怨可以支持某個痛點存在，但不能證明我們的產品能解決它。
7. 如果資料不足以支持結論，寫明「證據不足」。

輸出：
- 有證據支持的觀察
- 在本次樣本中重複出現的訊號
- 單一觀察
- 矛盾或缺少的背景
- 這些證據不能支持的主張
- 接下來最小的三個驗證問題
```

對這個紀錄檔遮蔽 CLI 來說，一個有用的研究問題是：「開發者是否反覆提到，維護自訂遮蔽規則是一項維運負擔？」研究應驗證這個問題，而不是一開始就認定產品已經找到市場需求。

## 第三階段：寫出定位假設

定位應連接一位使用者、一項工作、一個阻礙，以及一個已有事實支持的相信理由。

可以用下面的模型起草：

```text
定位假設 = 使用者 + 要完成的工作 + 目前阻礙 + 已確認的證明
```

標題不必塞入全部資訊。主標題、副標題和證明點可以共同完成表達。

| 模式 | 公式 | 範例 |
| --- | --- | --- |
| **移除已知阻礙** | `[完成工作]，不必[替代做法]` | 驗證資料庫還原，不必維護自訂復原指令碼。 |
| **轉換輸入** | `把[輸入]轉成[輸出]` | 把 Webhook 事件轉成可對帳的帳本紀錄。 |
| **說明服務對象** | `為[使用者或環境]設計的專用[產品類別]` | 為單一容器家用伺服器設計的運作狀態監控工具。 |
| **取代脆弱流程** | `停止[脆弱流程]。[取得結果]。` | 不再手動清理正式環境紀錄。匯出前先移除常見密鑰。 |
| **劃分工作** | `你負責[高價值工作]，我們處理[系統工作]。` | 你負責寫查詢，我們處理連線池、快取和容錯移轉。 |

對貫穿全文的例子，一個謹慎的初始假設可以是：

- **H1：** 上傳預備環境紀錄前，先移除常見密鑰。
- **副標題：** 讓紀錄先經過本機 CLI，遮蔽它支援的 API 金鑰和資料庫連線字串，再將清理後的資料流交給上傳指令碼。
- **CTA：** 查看安裝指令。
- **證明點：** 在本機運作、採用標準輸入/輸出工作流程，並使用 MIT License。

每句話都來自產品事實表。文案沒有聲稱它能完整偵測所有風險、符合特定法遵要求，或節省經過測量的時間。

### 可複製的定位提示詞

```markdown
你正在協助一位技術創辦人起草定位假設。

只使用下方已確認的產品事實和有證據支持的研究觀察。
不要捏造效能、隱私、法遵、客戶、價格、整合或設定方面的主張。

已確認的產品事實：
[貼上產品事實表]

有證據支持的研究觀察：
[貼上具有證據邊界的發現]

要求：
1. 起草三個明顯不同的首屏方案。
2. 每個方案提供 H1、副標題、CTA 和證明點。
3. 寫明每個方案背後的受眾假設。
4. 指出一位不夠謹慎的寫作者最可能加入的、最嚴重的無依據主張。
5. 缺少證明的地方寫「缺少證據」。
6. 最後提出一個最小使用者測試，用來判斷目標讀者最容易理解哪個方案。
```

提示詞只能產生候選方案，不能驗證定位。應將完整首屏展示給相關使用者，再詢問他們理解到的工作、受眾和差異點是什麼。

## 第四階段：檢查發布準備度

發布是一段連續過程，不是一則公告。

| 時間 | 重點 | 準備完成的證據 |
| --- | --- | --- |
| **T-14 至 T-7** | 啟用、錯誤處理、計費、隱私 | 核心流程和失敗流程都已測試 |
| **T-6 至 T-1** | 訊息、素材、管道規則、支援負責人 | 發布資料已審查，支援計畫已有負責人 |
| **第 0 天至第 2 天** | 冒煙測試、回覆、問題分級 | 產品維持可用，新問題有明確負責人 |
| **第 3 天至第 30 天** | 流失診斷、留存、質性回饋 | 已記錄下一步產品與推廣決策 |

### 技術發布檢查清單

- **啟用：** 使用真實輸入完成主要價值行動，並確認分析工具中出現預期事件。
- **錯誤：** 刻意觸發一次例外，確認負責人能找到足夠的背景資訊進行調查。
- **計費：** 使用 Stripe 的[測試環境](https://docs.stripe.com/testing)模擬產品支援的付款流程。不要在正式環境中使用真實付款資料測試。
- **Webhook：** 對 Stripe Webhook，使用端點密鑰和未經修改的請求本文驗證簽章。採用冪等處理，並記錄已處理的事件 ID。參考 Stripe 目前的 [Webhook 指南](https://docs.stripe.com/webhooks)。
- **遙測：** 檢查工作階段錄製或紀錄工具中的實際設定與已擷取內容。不要假定所有位置都已啟用遮罩。
- **復原：** 記錄並測試適合目前架構的復原或回復路徑。資料庫移轉、Serverless 函式和桌面應用程式可能需要不同方案。
- **容量：** 以合適的限制、佇列或逾時保護高成本端點，並測試觸發限制時使用者會看到什麼。
- **管道：** 閱讀社群目前的規則，需要時準備揭露說明，並安排發布後負責回答問題的人。

更完整的執行安排請見[七天產品發布指南](/zh-tw/blog/how-to-launch-product-7-days)。選擇第一個社群時，可以比較 [Product Hunt、Reddit 與 Hacker News](/zh-tw/blog/product-hunt-vs-reddit-vs-hacker-news)各自的優勢與限制。

## 第五階段：建立每日與每週學習循環

日常安排的目標不是在所有平台發文，而是在不占滿工作日的前提下，持續推進有價值的對話、產品學習和後續聯繫。

| 時段 | 行動 | 產出 |
| --- | --- | --- |
| **00–10 分鐘** | 查看兩個已儲存的問題搜尋；如果有合適討論，提供一次有幫助的回覆 | 一則有用回覆，或一個更準確的搜尋詞 |
| **10–20 分鐘** | 把真實的產品變更、錯誤修正或經驗寫成簡短更新 | 一則已審查的貼文或草稿 |
| **20–30 分鐘** | 聯繫一位使用者，或調查一個啟用障礙 | 一項有負責人的下一步行動 |

計時結束就停止。如果沒有合適的對話或聯繫對象，就改進搜尋、記錄一個問題，或回到產品工作。

星期五用檢視取代中間十分鐘：

- 哪些對話涉及真正的目標受眾？
- 哪些使用者完成了啟用事件？
- 他們在哪裡停下來或需要協助？
- 他們來自哪個來源？無法確認時就標記為未知。
- 下週哪些事情應該繼續、調整或停止？

[獨立創辦人每天 30 分鐘的行銷安排](/zh-tw/blog/daily-marketing-routine-solo-founders)提供可複製的每日清單和更完整的每週檢視方法。

## 用一個例子串起五個階段

這個假設的紀錄檔遮蔽 CLI 可以這樣貫穿整套系統：

| 階段 | 範例決策 |
| --- | --- |
| **產品事實** | 確認本機執行、支援的密鑰類型、標準輸入/輸出和授權條款。 |
| **研究** | 驗證開發者是否反覆將維護自訂遮蔽規則描述為負擔。 |
| **定位** | 起草一個關於「匯出前遮蔽已支援密鑰」的窄範圍主張，避免完整安全或法遵承諾。 |
| **發布準備** | 測試真實紀錄資料流、失敗行為、文件、遙測和復原方案。 |
| **學習循環** | 記錄誰理解了使用情境、誰完成第一次遮蔽匯出，以及設定在哪一步失敗。 |

一次發布的結果可能改變定位。如果使用者更在意本機處理，而不是指令碼維護，下一版標題就應測試這項發現。當證據能改變下一次決策時，這個循環才真正發揮作用。

## Tomako 在其中扮演什麼角色

起步階段的人工工作很有價值，因為它能顯示哪些背景、證據和判斷真正重要。當流程開始重複時，[Tomako](https://tomako.ai)可以把已連接的產品與市場背景整理成有優先順序、可審核的成長工作。方向、發布、外部聯繫、支出及其他重要決定仍由人掌控。

> **檢查你的 GTM 準備度**
>
> 使用免費的 [GTM 準備度檢查清單](/zh-tw/tools/gtm-readiness-checklist)，在推廣產品前找出產品、定位、發布與衡量環節仍需解決的問題。

## 延伸閱讀

- [如何在 7 天內發布產品](/zh-tw/blog/how-to-launch-product-7-days)
- [Product Hunt、Reddit 與 Hacker News：獨立創辦人應該先在哪裡發布？](/zh-tw/blog/product-hunt-vs-reddit-vs-hacker-news)
- [獨立創辦人每天 30 分鐘的行銷安排](/zh-tw/blog/daily-marketing-routine-solo-founders)

從產品事實表開始，選擇一個研究問題，再提出一個能用真實使用者驗證、範圍盡可能小而誠實的主張。