product-launch

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

When this skill is activated, always start your first response with the 🧢 emoji.

激活该Skill后，首次回复请务必以🧢表情开头。

Product Launch

产品发布

A practical framework for planning, executing, and measuring product launches. Most launches fail not because of the product but because of poor coordination, rushed checklists, and no rollback plan. This skill covers the full launch lifecycle: scoping a go-to-market strategy, designing a beta program, building function-level launch checklists, planning tiered rollouts, writing internal and external communications, coordinating cross-functional teams, and measuring launch success. Agents can use this to draft GTM plans, run betas, sequence rollouts, and run launch retrospectives.

这是一个用于规划、执行和衡量产品发布的实用框架。大多数发布失败并非因为产品本身，而是由于协调不力、清单仓促制定以及缺乏回滚计划。该Skill覆盖发布全生命周期：制定上市（GTM）策略、设计Beta测试项目、构建职能级发布清单、规划分阶段上线、撰写内外部沟通内容、协调跨职能团队，以及衡量发布成效。Agent可借助它起草GTM计划、运营Beta测试、安排上线顺序，以及开展发布复盘。

When to use this skill

何时使用该Skill

Trigger this skill when the user:

Is planning or executing a product launch or major feature release
Needs to build a go-to-market strategy or launch plan
Wants to design or run a beta program (closed, open, or pilot)
Needs a launch checklist broken down by function (eng, marketing, support, legal)
Is planning a tiered or phased rollout (dark launch, beta, GA)
Needs to write launch communications - internal announcements, press releases, blog posts, or customer emails
Wants to coordinate a cross-functional launch squad or assign RACI ownership
Needs to define or review launch success metrics and run a launch retrospective
Asks about launch tiers, rollout strategy, or go-to-market execution

Do NOT trigger this skill for:

Detailed pricing model design (use the pricing-strategy skill instead)
Feature flag implementation details or release engineering tooling (use a deployment or CI/CD skill)

当用户有以下需求时触发该Skill：

正在规划或执行产品发布或重大功能上线
需要制定上市（GTM）策略或发布计划
想要设计或运营Beta测试项目（封闭、开放或试点）
需要按职能拆分的发布清单（工程、营销、客服、法务）
正在规划分阶段上线（暗发布、Beta测试、正式发布GA）
需要撰写发布沟通内容——内部公告、新闻稿、博客文章或客户邮件
想要协调跨职能发布小组或分配RACI职责
需要定义或审核发布成功指标并开展发布复盘
询问发布层级、上线策略或上市（GTM）执行相关问题

请勿在以下场景触发该Skill：

详细定价模型设计（请使用pricing-strategy Skill）
功能标志实现细节或发布工程工具（请使用部署或CI/CD相关Skill）

Key principles

核心原则

Launch is a process, not an event - A launch begins weeks before the public announcement and ends weeks after. The announcement date is one milestone in a longer arc that includes internal readiness, beta feedback, and post-launch iteration. Plan the full timeline, not just the day-of.
Tier launches by impact - Not every launch needs a press release and a company all-hands. Match the launch tier to the blast radius of the change. A bug fix ships silently. A new pricing model gets a full GTM program. Define launch tiers upfront and assign different checklists to each tier.
Internal launch before external - Every external launch should be preceded by an internal launch. Sales, support, and success teams must be able to answer customer questions before the announcement goes live. "Internal GA" is a real milestone; treat it as one.
Measure launch success - Define success metrics before launch, not after. Decide in advance what a successful week one looks like: activation rate, trial starts, pipeline influenced, NPS, support ticket volume. Agree on a green threshold. Measure against it. Run a retrospective within 30 days.
Have a rollback plan - For every launch, define the criteria that would trigger a rollback or pause and the exact steps to execute it. Rollback plans are written in calm; they are executed in chaos. Write them now.

发布是一个流程，而非单一事件 - 发布始于公开宣布前数周，结束于宣布后数周。宣布日期只是更长周期中的一个里程碑，其中包括内部准备、Beta测试反馈和发布后迭代。规划完整时间线，而非仅关注发布当天。
按影响划分发布层级 - 并非所有发布都需要新闻稿和公司全员会议。根据变更的影响范围匹配发布层级。Bug修复可静默发布；新定价模型需要完整的GTM方案。提前定义发布层级，并为每个层级分配不同的清单项。
先内部发布，再对外发布 - 每一次对外发布都应先完成内部发布。销售、客服和客户成功团队必须在公开宣布前能够解答客户问题。“内部正式发布（GA）”是一个真实的里程碑，应同等对待。
衡量发布成效 - 在发布前而非之后定义成功指标。提前确定首周成功的标准：激活率、试用启动数、受影响的销售线索、NPS、支持工单量。商定合格阈值，并以此为基准衡量。在30天内开展复盘。
制定回滚计划 - 针对每一次发布，定义触发回滚或暂停的标准，以及具体执行步骤。回滚计划需在冷静期撰写，在混乱中执行。现在就完成撰写。

