technical-launch-planner

技术产品发布规划师

概览

为技术产品、开发者工具、API、SDK 和平台规划并执行成功的发布。本技能提供专为技术受众和面向开发者的产品设计的框架、清单和模板。

适用于：

• 开发者工具和平台
• API 和 SDK
• 技术基础设施产品
• B2D（企业对开发者）产品
• 面向技术买家的 SaaS

---

快速入门

1. 评估发布级别

运行交互式评估：

scripts/assess_launch_tier.sh

该评估将确定发布级别：

• Tier 1（重大／正式发布）——新产品、重大版本、重要扩展
• Tier 2（标准）——新功能、集成、区域扩展
• Tier 3（次要）——更新、改进、小型功能

2. 生成发布计划

创建完整的发布计划：

scripts/generate_launch_plan.sh

提供结构化计划，包括：

• 时间线和里程碑
• 利益相关方职责
• 开发者赋能清单
• 上市活动
• 发布日行动手册

3. 验证准备情况

发布前，检查准备情况：

scripts/validate_readiness.sh

验证以下内容：

• 文档是否完整
• 技术资料是否就绪
• 利益相关方是否达成一致
• 信息传达是否已最终确定
• 指标埋点是否就绪

---

核心发布框架

发布级别

不同的发布需要不同程度的投入：

级别	类型	示例	投入
Tier 1	重大	正式发布、新产品、重大版本	全面 GTM、活动、公关
Tier 2	标准	新功能、集成、SDK	选择性 GTM、博客、文档
Tier 3	次要	更新、改进、补丁	更新日志、应用内发布

完整框架请参阅 references/launch_tiers.md。

---

面向开发者的发布组件

1. 开发者赋能

对技术产品发布至关重要：

文档：

• 入门指南
• API 参考
• 代码示例
• 集成指南
• 迁移指南（如适用）

代码资源：

• SDK／客户端库
• 示例应用
• 入门模板
• 代码片段

开发者体验：

• 沙盒／操场环境
• 交互式教程
• API 浏览器
• 调试工具

完整清单请参阅 references/developer_enablement.md。

---

2. 技术信息传达

使用开发者熟悉的语言：

避免：

• 营销行话
• 含糊的优势描述
• 非技术性的夸大用语

包含：

• 具体的技术细节
• 性能指标
• 代码示例
• 架构图
• 集成模式

模板请参阅 references/launch_messaging.md。

---

3. 面向开发者的发布渠道

开发者发现新工具的渠道：

主要渠道：

• 开发者文档
• GitHub/GitLab
• 开发者博客
• API 更新日志
• 发布说明

次要渠道：

• Dev.to、Hacker News、Reddit
• 技术类 Twitter/X
• Discord/Slack 社区
• YouTube（教程）
• 开发者通讯

其他渠道：

• 网络研讨会／工作坊
• 会议
• 播客
• 案例研究

---

发布规划工作流

阶段 1：规划（发布前 12 至 8 周）

目标：

• 确定发布级别
• 设定成功标准
• 协调利益相关方
• 制定时间线

活动：

1. 发布级别评估

   scripts/assess_launch_tier.sh
   

2. 利益相关方启动会

   • 产品／工程
   • 开发者关系
   • 销售工程
   • 市场／传播
   • 合作伙伴（如适用）

3. 定义成功指标

   • 开发者采用指标
   • API 使用量／调用次数
   • SDK 下载量
   • 文档流量
   • 社区参与度

4. 制定发布计划时间线

   scripts/generate_launch_plan.sh
   

---

阶段 2：构建（T-8 至 T-4 周）

目标：

• 创建所有发布素材
• 准备文档
• 构建演示和示例

活动：

文档：

• 编写入门指南
• 完成 API 参考
• 准备好集成指南
• 迁移指南（如有需要）
• 故障排查常见问题解答

代码素材：

• 构建并测试 SDK
• 创建示例应用
• 准备代码片段
• 准备好沙盒环境

营销素材：

• 撰写技术博客文章
• 录制演示视频
• 起草公告邮件
• 社交媒体计划
• 新闻稿（第 1 级）

销售支持：

• 技术竞争对比卡
• 演示脚本
• 常见问题／异议处理
• 定价材料
• 竞争定位

---

阶段 3：准备（T-4 至 T-1 周）

目标：

• 审查并完善所有素材
• 培训团队
• 发布前验证

活动：

内部赋能：

• 培训销售团队
• 培训支持团队
• 合作伙伴简报会
• 内部演示日

外部准备：

• 向 Beta 客户介绍
• 协调合作伙伴
• 准备好开发者倡导者
• 准备好社区版主

技术验证：

scripts/validate_readiness.sh

发布前检查清单：

• 所有文档已发布到预发布环境
• SDK 已打标签并准备就绪
• 已测试演示环境
• 已配置监控／分析
• 已确定支持升级路径

---

阶段 4：发布（发布日）

发布日行动手册：

上午（9 AM）：

