产品做完了，然后呢？第一次推广的 30 天路线图

产品做完后，下一步不是发一条上线公告就结束。更有效的做法是运行一轮 30 天冷启动：从定位和用户研究开始，通过对话、实用内容和聚焦分发获取反馈，最后复盘哪些动作真正带来了合格用户。

首次发布的价值在于减少不确定性。到第 30 天，你应该更清楚谁需要产品、什么表达能被理解、在哪里能找到他们、什么阻碍了激活，以及哪些行动值得重复。

第 1 天之前：先定义 30 天的结果

只选一个主要结果，例如激活用户、完成演示、合格候补名单、开源项目实际使用，或用户访谈。不要把品牌曝光、收入、社群增长和每个渠道指标都塞进同一个目标。

同时定义激活动作。注册不一定等于真正用户，要说清对方必须完成什么，才体验到第一个有意义的价值。之后确保可以简单记录来源、注册、激活和有用反馈。

第 1–3 天：用证据建立冷启动简报

整理一份简短的共享事实：产品做什么、给谁用、解决什么问题、用户现在有哪些替代方法、核心差异、激活动作，以及哪些说法仍需核实。证据可以来自真实产品行为、用户对话、客服问题、竞品页面和公开讨论。

不确定的判断要明确标成假设，不要直接写成充满信心的落地页文案。这份简报的作用，是防止不同渠道各自发明一个不同版本的产品。

第 4–7 天：确定一个定位和两个渠道任务

把简报压缩成一个清楚承诺：为一类具体用户，通过某种重要机制或取舍，帮他们产生一个具体结果。对照落地页、新手引导和实际产品体验；如果三者讲的不是同一件事，先修正再扩大分发。

选一个主渠道触达用户，再选一个承担不同任务的辅助渠道。例如社群负责产生对话，指南负责承接搜索需求；创始人内容负责被发现，邮件或落地页负责承接意向。不要开启一批只会重复同一条公告的渠道。

第 2 周：先要对话，不要先追求发布量

联系少量相关用户，参与一个合适社群，并发布一篇以问题或创始人视角为主的内容。询问他们当前如何解决、问题代价、试过什么，以及什么会让一个新方案变得可信。只在产品与对话相关时才展示它。

记录用户的原话、反复出现的异议、他们提到的替代方法，以及兴趣在哪个环节停了下来。这些观察比泛化互动数更有用，因为它们能告诉你下一步应该改表达、引导还是产品。

第 2 周复盘：诊断第一条转化路径

从合格关注开始，检查产品访问、注册、激活和后续使用。内容有互动却没有访问，可能是与产品的连接不清楚；访问后不注册，可能是用户或承诺不对；注册却不激活，就应先修复引导或产品体验，而不是追更多流量。

只选一个继续使用的表达、一个要修复的阻力、一个要重复的渠道动作。不要一次改完所有东西，否则下一轮结果无法告诉你究竟是哪项改动有用。

第 3 周：把真实问题变成内容系统

根据前两周收集的问题建立内容。围绕一个真实决策，做一篇完整指南、演示、对比、案例记录或工作流。只有当各版本真正符合平台时，才拆成更小内容：社群回答应该完整，短视频需要画面机制，社交帖子只讲一个清晰观察。

用内链和一致的下一步把内容连起来。从指南进入的人，应该能理解产品、看到它如何工作，并直接体验相关流程，不需要重新在网站里搜索。

第 3 周分发：加入聚焦的发布阵地

只向匹配产品类别、用户、地区和提交条件的目录与发布平台提交。准备统一的描述、截图、标签和创始人资料，再分别记录已提交、审核中、已发布、被拒绝和待跟进状态。被收录是分发基础，不是需求证明。

不同平台只复用依然准确的事实。标题、上下文、证据和行动邀请要根据目的地改写，不要到处粘贴同一段发布稿。遵守社群规则，并让最终发布、付款、验证和账号权限始终由人确认。

第 4 周：围绕已有证据集中发布

用信号最强的表达和最清楚的产品演示组织一次集中发布。更新落地页，发布主故事或指南，联系之前表现过意向的人，并分发到选定渠道。目标不是制造热闹，而是让目前证据最充分的产品版本容易被发现和评估。

发布后继续回答问题。用户的回复、异议、设置问题和愿意分享的原因，都是发布数据的一部分，不是对计划的干扰。

第 27–30 天：决定哪些工作应该继续

分开行动量与真实结果。记录合格对话、产品访问、注册、激活、持续使用、目录发布和有用反馈。按带来的用户质量和学习价值比较渠道，不要只看触达量。一个只带来少量激活用户的来源，可能比大量被动浏览更值得继续。

把每项工作标记为继续、修改、暂停或下轮测试。保留能产生合格进展的渠道和表达组合，修复最大的转化缺口，再把尚未解决的问题放进下一批内容和产品待办。

使用一个简单的每日运行循环

每天先看当前目标和昨天的证据，再完成一个聚焦动作，记录发生了什么，最后准备下一步。一次用户对话、一条完整社群回答、一次落地页修正、一批目录提交，或一段基于真实异议写成的内容，都可以是一天的完整任务。

证据变化时，计划也可以变；但不要因为一条内容点赞少，或另一个平台突然热闹，就每天重置策略。把较大决策留到每周复盘，避免被每日噪声牵着走。

首次发布应该看哪些数据

只跟踪一个小漏斗：合格关注、产品访问、注册、激活和持续使用。再加上定性证据，例如重复出现的原话、异议、需求场景、支持阻力和拒绝原因。这些信号能解释数字，并帮你判断下一项改动应该发生在获客、定位、引导还是产品。

不要编造通用基准。更有用的比较，是在相似条件下比较自己的渠道、表达和每周实验。

容易让 30 天冷启动失效的错误

一开始同时做所有渠道，会产生大量动作却得不到清晰学习。每几天就更换用户和表达，无法完成公平测试。把点赞当成需求，会隐藏关注到激活之间的断点。没有证据就发布效果承诺，会损害信任。写大量没有明确任务的薄内容，只会增加无效页面。在没有人审核的情况下自动执行账号操作，会带来平台和品牌风险。

一轮好的首次发布会更聚焦：一个用户假设、一个主要结果、一份共享产品事实、少量不同的渠道任务，以及一个固定复盘节奏。

要等产品完美再发布吗

等到一个合适用户可以到达核心价值，且你能帮他处理明显失败就够了。不需要等所有功能和边缘场景完成。只要清楚说明已知边界，且产品不会给用户带来重大风险，带着限制发布是可以的。

独立开发者应该同时做几个渠道

从一个主获客渠道和一个辅助阵地开始。只有新渠道承担不同任务，并且现有工作流已经可持续时，再添加一个。正确数量取决于制作成本、用户可触达性和学习速度，而不是某份通用上线清单。

第 30 天以后做什么

30 天计划应该以继续决策结束，不是再次沉默。保留最强的渠道、表达和内容资产，修复最大的激活或转化问题，归档已被否定的假设，再围绕现有证据安排下一个月。