Core concepts

核心概念

Launch tiers classify releases by scope and customer impact. Tier 1 is a major launch (new product, new market, major pricing change) - full GTM, press, exec involvement. Tier 2 is a significant feature - blog post, in-app announcement, sales enablement. Tier 3 is a minor improvement - release notes, internal notification. Tier 4 is a patch or internal change - changelog entry only. Assign tier at kickoff; the tier drives which checklist items are required.

GTM components are the building blocks of a go-to-market plan: target segment (who is this for), positioning (why this over alternatives), pricing and packaging, distribution channel (self-serve, sales-led, partner-led), launch timing, and success metrics. All six must be aligned before any launch activity begins.

Beta program types serve different purposes. A closed beta gives access to a hand-picked cohort for deep feedback - high quality signal, slow velocity. An open beta removes the gate - broader signal, noisier data. A pilot is a time-limited full deployment with a single customer or segment - best for enterprise products or regulated industries. Choose the type based on what you need to learn and how fast.

Launch metrics fall into three buckets: awareness (reach, share of voice, press mentions), activation (trial starts, sign-ups, demo requests, product qualified leads), and retention (week-1 return rate, feature adoption, churn delta in the 30 days post-launch). Track all three; optimize for the bucket that is weakest.

发布层级 根据范围和客户影响对版本进行分类。1级是重大发布（新产品、新市场、重大定价变更）——完整GTM、媒体报道、高管参与。2级是重要功能发布——博客文章、应用内公告、销售赋能。3级是小幅改进——发布说明、内部通知。4级是补丁或内部变更——仅更新变更日志。在启动时分配层级，层级决定所需的清单项。

GTM组件 是上市计划的构成要素：目标受众（面向谁）、定位（为何优于竞品）、定价与包装、分销渠道（自助、销售主导、合作伙伴主导）、发布时机和成功指标。所有六项必须在任何发布活动开始前保持一致。

Beta测试类型 用于不同目的。封闭Beta测试向精心挑选的用户群体开放，以获取深度反馈——信号质量高，但速度慢。开放Beta测试取消准入限制——信号范围更广，但数据噪音大。试点测试是与单个客户或细分市场进行的限时完整部署——最适合企业产品或受监管行业。根据你需要了解的内容和速度选择测试类型。

发布指标 分为三类：认知度（触达量、声量、媒体提及数）、激活率（试用启动数、注册数、演示请求数、产品合格线索）、留存率（首周回访率、功能采用率、发布后30天内的流失变化）。跟踪所有三类指标，针对最弱的类别进行优化。

Common tasks

常见任务

Create a GTM strategy

制定GTM策略

A go-to-market strategy answers six questions. Answer them in this order:

Who - Define the target segment precisely. Not "SMBs" but "engineering managers at Series A-C SaaS companies with 10-50 engineers."
Problem - State the specific pain the product solves for that segment. Quantify it if possible ("spend 4 hours/week on X").
Positioning - Write a positioning statement: "For [segment], [product] is the [category] that [key benefit] unlike [alternative] which [limitation]."
Pricing and packaging - Which tier or plan is the entry point? What is the upgrade path? Is there a free trial or freemium component?
Distribution - How does the segment discover and buy? Self-serve (product-led), sales-assisted (sales-led), or through a partner channel?
Success metrics - What does a successful launch look like at 7, 30, and 90 days? Name specific numbers and who owns them.

Codify all six in a one-page GTM brief before any execution begins.

上市（GTM）策略需回答六个问题，请按以下顺序作答：

谁 - 精准定义目标受众。不是“中小企业”，而是“A-C轮融资SaaS公司中管理10-50名工程师的工程经理”。
问题 - 说明产品为该受众解决的具体痛点。尽可能量化（“每周在X上花费4小时”）。
定位 - 撰写定位声明： “针对[受众]，[产品]是一款[品类]产品，可提供[核心价值]，而[竞品]存在[局限性]。”
定价与包装 - 哪个层级或套餐是入门选项？升级路径是什么？是否有免费试用或免费增值组件？
分销 - 受众如何发现并购买产品？自助式（产品主导）、销售协助式（销售主导）还是通过合作伙伴渠道？
成功指标 - 发布后7天、30天和90天的成功标准是什么？指定具体数值和负责人。