• 发布文档
• 发布 SDK／软件包
• 发布博客文章
• 发送公告邮件
• 发布社交媒体内容
• 更新网站／产品页面

中午（12 PM）：

• 监控指标仪表板
• 回应社区问题
• 分享到外部社区
• 参与社交媒体提及互动

下午（3 PM）：

• 在 Hacker News/Reddit 发布（若为第 1 级）
• 发布开发者倡导者内容
• 合作伙伴公告

当天结束时：

• 第 1 天指标报告
• 团队复盘
• 问题分类处理

---

阶段 5：发布后（T+1 周至 T+4 周）

目标：

• 监控采用情况
• 收集反馈
• 迭代优化宣传信息
• 汇报结果

活动：

第 1 周：

• 每日监控指标
• 社区问答
• 优先处理错误修复
• 汇总反馈

第 2 周：

• 首批采用情况指标
• 客户反馈访谈
• 更新文档
• 后续内容

第 4 周：

• 发布复盘
• 成功指标报告
• 经验总结文档
• 更新发布行动手册

---

发布级别详情

第 1 级：重大发布

适用情况：

• 新产品正式发布
• 主要版本发布（v2.0、v3.0）
• 重要的平台扩展
• 颠覆性功能

时间线： 12-16 周

投入：

• 全面的跨职能 GTM
• 公关／媒体推广
• 开发者活动
• 合作伙伴协调
• 付费推广

交付内容：

• 完整文档
• 多种 SDK
• 示例应用
• 视频教程
• 交互式演示
• 新闻稿
• 分析师简报会
• 发布活动／网络研讨会
• 合作伙伴联合营销

---

第 2 级：标准发布

适用情况：

• 新功能
• 新集成
• 其他 SDK
• 区域扩展

时间线： 6-8 周

投入：

• 有选择地开展 GTM 活动
• 博客和社交媒体
• 向开发者邮件列表发送邮件
• 更新文档

交付内容：

• 功能文档
• 代码示例
• 博客文章
• 演示视频
• 公告邮件
• 社交媒体内容
• 更新日志条目

---

第 3 级：小型发布

适用情况：

• 增量改进
• 错误修复
• 性能增强
• 小型功能添加

时间线： 2-4 周

投入：

• 最少的营销活动
• 仅更新文档
• 更新日志

交付内容：

• 发行说明
• 更新后的文档
• 更新日志条目
• 应用内通知（如适用）

---

开发者发布最佳实践

1. 文档优先

没有以下内容，发布就尚未准备就绪：

• ✅ 入门指南
• ✅ API 参考
• ✅ 至少 3 个代码示例
• ✅ 集成指南

开发者准则：“没有文档记录的内容，就等于不存在”

---

2. 展示，而非空谈

开发者想看代码：

好的示例：

# Initialize the SDK
import acme_sdk

client = acme_sdk.Client(api_key="your_key")
result = client.widgets.create(name="My Widget")
print(result.id)

不好的示例： “我们的 SDK 能让你只用几行代码就轻松创建小组件”

---

3. 互动优于被动浏览

参与度层级：

1. 🥇 互动式教程／练习场
2. 🥈 实时演示
3. 🥉 演示视频
4. ❌ 静态截图

---

4. 诚实的技术沟通

开发者欣赏：

• 清楚说明限制
• 性能特征
• 透明的定价
• 迁移复杂度
• 破坏性变更

开发者反感：

• 过度承诺
• 隐藏限制
• 意外的破坏性变更
• 供应商锁定

---

5. 社区优先

在开发者活跃的地方参与交流：

• 在 Stack Overflow 上回答问题
• 积极参与 GitHub 讨论
• 在 Hacker News 上回应
• 加入相关的 Discord／Slack 社区
• 参与 Reddit AMA

不要：

• 在社区刷屏
• 忽视负面反馈
• 删除批评性评论
• 只在发布时露面

---

技术指标

开发者采用指标

激活：

• 沙盒／试用注册数
• 24 小时内首次调用 API 的人数
• SDK 下载量
• “Hello World” 示例完成数

参与度：

• 日活／周活开发者
• 每位开发者的 API 调用次数
• 已采用的功能
• 集成深度

留存：

• 第 7、30、90 天的开发者留存率
• 流失率
• NPS（开发者）

完整指南请参阅 references/metrics_frameworks.md。

---

发布模板

技术博客文章模板

# Introducing [Feature/Product]

## The Problem

[Describe the developer pain point in technical detail]

## The Solution

[High-level technical overview]

## How It Works

[Technical architecture, with diagram]

## Getting Started

[Code sample showing basic usage]

## What's Next

[Roadmap tease]

[Link to full documentation]

---

发布邮件模板

主题：[Feature] 现已推出

正文：

Hi [Developer Name],

We're excited to announce [Feature] is now generally available.

What it does:
[One sentence technical description]

Why it matters:
[Developer benefit]

Get started in 5 minutes:
[Code snippet or quick start link]

