go-to-market

Go-To-Market スキル

このスキルは、製品、機能、または取り組みのための完全な Go-To-Market アセットパックを作成します。Geoffrey Moore のポジショニングフレームワークに従い、営業資料、ランディングページ、ローンチメール、社内の認識合わせ用ドキュメントで使えるよう、すべてのアウトプットを構成します。

ブリーフをもとに作成する

詳細がすべて含まれていない短いブリーフを受け取ることはよくあります。その場合でも、必ず完全な GTM パックを作成してください。質問して作業を止めたり、[ADD PROOF POINT] や [Technical capability] のような角括弧付きのプレースホルダーを残したりしないでください。差別化要因、裏付けとなる実績、機能などの詳細が不足している場合は、製品の説明とターゲット顧客から、具体的で現実的な内容を推測し、推測した内容には (仮定 — 要確認) と明記してください。具体的で、仮定だと明記された内容は、空欄よりも常に優れています。

入力（提示されていない項目は推測し、仮定であることを明記）

• 製品／機能名
• 一文での説明（技術的に何をするか）
• ターゲット顧客（役職、企業規模、該当する場合は業界）
• 解決する主な課題
• 主要な競合または代替手段（現在、この製品なしで人々が行っていること）
• 主な差別化要因 3 つ

Brain からの読み込み／Brain への書き込み

professional-brain（brain/）が存在する場合は、質問する前に利用してください。

• 最初に読むもの： context.md（製品、ICP、トーン）、knowledge/market.md と knowledge/strategy.md、およびローンチ対象に該当する entities/ の機能。
• 作成後に書き込むもの： ローンチ計画を entities/ に保存し、ポジショニングやチャネルに関する決定事項を、それぞれ出典情報を付けて decisions/ に保存します。

出力構成

以下の 4 つのセクションを、必ず順番どおりにすべて作成してください。

---

1. ポジショニングステートメント

Geoffrey Moore の形式をそのまま使用します。

[ターゲット顧客] に向けた、[この課題やニーズを抱えている] 顧客のための [製品名] は、[製品カテゴリー] です。[主なメリット／成果] を実現します。[主な代替手段または競合] とは異なり、当社の製品は [主な差別化要因] を提供します。

主となるポジショニングステートメントを 1 つ作成し、次に、ヒーロー見出しに適した短いタグライン（10 語以内）を提示してください。

---

2. メッセージの柱

メッセージの柱を 3～5 個作成します。各柱には、以下を含めてください。

• 柱の名前（2～4 語、太字）
• この柱が主張する内容をまとめた 1 文の要約
• 裏付けとなる実績 2～3 点（具体的で、証拠に基づくもの。データが提供されていない場合は、現実的な裏付けとなる実績を推測して (仮定) と明記します。未記入のプレースホルダーは絶対に残さないでください）
• コピーでの使用例（ランディングページや資料に掲載する場合の 1 文）

各柱は明確に区別し、重複を避けてください。どの柱も、主要な競合に対して裏付け可能な内容にしてください。

---

3. 機能一覧

2 列の表を作成してください。

機能／性能	購入者にとってのメリット（ユーザーにとって何を意味するか）
[Technical capability]	[平易な言葉で表した成果 — 「削減する…」「可能にする…」「なくす…」のように、動詞から始める]

ルール：

• 対応するメリットなしに機能を挙げないでください。
• メリットには、ターゲット顧客のワークフローまたは課題を反映させてください。
• 6～12 行を目安にしてください。提示された機能が 1～2 個のみの場合は、製品の説明から残りを妥当な範囲で推測してください。
• メリットの列では専門用語を避け、エンジニアではなく購入者に説明するように書いてください。

---

4. ユースケース

役割に応じたユースケースを 3～5 個作成してください。各ユースケースは、以下の形式に従ってください。

ユースケース [N]：[役割] — [シナリオ名]

• 対象者： [職種／役割]
• 状況： 製品を利用するきっかけとなる具体的な場面や出来事
• 導入前： この製品がない場合に必要だった作業（所要時間、手間、リスクを具体的に記載）
• [製品名] 導入後： 現在行う作業（曖昧なメリットではなく、具体的な行動）
• 成果： 測定可能または具体的に示せる結果

可能であれば、ユースケースは異なる購入者のペルソナを対象にしてください（例：エンドユーザー、マネージャー、管理者）。

---

詳細資料

このスキルにはサポートファイルが付属しています。利用可能な場合は活用してください。

• references/messaging-hierarchy.md — メッセージング階層：まず1つの主張を提示し、その後にすべてを伝える。出力を作成する際に活用してください。上記の手法の概要で要約された、調整の基準や判断の指針が記載されています。
• templates/gtm-pack.md — 品質ゲートがインラインで記載された、成果物の記入用テンプレートです。生成を依頼するのではなく、ユーザー自身でドキュメントを作成したい場合に提示してください。

スコアリング基準（0～40）

このスキルの出力は、提出前に採点してください。32点以上が出荷可能な品質です。

項目	0	5	10
ポジショニングの精度	汎用的な価値提案で、対象顧客も代替手段も示されていない	Moore 形式に従っているが、「～とは異なり」の節が曖昧	明確な対象セグメントを示した Moore 形式で、「～とは異なり」の節では購入者が比較検討する実際の代替手段を挙げている
メッセージと根拠の整合性	柱となるメッセージが裏付けのない主張である	裏付けとなるポイントはあるが、一部が主張の言い換えにすぎない	各柱に2つ以上の確かな裏付けポイントがある（または未確定のプレースホルダーであることが明示されている）。さらに、メッセージ階層の冒頭に1つの主張がある
機能からメリットへの変換	メリットを伴わない機能の羅列	メリットはあるが、受け身であったり機能の説明にとどまったりしている	すべての機能に、購入者が上司に説明するときにも使える、行動を表す動詞で始まるメリットがある
ローンチでの使いやすさ	ポジショニングのエッセイであり、パックになっていない	パックとしては完成しているが、各要素に一貫性がない	タグライン、柱、ユースケース、メリットの一覧がすべて同じストーリーを伝えており、ローンチページにそのまま使える

品質チェック

出力を提出する前に、以下を確認してください。

• ポジショニング文が Moore 形式に厳密に従っている
• タグラインが10語以内である
• 各柱に2つ以上の裏付けポイントがある（または未確定のプレースホルダーであることが明示されている）
• すべての機能にメリットがあり、孤立した機能がない
• メリットが行動を表す動詞で始まっている
• ユースケースに Before／After の構成が含まれている
• 言葉遣いが、社内のエンジニアリング用語ではなく、対象顧客の語彙に合っている

アンチパターン

• メリットの代わりに機能の説明を書かないでください。GTM パックでは、機能を顧客価値に置き換える必要があります
• すべての購入者ペルソナに同じメッセージを使わないでください。役割ごとに優先事項や言葉遣いは異なります
• どの競合製品にも当てはまるポジショニング文を作らないでください。差別化は具体的で、根拠を示せる必要があります
• 「対象外」のセクションを省略しないでください。対象外を定義すると、ポジショニングが明確になり、販売活動のミスマッチを防げます
• 具体的な職種や購入者の役割と結び付けずに、ユースケースを列挙しないでください

トリガーとなるフレーズの例

• 「[product] のポジショニング文を作成して」
• 「[feature] の GTM 計画を書いて」
• 「[product name] の主要な柱を教えて」
• 「[product] の機能とユースケースの一覧を作って」
• 「[X] をローンチします。メッセージングを手伝って」