在开始任何执行工作前，将以上六项整理为一页GTM简报。

Design a beta program

设计Beta测试项目

Recruitment

Define who qualifies: segment, use case, technical maturity, time commitment
Aim for 15-50 participants for a closed beta (enough signal, manageable noise)
Recruit from existing waitlist, active customers, or outbound to target accounts
Set clear expectations: duration, feedback cadence, and what they get in return (early access, pricing discount, public recognition, direct product influence)

Feedback loops

Weekly check-in cadence: short async survey (5-7 questions) plus optional 30-minute call slot
Track usage data alongside qualitative feedback - usage tells you what they do, interviews tell you why
Maintain a shared tracker of reported issues, feature requests, and blockers with status updates visible to beta participants

Graduation criteria

Define graduation gates before the beta starts, not during
Minimum criteria: core user journey completion rate above threshold, no critical bugs open, support volume sustainable at scale, NPS or CSAT baseline established
Graduation is a decision meeting with eng, product, and CS present - not an automatic date flip

招募

定义合格标准：受众、使用场景、技术成熟度、时间投入
封闭Beta测试目标招募15-50名参与者（足够获取信号，且噪音可控）
从现有等待名单、活跃客户或目标客户群中招募
设定明确预期：测试时长、反馈频率，以及参与者的回报（提前访问、定价折扣、公开认可、直接影响产品方向）

反馈循环

每周沟通节奏：简短异步调查（5-7个问题）加可选30分钟通话时段
跟踪使用数据和定性反馈——使用数据告诉你用户做了什么，访谈告诉你原因
维护共享跟踪表，记录报告的问题、功能请求和障碍，并向Beta参与者公开状态更新

毕业标准

在Beta测试开始前而非期间定义毕业门槛
最低标准：核心用户旅程完成率超过阈值，无未解决的关键Bug，支持量可规模化，NPS或CSAT基准已建立
毕业需由工程、产品和客户成功团队共同参与决策会议，而非自动到点切换

Build a launch checklist

构建发布清单

Break the checklist by function and time horizon. See

references/launch-checklist.md

for the full copy-paste checklist.

Engineering - feature flags, performance benchmarks, error monitoring, rollback procedure, capacity plan, data migration tested

Product - positioning finalized, pricing approved, feature documentation complete, beta graduation signed off, launch tier confirmed

Marketing - landing page live (dark or staged), blog post drafted, social copy approved, email sequence queued, press brief sent (if Tier 1)

Sales - pitch deck updated, objection handling doc written, demo environment current, sales training completed, CRM fields updated for tracking

Customer Success / Support - help center articles published, support scripts written, escalation path defined, internal FAQ distributed, surge plan in place

Legal / Compliance - Terms of Service updated (if needed), privacy review completed, trademark cleared, any regulated market approvals obtained

按职能和时间范围拆分清单。完整的可复制清单请查看

references/launch-checklist.md

。

工程 - 功能标志、性能基准、错误监控、回滚流程、容量规划、数据迁移测试

产品 - 定位最终确定、定价获批、功能文档完成、Beta测试毕业签字确认、发布层级确认

营销 - 落地页上线（暗发布或分阶段）、博客文章草稿完成、社交文案获批、邮件序列就绪、媒体简报发送（若为1级发布）

销售 - 演示文稿更新、异议处理文档撰写、演示环境同步、销售培训完成、CRM字段更新以用于跟踪

客户成功/客服 - 帮助中心文章发布、客服脚本撰写、升级路径定义、内部FAQ分发、高峰应对计划就位

法务/合规 - 服务条款更新（如需）、隐私审核完成、商标获批、获取所有受监管市场的批准

Plan a tiered rollout

规划分阶段上线

A tiered rollout reduces risk by exposing new functionality progressively.

Stage 1 - Dark launch (internal only)

Feature is live in production but gated to internal users (flag or allowlist)
Goal: validate infrastructure, monitor error rates, confirm logging is correct
Exit criteria: zero critical errors over 48 hours of internal use

Stage 2 - Closed beta (1-5% of users or hand-picked cohort)

Enable for a small, willing cohort that opted in
Goal: gather qualitative feedback, surface UX friction, confirm core value
Exit criteria: beta graduation threshold met

Stage 3 - Limited GA (10-25% traffic or specific segment)

Ramp up via feature flag or regional rollout
Goal: validate at scale, monitor support volume, watch activation metrics
Exit criteria: activation rate at or above target, support ticket rate below cap