Key resources:
- Documentation: [link]
- Sample code: [link]
- API reference: [link]

Questions? Reply to this email or join us in [Discord/Slack].

Happy building!
[Your Name]

---

更新日志条目模板

## [Version] - YYYY-MM-DD

### Added
- [New feature]: [Technical description]
  - Example: `client.newMethod(params)`
  - [Link to docs]

### Changed
- [Breaking change]: [What changed and why]
  - Migration guide: [link]

### Fixed
- [Bug fix]: [What was fixed]

### Deprecated
- [Feature]: [Timeline for removal]

---

合作伙伴／集成发布

有合作伙伴时

需要协调的事项：

• 联合宣传信息
• 联合营销计划
• 技术验证
• 相互提供客户案例

合作伙伴准备工作：

• 已测试技术集成
• 合作伙伴文档
• 联合案例研究
• 联合品牌素材
• 销售团队培训

发布活动：

• 联合撰写博客文章
• 联合举办网络研讨会
• 在社交媒体上交叉推广
• 向双方邮件列表发送邮件
• 相互发布新闻稿（Tier 1）

---

发布回顾

发布后评估（30 天内）

指标回顾：

• 我们是否达成了采用目标？
• 第 1 天、第 1 周、第 1 个月的使用情况如何？
• 开发者的态度如何（NPS、社交媒体、支持反馈）？
• 是否获得媒体／分析师报道（如适用）？

哪些做得好：

• 哪些渠道带来了最多的采用？
• 哪些内容最受欢迎？
• 哪些赋能素材使用最多？

哪些做得不好：

• 开发者在哪些地方遇到了阻碍？
• 缺少哪些文档？
• 哪些假设是错误的？

行动事项：

• 改进文档
• 优化宣传信息
• 改进下一次发布的流程

模板：[在 Notion/Confluence 中记录]

---

常见陷阱

陷阱 1：文档不完整就发布

问题：“文档很快就会准备好”＝发布失败

**解决方案：**文档不可妥协。必要时推迟发布。

---

陷阱 2：对开发者使用营销话术

问题：“革命性”“无缝”“颠覆性”

**解决方案：**使用具体的技术语言、指标和代码。

---

陷阱 3：忽视迁移复杂度

**问题：**有破坏性变更，却没有迁移指南

**解决方案：**提供清晰的迁移指南、迁移工具和版本支持计划。

---

陷阱 4：过度聚焦发布日

**问题：**所有精力都放在第 1 天，后续采用无人跟进

**解决方案：**规划发布后 4 周的内容日历。

---

陷阱 5：没有开发者反馈闭环

**问题：**发布后就消失

**解决方案：**积极参与社区，定期安排开放交流时间。

---

资源

脚本

• assess_launch_tier.sh - 确定合适的发布层级
• generate_launch_plan.sh - 制定全面的发布计划
• validate_readiness.sh - 发布前就绪情况检查

参考资料

• launch_tiers.md - 完整的发布层级框架
• developer_enablement.md - 开发者支持清单
• launch_messaging.md - 技术宣传模板
• metrics_frameworks.md - 开发者产品指标指南

---

真实案例

示例 1：API 正式发布（第 1 级）

产品： 面向开发者平台的新 REST API

时间线： 12 周

关键活动：

• 完成 API 文档
• 5 个 SDK（Python、Node、Ruby、Go、Java）
• 交互式 API 浏览器
• 10 个以上示例应用
• 视频教程系列
• 开发者网络研讨会
• 博客文章和案例研究
• 在 HN/Reddit 上发布
• 向 5 万名开发者发送邮件

结果：

• 第 1 周发放 1 万个 API 密钥
• 激活率为 60%（发起首次 API 调用）
• 第 7 天留存率为 40%
• 登上 Hacker News 榜首

---

示例 2：新增集成（第 2 级）

产品： 与热门 DevOps 工具集成

时间线： 6 周

关键活动：

• 集成指南
• 示例工作流
• 博客文章
• 与合作伙伴联合营销
• 演示视频
• 邮件公告

结果：

• 第 1 个月激活 2,000 次集成
• 25% 的现有用户尝试了该功能
• 用户参与度指标良好

---

示例 3：SDK 更新（第 3 级）

产品： 提升性能的新版本 SDK

时间线： 2 周

关键活动：

• 发布说明
• 迁移指南
• 更新日志
• Tweet/X 帖子

结果：

• 第 1 周升级率为 30%
• 支持负担极小
• 社区反馈积极

---

总结

技术发布需要：

1. 完整文档 - 不可妥协
2. 代码示例 - 用实例说明，而非空谈
3. 开发者支持 - 让尝试变得轻松
4. 技术可信度 - 使用专业语言
5. 社区互动 - 出现在开发者聚集的地方
6. 明确的指标 - 衡量重要事项
7. 发布后持续投入 - 发布是第 1 天，而非终点

使用脚本简化规划，遵循框架保持一致，并始终将开发者放在首位。

立即开始：

scripts/assess_launch_tier.sh