可靠的市场进入流程，应从已核实的产品事实出发，把市场信号转成可验证的定位假设，再用发布结果指导下一步决策。这套手册让技术创始人不用复杂的营销工具栈，也能建立一套小而完整的执行系统。
每个阶段都应产出一个可以直接交给下一阶段使用的工件。
| 阶段 | 要回答的问题 | 产出 |
|---|---|---|
| 1. 产品事实 | 产品现在可以被核实地完成什么？ | 产品事实表 |
| 2. 市场研究 |
| 证据中出现了哪些问题和表达？ |
| 证据笔记与待验证问题 |
| 3. 定位 | 哪个范围明确的主张值得测试？ | 首屏文案与定位假设 |
| 4. 发布准备 | 用户能否避开可预防的故障并获得价值？ | 发布清单与渠道计划 |
| 5. 学习循环 | 发生了什么，下一步要改变什么？ | 每日记录与每周决策 |
顺序很重要。产品事实让研究保持在真实边界内；研究为定位提供依据；定位决定发布方式；发布结果则为下一轮研究带来更好的问题。
把下面的模板保存到项目仓库或工作笔记中，文件名可用 GTM_RUNBOOK.md。
Tiny
学习闭环# 技术创始人 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 准备度检查清单，在推广产品前找出产品、定位、发布与衡量环节仍需解决的问题。
从产品事实表开始，选择一个研究问题，再提出一个能用真实用户验证的、尽可能小而诚实的主张。
根据当前流程的下一步决策或任务，继续使用合适的工具。