Stage 4 - General availability (100%)

Full launch with marketing activation
Monitor closely for 72 hours post-launch; have on-call coverage
Rollback trigger: error rate spike above baseline, P0 bug, or activation rate below 50% of target after 48 hours

分阶段上线通过逐步开放新功能来降低风险。

阶段1 - 暗发布（仅内部）

功能在生产环境上线，但仅限内部用户访问（通过标志或白名单）
目标：验证基础设施、监控错误率、确认日志正确
退出标准：内部使用48小时内无关键错误

阶段2 - 封闭Beta测试（1-5%用户或精心挑选的群体）

向自愿参与的小群体开放
目标：收集定性反馈、发现UX痛点、确认核心价值
退出标准：达到Beta测试毕业阈值

阶段3 - 有限正式发布（10-25%流量或特定受众）

通过功能标志或区域发布逐步扩大范围
目标：规模化验证、监控支持量、观察激活指标
退出标准：激活率达到或超过目标，支持工单率低于上限

阶段4 - 正式发布（100%开放）

配合营销活动全面上线
发布后72小时密切监控；安排值班人员
回滚触发条件：错误率超过基线、P0级Bug、或48小时后激活率低于目标的50%

Write launch communications

撰写发布沟通内容

Internal announcement (pre-launch, T-5 days) Structure: what is launching, who it is for, how it works (one paragraph), what changed from the previous version, key dates, and where to get help. Distribute to all-hands Slack, sales channel, and support channel simultaneously.

