产品已经能用了：测试通过，可以正常部署，新访客也能注册账号。接下来，你需要找到真正有理由使用它的人。
有几件事代码无法替你决定：先接触谁、去哪里找到他们、邀请他们试什么，以及怎样判断产品确实帮到了他们。
这篇指南把这些问题整理成一套早期获客流程：
明确目标客户 → 测试一个渠道 → 帮助用户获得价值 → 复盘并继续尝试。
你将设计一次小规模营销实验，并获得一份可以配合开发工作使用的每周清单。这里讨论的是不投付费广告、从可试用产品开始获取早期用户的方法。
全文使用两个假设案例：数据库备份验证工具，以及自由设计师使用的账单生成工具。后者用于向客户请款，不涉及当地税务发票功能。案例用于解释决策方法，不代表真实客户成果。
“开发者”和“自由职业者”都太宽泛，无法告诉你谁有迫切的理由尝试产品。
先明确具体客户、使用场景，以及你能提供的结果：
| 问题 | 备份验证工具 | 自由职业者账单工具 |
|---|---|---|
| 谁遇到了这个问题？ | 为客户维护数据库的小型服务团队 |
| 按项目阶段结算的自由设计师 |
| 什么事情促使他们行动？ | 项目交付时，客户要求提供备份可恢复的证明 | 一个项目阶段已验收，可以向客户请款 |
| 他们目前怎么处理？ | 手动测试恢复，再整理验证结果 | 把项目明细复制到账单模板中 |
| 你能提供什么有用的结果？ | 完成一次恢复测试，并留下清晰的验证记录 | 生成一份信息准确、可以发送给客户的账单 |
把答案整理成一句话：
这款工具帮助 [具体客户] 在 [相关场景] 下完成 [有用的结果]。
以账单工具为例：
这款工具帮助自由设计师把已验收的项目阶段生成账单，不必重新录入项目明细。
接着，从交流记录、客服问题或访谈中寻找这个需求的依据。问问对方目前怎么处理，具体麻烦在哪里。
根据回答进一步明确第一批客户。客户描述越具体，第一次接触就越容易切中需求，结果也更容易解释。
第一个渠道应该能让你接触到真正遇到上述问题的人。
备份工具可以从服务团队负责人或数据库管理员所在的社区入手。账单工具则可以关注自由设计师讨论项目管理、结算和收款的社区。
比较渠道时，先回答三个问题：
| 渠道 | 什么时候值得考虑？ | 先检查什么？ |
|---|---|---|
| 相关的 Reddit 子社区 | 成员正在讨论你要解决的工作问题 | 社区规则，以及是否允许提及相关产品 |
| Hacker News / Show HN | 已有可试用的产品，希望获得技术反馈 | 演示是否方便访问，以及能否说明产品的实现方式和设计理由 |
| Product Hunt | 想向其受众公开介绍产品，测试反馈 | 同类产品是否吸引了你的目标客户参与讨论 |
| 垂直社区或已有的人脉 | 可以直接接触负责这项工作的人 | 是否适合征求反馈、演示产品或请求引荐 |
Reddit 的平台规则禁止垃圾信息，各子社区也有自己的要求。分享内容或产品链接前，应先阅读相关规则。Reddit 垃圾信息规则
Show HN 面向别人可以实际尝试的作品。只有落地页或候补名单，不符合其投稿要求。Show HN 投稿指南
如果你正在比较这些平台，可以继续阅读 Product Hunt、Reddit 和 Hacker News：应该先在哪个平台发布产品？
记录以下内容：
账单工具可以这样安排：
在允许讨论工作流程的自由设计师社区，分享一种追踪可结算项目阶段的方法。为感兴趣的成员演示如何把一个已验收阶段生成账单。
先安排一周后做首次复盘，看看产生了哪些交流和试用，再决定继续还是调整。
起步不需要一份横跨三个平台的发布日历。先找到一个相关的地方，提供有用的信息，并给出清晰的下一步。
对方表达兴趣，意味着你可以开始引导试用。
有人想进一步了解时，说明可以试什么、需要准备哪些信息，以及预计会得到什么结果。可以在当前对话中继续，也可以按对方意愿提供单独演示。
以账单工具为例：
你可以用示例项目，或者自己的一个已验收阶段来试。先生成一份账单，检查明细是否正确。我可以发演示链接，也可以带你操作一遍。
示例环境能降低第一次尝试的难度。之后再确认产品能否融入对方的实际工作流程。
把下面几个阶段分开记录：
| 阶段 | 它说明什么？ |
|---|---|
| 访问 | 有人进入网站 |
| 注册 | 有人创建了产品账号 |
| 激活 | 有人完成了能体现初步价值的操作 |
| 持续使用 | 有人再次使用产品，或持续从中获得价值 |
| 付费 | 有人为产品或服务付款 |
激活行为应当对应你向客户承诺的结果。
对于备份工具，连接数据库只是准备工作。完成一次恢复测试，并查看验证记录，更能说明用户体验到了初步价值。
对于账单工具，创建账号只是准备工作。根据已验收的项目阶段生成账单，并检查内容，可以作为第一次有价值的操作。
同时记录这次使用的是示例数据还是真实项目，以及是否需要你的协助。这些信息比单独一个激活人数更能帮助你判断结果。
先问对方想完成什么，再观察他们如何处理任务。
重点留意：
设计师可能已经生成账单，却发现缺少付款条款。服务团队可能已经完成恢复测试，但还需要一份能交给客户的报告。
这些观察能让你看到：产品虽然给出了技术结果，但离客户真正要完成的工作还有什么差距。
先处理影响最大的障碍，说明改了什么，并在合适的时候邀请对方继续尝试。
更详细的招募和沟通方法，见不投广告，如何获得首批 100 名 SaaS 用户。
在笔记文件夹中新建 gtm-experiment.md，或把下面的清单粘贴到 Notion 页面。每次实验使用一份。
Tiny
学习闭环# 每周 SaaS 营销实验
## 1. 客户与价值
- 目标客户：
- 问题或触发场景：
- 当前解决办法：
- 产品提供的有用结果：
- 来自交流或调研的依据：
## 2. 渠道测试
- 渠道或社区：
- 为什么这里的受众适合：
- 已检查的参与规则：
- 准备分享的内容或发出的邀请：
- 感兴趣的人下一步怎么做：
- 复盘日期：
## 3. 第一次产品体验
- 激活行为：
- 示例数据还是真实项目：
- 提供了哪些协助：
- 主要障碍：
- 预计下次使用或检查价值的时间：
## 4. 行动
- [ ] 分享相关内容，或发出合适的邀请。
- [ ] 跟进主动要求进一步了解的人。
- [ ] 尽可能观察一次产品试用。
- [ ] 记录疑问和障碍。
- [ ] 处理当前最重要的下一步。
## 5. 结果
- 相关交流次数：
- 开始试用的数量：
- 已激活账号数：
- 持续获得价值的账号数：
- 付费账号数：
- 投入时间：
- 来源未知或无法确定的用户记录：
## 6. 下一步决策
- 继续、调整或暂停：
- 决策依据：
- 下一次实验的一项调整：
在账单工具的例子中，激活行为可以写成：“根据已验收的项目阶段生成账单，并检查内容。”下一次跟进可以放在下个结算节点，了解设计师是否再次使用了工具。
这份清单是为了帮助你决定下一步，保持简洁才容易坚持记录。
在日程中为营销留出固定时间，避免潜在客户的交流和试用跟进被开发任务挤掉。
可以先每天安排 30 分钟维护日常工作，优先处理：
根据当前卡点分配时间。如果一个试用用户遇到了问题，整段时间都用来协助他也很合理。
访谈、发布准备、较完整的教程等深入工作，需要另外安排时间。每天的固定时段负责让两次大任务之间的工作不断档。
从客户需要理解什么出发，选择值得分享的更新。
以账单工具为例：
备份工具则可以写一篇短文，解释如何区分恢复失败与测试环境配置错误。
当一个功能能回答真实的客户问题时，它才值得作为内容分享。用这个标准筛选，不必把每次代码提交都变成帖子。
更具体的日程和示例，见独立开发者每天 30 分钟的营销安排。
到了复盘时间，回看从第一次交流到产品使用结果的全过程。
小规模实验要保留具体数量。两次试用中有一次激活，是值得继续观察的结果，还不能当作稳定的转化率。
| 观察到的情况 | 接下来调查什么？ |
|---|---|
| 相关回复很少 | 合适的人看到信息了吗？是否看懂了问题？参与方式是否合适？ |
| 有交流，但很少试用 | 问题是否紧迫？邀请是否清楚？尝试成本或信任门槛是否过高？ |
| 有试用，但很少激活 | 是否遇到设置障碍、产品故障，或者产品与预期不符？ |
| 已激活，但未持续获得价值 | 需求何时再次出现？产品是否融入日常流程？ |
| 持续使用，但很少付费 | 谁决定付款？购买方案是否清楚？价值是否值得这个价格？ |
这些问题用于指引调查。结合交流记录和实际操作，逐步缩小原因范围。
判断持续使用时，要考虑产品的使用节奏。账单工具可能要到下个结算节点才会再次用到；备份工具即使没有每日登录，也可能一直在后台提供价值。
每次复盘后做出一个决定：
记录原因，以及下一次准备调整什么。
当一项重复工作已经证明有用，而且你知道怎样才算做好，就可以考虑借助工具减少工作量。
可以先从这些任务入手：整理对方要求的后续跟进、汇总访谈笔记供自己检查，或根据已确认的产品说明起草更新内容。
选工具前，先补全这句话：
当 [事件] 发生时，我需要得到 [输出]，并通过 [检查方法] 确认结果。
例如：
引导试用结束后，我需要一份客户目标和操作障碍的摘要，再对照自己的笔记核实。
这样你就有了具体要求。判断是否值得自动化时，把节省的时间与检查、修正结果的时间一起考虑。
先回答四个问题：
把答案填进清单，安排第一次分享、引荐请求或产品演示。
随着实验重复推进，你会逐渐知道哪些营销任务值得亲自投入，哪些工作希望交给工具协助。
这也正是 Tomako 关注的问题。Tomako 是协助创始人持续把产品推向市场的 AI 营销负责人（AI CMO）。 如果你也在探索如何用 AI 支持营销工作，可以开始使用 Tomako。
从一个真实的客户问题和一次小实验开始，用学到的东西决定下一步怎么做，以及需要什么工具。
