L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Productivité · SKILL.md

go-to-market

go-to-market

為任何產品或功能製作上市(GTM)物料。當被要求做 GTM 計劃、定位陳述、產品釋出計劃、核心資訊支柱、使用場景或功能與利益清單時使用。產出完整的 GTM 物料包:定位陳述、資訊支柱、功能到利益的對應,以及按角色劃分的使用場景。需要跨部門協作的分級釋出計劃請使用 go-to-market-planner。

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentation de la Skill

GitHub

name: go-to-market language: zh-TW 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 enregistrées