External blog post (launch day) Structure: problem being solved (lead with customer pain), solution overview (show don't tell - screenshot or short video), customer quote or beta user story, availability and pricing, call to action. Keep under 800 words. Publish at 9am in the target market's timezone.

Customer email (launch day or T+1) Subject line: lead with the benefit, not the feature name ("Save 3 hours a week on X" beats "Introducing Y"). Body: one paragraph on the problem, two sentences on the solution, one CTA button. No attachments. Mobile-optimized.

Press release (Tier 1 only) Format: headline, dateline, lead paragraph (who/what/when/where/why), product details paragraph, customer or partner quote, boilerplate, contact info. Send to press contacts under embargo 48 hours before publication.

内部公告（发布前5天，T-5） 结构：发布内容、面向人群、工作方式（一段）、与之前版本的差异、关键日期，以及获取帮助的渠道。同时发布到全员Slack频道、销售频道和客服频道。

外部博客文章（发布当天） 结构：解决的问题（从客户痛点切入）、解决方案概述（展示而非讲述——截图或短视频）、客户评价或Beta用户故事、可用性和定价、行动号召。字数控制在800字以内。在目标市场时区的上午9点发布。

客户邮件（发布当天或次日，T+1） 主题：突出价值而非功能名称（“每周在X上节省3小时”优于“推出Y功能”）。正文：一段说明问题，两句介绍解决方案，一个行动号召按钮。无附件，适配移动端。

新闻稿（仅1级发布） 格式：标题、发稿地点及日期、导语（人物/事件/时间/地点/原因）、产品细节段落、客户或合作伙伴评价、公司简介、联系方式。在发布前48小时 embargo（禁发）状态下发送给媒体联系人。

Coordinate cross-functional launch

协调跨职能发布

Use a RACI to eliminate ambiguity on every launch deliverable.

Deliverable	R (Does)	A (Owns)	C (Consulted)	I (Informed)
GTM brief	Product	Product	Marketing, Sales	Exec
Landing page	Marketing	Marketing	Product, Design	All
Blog post	Marketing	Marketing	Product	All
Sales enablement	Sales	Sales	Product, Marketing	CS
Help center articles	CS/Support	CS	Product	Support
Feature flags / rollout	Eng	Eng Lead	Product	All
Press outreach	Marketing	Marketing	Exec	Legal
Launch metrics dashboard	Data/Eng	Product	Analytics	All

Run a launch readiness review 48 hours before go-live. All R and A owners confirm their deliverables are complete. Any open blocker halts the launch.

使用RACI矩阵消除每个发布交付物的职责模糊。

交付物	R（执行方）	A（负责人）	C（咨询方）	I（告知方）
GTM简报	产品	产品	营销、销售	高管
落地页	营销	营销	产品、设计	全员
博客文章	营销	营销	产品	全员
销售赋能材料	销售	销售	产品、营销	客户成功
帮助中心文章	客户成功/客服	客户成功	产品	客服
功能标志/上线	工程	工程负责人	产品	全员
媒体 outreach	营销	营销	高管	法务
发布指标仪表盘	数据/工程	产品	分析	全员

在上线前48小时召开发布就绪评审会。所有执行方和负责人确认交付物已完成。任何未解决的障碍将暂停发布。

Measure launch success

衡量发布成效

Pre-launch: define the scorecard

Before launch, fill in this template and get stakeholder agreement:

Metric	Target (Day 7)	Target (Day 30)	Owner
Trial starts / sign-ups	X	X	Marketing
Activation rate (core action)	X%	X%	Product
Week-1 retention	X%	-	Product
NPS / CSAT	X	X	CS
Support ticket volume	< X/day	-	Support
Pipeline influenced	$X	$X	Sales

Post-launch retrospective (Day 30)

What did we target vs achieve on each metric?
What went well in the launch process?
What friction did the cross-functional team experience?
What would we change in the checklist or process for next time?
Are there follow-up product changes driven by launch feedback?

Document the retro output and add lessons to the team's launch playbook.

发布前：定义计分卡

发布前，填写以下模板并获得相关方同意：

指标	目标（第7天）	目标（第30天）	负责人
试用启动数/注册数	X	X	营销
激活率（核心操作）	X%	X%	产品
首周留存率	X%	-	产品
NPS/CSAT	X	X	客户成功
支持工单量	< X/天	-	客服
受影响的销售线索	$X	$X	销售

发布后复盘（第30天）

每个指标的目标值与实际达成情况对比如何？
发布流程中哪些环节做得好？
跨职能团队遇到了哪些摩擦？
下次发布的清单或流程需要做出哪些调整？
发布反馈是否驱动后续产品变更？

记录复盘结果，并将经验教训添加到团队的发布手册中。

Anti-patterns / common mistakes

反模式/常见误区

Mistake	Why it fails	What to do instead
Setting the launch date before the product is ready	Creates pressure to ship incomplete work; leads to support surges and negative first impressions	Set dates from graduation criteria upward, not from a calendar downward
Skipping internal launch	Sales and support get blindsided; customers hear conflicting information	Ship internally at T-5; hold a readiness call with every customer-facing team
Launching without a rollback plan	When something breaks post-launch, teams scramble without clear ownership or steps	Write rollback criteria and procedure before the launch; test it in staging
Measuring only top-of-funnel metrics	Awareness numbers look good while activation and retention quietly fail	Define and track all three buckets: awareness, activation, retention
Big-bang rollout for a risky change	A bug at 100% exposure reaches all users simultaneously	Always ramp via feature flags or staged rollout; reserve 100% for confirmed stable state
Treating every release as a Tier 1 launch	Team exhaustion; diminishing attention; cry-wolf effect with press and customers	Define launch tiers at kickoff; reserve full GTM effort for true Tier 1 releases

误区	失败原因	正确做法
在产品准备好之前设定发布日期	导致压力下交付不完整的产品；引发支持量激增和负面第一印象	根据毕业标准向上推导日期，而非从日历向下设定
跳过内部发布	销售和客服措手不及；客户听到矛盾信息	在T-5时内部发布；与所有客户-facing团队召开就绪会议
无回滚计划就发布	发布后出现问题时，团队在无明确职责或步骤的情况下慌乱应对	发布前撰写回滚标准和流程；在预演环境中测试
仅衡量漏斗顶部指标	认知度数据好看，但激活和留存悄然失败	定义并跟踪三类指标：认知度、激活率、留存率
对高风险变更采用一次性全量发布	100%暴露时出现的Bug会影响所有用户	始终通过功能标志或分阶段上线逐步扩大范围；仅在确认稳定后才全量开放
将所有版本都视为1级发布	团队疲惫；关注度下降；对媒体和客户产生“狼来了”效应	启动时定义发布层级；仅为真正的1级发布投入完整GTM资源

References

参考资料

For a detailed, ready-to-use checklist broken down by function and launch phase, load the reference file:

```
references/launch-checklist.md
```
- comprehensive launch checklist organized by function (Engineering, Product, Marketing, Sales, CS/Support, Legal) and time horizon (T-30 through T+30), suitable for copy-paste into any project management tool

Only load the reference file when actively building or running a launch - it is long and will consume context.

如需按职能和发布阶段拆分的详细可复用清单，请加载参考文件：

```
references/launch-checklist.md
```
- 全面的发布清单，按职能（工程、产品、营销、销售、客户成功/客服、法务）和时间范围（T-30至T+30）组织，可直接复制粘贴到任何项目管理工具中

仅在积极构建或执行发布时加载参考文件——文件较长，会占用上下文资源。