La interfaz está localizada; las descripciones y documentos de las Skills se traducen automáticamente con IA a su idioma. El código, los comandos, rutas y términos técnicos se mantienen en el original, y prevalece el documento del autor.
Explorar Skills
Productividad · SKILL.md

go-to-market

go-to-market

为任何产品或功能制作上市(GTM)物料。当被要求做 GTM 计划、定位陈述、产品发布计划、核心信息支柱、使用场景或功能与利益清单时使用。产出完整的 GTM 物料包:定位陈述、信息支柱、功能到利益的对应,以及按角色划分的使用场景。需要跨部门协作的分级发布计划请使用 go-to-market-planner。

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentación de la Skill

GitHub

name: go-to-market language: zh description: "为任何产品或功能制作上市(GTM)物料。当被要求做 GTM 计划、定位陈述、产品发布计划、核心信息支柱、使用场景或功能与利益清单时使用。产出完整的 GTM 物料包:定位陈述、信息支柱、功能到利益的对应,以及按角色划分的使用场景。需要跨部门协作的分级发布计划请使用 go-to-market-planner。"

go-to-market 的简体中文翻译,英文版本为规范版本。

上市(GTM)

这个技能为一个产品、功能或计划制作完整的上市物料包。它遵循 Geoffrey Moore 的定位框架,所有产出都整理成可直接用于销售演示、落地页、发布邮件和内部对齐文档的结构。

从简要说明开始工作

你常常会拿到一份简短的说明,缺少一些细节。无论如何都要交付完整的 GTM 物料包:不要停下来提问,也不要留下 [ADD PROOF POINT] 或 [Technical capability] 这样的方括号占位符。缺少细节时(差异点、证明点、功能),根据产品描述和目标客户推断具体、现实的内容,并把任何推断的内容标注为 (假设,待确认)。具体且标注清楚的假设,永远好过空白。

输入(未提供的可推断,并标注假设)

  • 产品或功能名称
  • 一句话描述(从技术上说它做什么)
  • 目标客户(角色、公司规模,相关时写行业)
  • 它解决的主要问题
  • 主要竞品或替代方案(没有它时人们现在怎么做)
  • 最重要的 3 个差异点

从大脑读取 / 写入大脑

如果存在 professional-brain(brain/),先用它再提问:

  • 先读: context.md(产品、理想客户画像、语气)、knowledge/market.md 和 knowledge/strategy.md,以及对应的要发布的 entities/ 功能。
  • 之后写: 把发布计划保存到 entities/,把定位或渠道决策记入 decisions/,都标注来源。

输出结构

总是按顺序产出下面四个部分。


1. 定位陈述

严格使用 Geoffrey Moore 的格式:

对于 [目标客户],他们 [有这个问题或需要],[产品名称] 是一款 [产品品类],能够 [关键利益或结果]。不同于 [主要替代方案或竞品],我们的产品 [关键差异点]。

写一条主定位陈述,再给一个更短的口号版本(不超过 10 个英文词或约 15 个汉字),适合做首屏标题。


2. 信息支柱

生成 3 到 5 个信息支柱。每个支柱必须包含:

  • 支柱名称(2 到 4 个词,加粗)
  • 一句话概括这个支柱主张什么
  • 2 到 3 个证明点(具体、有证据;如果没提供数据,推断一个现实的证明点并标注 (假设),绝不留下空占位符)
  • 文案中的用法示例(它出现在落地页或演示中时的一句话)

支柱之间要有区别,避免重叠。每个支柱都要能在主要竞品面前站得住。


3. 功能与能力清单

给出两列表格:

功能 / 能力买家利益(对用户意味着什么)
[技术能力][用通俗语言写的结果,以动词开头:"减少……"、"让……成为可能"、"消除……"]

规则:

  • 绝不列出没有对应利益的功能
  • 利益要提到目标客户的工作流或痛点
  • 目标 6 到 12 行;如果只给了 1 到 2 个功能,根据产品描述合理推断其余的
  • 利益一栏避免术语:写得像在向买家解释,而不是向工程师

4. 使用场景

生成 3 到 5 个按角色划分的使用场景。每个场景按以下格式:

场景 [N]:[角色],[场景标题]

  • 谁: [职位 / 角色]
  • 情境: [让他们使用产品的具体时刻或触发点]
  • 之前: [没有这个产品时他们必须怎么做,具体写出时间、摩擦或风险]
  • 有了 [产品名称]: [他们现在怎么做,具体的行动而不是模糊的利益]
  • 结果: [可衡量或看得见的成果]

如果可能,场景要覆盖不同的买家角色(例如最终用户、经理、管理员)。


延伸材料

这个技能附带支持文件,可用时请使用:

  • references/messaging-hierarchy.md:信息层级:先一个主张,再说其他。在产出时应用它;它包含上面方法摘要压缩掉的校准和判断。
  • templates/gtm-pack.md:可填写的成果模板,质量关卡写在里面。当用户想自己完成文档而不是生成时提供。

评分量表(0 到 40)

交付前给这个技能的任何产出打分;32 分以上才算可以交付。

维度0510
定位精准度笼统的价值陈述,没有目标客户或替代方案遵循了 Moore 格式,但"不同于"一句很弱Moore 格式,目标细分市场清晰,"不同于"点出了买家真正在比较的替代方案
信息与证明的一致性支柱是没有支撑的主张有证明点,但有些只是换个说法重复主张每个支柱都有至少 2 个真正的证明点(或诚实标注的占位符),层级以一个主张开头
功能到利益的转化只有功能清单,没有利益有利益,但被动或仍是功能的样子每个功能都配一个以动词开头、买家会转述给老板的利益
发布可用性一篇定位文章,而不是物料包物料包齐全,但各部分之间不一致口号、支柱、场景和利益清单讲的是同一个故事,可以直接用于发布页

质量检查

交付前确认:

  • 定位陈述严格遵循 Moore 格式
  • 口号足够短(不超过 10 个英文词或约 15 个汉字)
  • 每个支柱至少有 2 个证明点(或标注的占位符)
  • 每个功能都有利益,没有孤立的功能
  • 利益以动词开头
  • 使用场景包含"之前 / 之后"结构
  • 语言符合目标客户的词汇(而不是内部工程术语)

反模式

  • 不要用功能描述代替利益:GTM 物料包必须把功能翻译成客户价值
  • 不要对所有买家角色使用同样的信息:每个角色的优先事项和语言都不同
  • 不要写出可以套用到任何竞品的定位陈述:差异化必须具体、站得住
  • 不要跳过"不适合谁":界定不适合谁能让定位更清晰,并避免销售精力用错方向
  • 不要列出不与具体职位或买家角色挂钩的使用场景

示例触发语

  • “为 [产品] 写一条定位陈述”
  • “为 [功能] 写一份 GTM 计划”
  • “给我 [产品名称] 的核心信息支柱”
  • “为 [产品] 做功能和使用场景清单”
  • “我们要发布 [X],帮我写发布信息”
Skills guardadas