产品发布不只是发一条公告。本指南帮助你确定该说什么、让用户走到下一步、找到合适渠道，并用真实反馈决定后续动作。
要发布一个产品，先确定三件事：产品是给谁用的、现在能证明什么结果、希望对方完成什么动作。然后建立从发布信息到该动作的路径，准备好发布渠道与回复安排，并在发布后根据用户实际行为决定下一步。
这份指南适合已经能完成核心任务的 SaaS、数字产品或范围明确的 Beta。若核心产品还不能用、目标用户仍不清楚，或发布周没有人能回复用户，应该先延长准备时间，而不是急着公开发布。
很多发布效果不好，并不是少发了一条社媒内容，而是某个关键判断从未完成：受众太宽、产品证明不了承诺、下一步路径断了，或者没有人负责回复。
| 阶段 | 要做的判断 | 进入下一步前的合格标准 |
|---|---|---|
| 发布策略 | 第一批用户是谁，为什么现在会在意？ | 有明确的受众、问题、承诺和不做什么 |
| 发布计划 | 先做什么、谁负责、有哪些风险？ | 有一个目标、清晰顺序、负责人和渠道选择 |
一套持续运转的 GTM 系统
可免费试用，从你的真实产品开始
| 发布就绪 | 用户能否理解、体验并完成下一步？ | 路径测试通过，有真实证明和诚实说明 |
| 发布执行 | 去哪里发布，谁来处理反馈？ | 有渠道素材、当日规则确认和回复安排 |
| 发布复盘 | 什么证据会改变下一步？ | 有指标来源、复盘时间和下一次实验 |
下面会先讲清楚每个部分怎么做。七天安排放在后面，作为完整方法的压缩执行版本。
发布策略是这次发布背后的选择。它要回答：这次主要面对谁、他们正在经历什么问题、产品今天能证明什么、这次发布最看重什么结果。
先写一页发布简报。它应当具体到另一个同事可以据此检查落地页，或回答用户提问。
| 简报字段 | 要写清什么 | 不够好的写法 | 可执行的写法 |
|---|---|---|---|
| 第一批受众 | 最容易触达且有该问题的人 | “创业者” | “还在用表格管理合作邀约的独立 SaaS 创始人” |
| 当前替代方案 | 不用产品时如何解决 | “他们需要更好的工具” | “联系人、沟通记录和跟进事项分散在不同表格” |
| 产品承诺 | 现有产品确实能展示的结果 | “最好的 AI 工具” | “把产品 URL 整理成一份结构化发布待办” |
| 主要动作 | 这次发布希望带来的一个下一步 | “提高知名度” | “开始试用并完成第一个核心动作” |
| 不做的承诺 | 此时不应夸大的事情 | 留空 | “暂不声称能够替代完整营销团队” |
尽量使用真实对话、支持请求、产品反馈和用户当前替代方案里的表达。承诺应当是用户今天能在产品里看到的结果，而不是路线图或宽泛的品类词。
为本次发布选一个主要结果：合格候补名单、完成激活的 Beta 用户、开始试用、付费购买，或高相关度的对话都可以。辅助信号有用，但不能代替主要结果。
合格后再进入下一步： 团队里的任何人都能不增加新承诺地说清受众、问题、产品承诺和下一步动作。若描述越写越长，先收窄受众或承诺，再制作素材。
策略解释为什么这样选择；产品发布计划把这些选择变成可以完成、检查和协作的工作。
不要从“所有平台都发一遍”开始。先画出一个人从第一次看到发布信息，到完成你最在意的动作之间的路径，再列出可能让这条路径中断的依赖、负责人和风险。
| 计划字段 | 要做的判断 | 合格标准 |
|---|---|---|
| 目标 | 主要动作与复盘时间 | 一个动作比单纯流量更重要 |
| 信息 | 受众、问题、承诺和证明 | 每个主张都能演示或如实解释 |
| 路径 | 公告、落地页、CTA、确认页、首次使用 | 一个真实用户能从头走到尾 |
| 渠道 | 第一批受众已经在哪些地方注意信息 | 选少量渠道，并有回复能力 |
| 负责人 | 谁准备、发布、回复和修复问题 | 每个依赖项都有唯一负责人 |
| 风险 | 什么情况应暂停或延后 | 访问失效、证明缺失、规则未确认或没人回复，在发布日前就可见 |
你可以有七天、两周，或更长的 Beta 准备期。时间长短改变的是节奏，不改变发布需要完成的工作。如果产品路径和定位还没有解决，压缩日历只会把问题推到用户发现它的时候。
合格后再进入下一步： 所有人看到的是同一份计划：目标、路径、渠道、负责人、关键依赖，以及什么情况下应该推迟发布。
用户并不会体验你的发布计划。他们体验的是产品页、你展示的证明、点击的 CTA，以及点击之后发生的事情。
围绕产品承诺准备一套小而完整的证据素材。它的作用是回答一个理性访客会问的问题，而不是让用户相信空泛的营销词。
| 素材 | 它必须完成什么 | 怎么检查 |
|---|---|---|
| 落地页 | 说明受众、结果、证明、边界和一个下一步 | 让团队外的人在 30 秒后复述产品做什么 |
| 演示或截图 | 展示真实产品如何产生承诺的结果 | 使用核心流程，不用纯装饰画面 |
| CTA 与确认 | 如实说明用户要做什么、之后会发生什么 | 用非管理员账号测试注册、购买、下载或预约 |
| 上手路径 | 帮新用户到达第一个有价值的时刻 | 首次核心动作清楚且能完成 |
| FAQ 与回复说明 | 回答访问、价格、隐私、限制和支持问题 | 删除依赖虚构政策或未来功能的答案 |
在桌面端和移动端完整走一遍：打开链接、读页面、点击 CTA、收到预期确认，再到达产品里的第一个动作。检查发布信息依赖的跳转、邮件、表单和支持入口。
不要用占位 Logo、编造的评价或产品无法展示的主张来填补证明空白。写清一个限制，比制造虚假的确定感更有价值。
合格后再进入下一步： 一个没有参与开发的人，能够理解产品价值、完成预期动作，并知道之后会发生什么。
度量不是发布后才打开的仪表盘，而是在发布前就约定好的证据标准。
为每个目标写清数据来源和查看人，并把指标控制在团队真正会使用的范围内。
| 目标 | 重点观察什么 | 结合什么复盘 |
|---|---|---|
| 候补名单质量 | 合格注册与有价值的回复 | 来源、落地页转化和回复主题 |
| Beta 学习 | 到达第一个核心动作的用户 | 激活路径与反馈完成情况 |
| 付费验证 | 购买或开始试用 | 结账/试用事件与早期激活 |
| 社区学习 | 相关讨论，而不是单纯曝光 | 重复问题、主页访问和有效跟进 |
发布前测试分析事件、链接来源标记、移动端显示、图片、表单、确认状态和支持联系方式。如果搜索发现也是计划的一部分，检查页面标题、描述、规范 URL、内链和 sitemap 流程。sitemap 可以帮助发现页面，但不承诺即时收录或流量。
合格后再进入下一步： 团队无需事后拼凑，也能回答三个问题：用户从哪里来、是否完成了主要动作、路径出错或出现重要问题时由谁处理。
选择渠道的原因应当是第一批用户已经在那里、团队也能在那里回复，而不是因为任何通用清单都要求每个平台出现一次。
| 渠道类型 | 适合什么情况 | 信息要如何调整 | 发布前要准备什么 |
|---|---|---|---|
| 既有受众或邮件 | 对方已了解问题或了解你的工作 | 直接说这次改变了什么、帮助谁 | 分组、一个 CTA 和回复负责人 |
| 社区讨论 | 社区确实在讨论这个问题 | 提供有用背景，并邀请相关反馈 | 阅读当日规则，并披露与产品的关系 |
| 合作伙伴或客户触达 | 有真实关系和明确联系理由 | 针对对方的问题、证明和请求个性化表达 | 短消息、跟进规则和不施压的退出方式 |
| 发布平台 | 产品符合平台受众与内容形式 | 使用该平台需要的素材和社区表达 | 当前规则、回复安排和可用落地页 |
准备一版短公告、一版更完整的说明，以及常见问题的回复库。短公告应说明用户问题、展示产品结果，并提供一个下一步；长说明可以解释触发原因、取舍和你希望获得的反馈。
在发布前一天重新阅读目标社区规则。不要把推广伪装成中立讨论。用户能提出真实问题、团队能给出真实回答，才能让发布产生更可靠的证据。
发布条件： 每个已选渠道都有可用链接、符合语境的信息，以及发布窗口内能回复的负责人。
这份清单是对上面方法的压缩复核，不替代发布策略和发布计划。
如果需要一份更结构化、可评分的复核，可使用免费的 GTM 发布就绪度清单，从定位、素材、渠道、度量和迭代五方面检查后再确定发布日期。
标题里的“7 天”适用于产品已能工作、团队已有合理受众假设，并且有人能回复用户的情况。它是一场协调冲刺，而不是所有产品都应在一周内发布的承诺。
| 天数 | 当天完成的阶段 | 交付物 | 不满足时不要推进 |
|---|---|---|---|
| 第 1 天 | 策略 | 受众、问题、承诺、目标和不做的承诺 | 承诺不能演示，或下一步不清楚 |
| 第 2 天 | 计划 | 里程碑、负责人、渠道、依赖和风险 | 关键依赖没有负责人或暂停条件 |
| 第 3 天 | 素材 | 落地页、证明、CTA、上手路径和 FAQ | 团队外的人走不通核心路径 |
| 第 4 天 | 运营 | 追踪、链接标记、QA 和回复路径 | 看不到信号，或无法处理失败 |
| 第 5 天 | 分发 | 各渠道素材包和发布计划 | 规则、链接或回复安排未确认 |
| 第 6 天 | 演练 | 小范围测试与修正清单 | 关键困惑或路径问题未修复、未明确延后 |
| 第 7 天 | 发布与复盘 | 发布、回复记录和复盘安排 | 下一次实验没有负责人和日期 |
如果第 2 天发现产品承诺仍不清楚，不要假设第 3 天做更多素材就能解决，应当回到策略。如果第 5 天发现没有人能支持某个渠道，就删掉它。七天安排的价值，在于尽早暴露这些判断。
Product Hunt 只是一个渠道，不是产品发布的默认定义。若它确实适合你的受众，准备准确的文案、真实产品视觉素材和当天能回复的 maker。关于会变化的素材与提交要求，以 Product Hunt 官方准备指南 为准，不要依赖被复制的旧清单。
发布并不会在内容上线时结束。把结果与发布前设定的目标对照。
把证据分成四类：
不要因为一条评论或几个小时的低流量就推翻定位。观察重复信号，再选择一个与证据相称的下一步：修改信息、改善转化步骤、跟进高质量人群、测试另一个渠道，或暂停不适合受众的活动。
一份有用的发布复盘必须以决策结束： 保留、调整或暂停；一个负责人；一个下一次日期。
通常不建议。七天可以组织一个已经可用的产品或范围明确的 Beta；如果核心价值、访问路径、受众或支持方案仍未解决，应先补足这些基础，再公开发布。
至少包括主要目标、第一批受众、信息与证明、通往一个 CTA 的产品路径、选择的渠道、负责人、依赖、风险、数据来源和发布后复盘。只有日历、没有这些判断的内容，本质上只是待办列表。
策略解释选择：要触达谁、解决什么问题、能证明什么承诺，以及这次发布为什么重要。计划则把这些选择变成里程碑、素材、渠道、负责人和时间安排。
从目标受众已经注意信息、团队也能回答问题的最小渠道组合开始。既有邮件受众、相关社区、合作伙伴触达或发布平台，都可能合适，前提是信息、受众和支持能力相匹配。
用发布前确定的目标和它带来的证据来判断。合格激活、购买、重复出现的问题、转化阻力，或能够明确改变信息与渠道的理由，都属于有用证据；只有注意力并不够。
不是。它可能适合一部分产品和受众，但只是分发选择之一。只有当受众、素材和当天回复能力都匹配你的发布目标时，才值得把它纳入计划。
根据当前流程的下一步决策或任务，继续使用合适的工具。
Tiny
SEO/GEO
学习闭环