ローンチ戦略
このスキルは、構造化された反復可能なフレームワークを使用して製品ローンチの計画と実行を支援します。核となる洞察：ほとんどのチームは大きな派手なローンチしか行いません。すべてのリリースを、その重要性に応じてスケールされた潜在的なローンチの瞬間として扱うことで、一貫した認知、獲得、アクティベーションを構築できます。目標は、単発のイベントではなく、ローンチエンジンを構築することです。
ローンチ階層
すべてのリリースは3つの階層のいずれかにマッピングされます。階層によって、メッセージング、アセット、配信にかける労力が決まります。
Tier 1: 主要新製品またはプラットフォームの転換
本格的なローンチ。旗艦となる瞬間、つまり新製品、大規模リブランド、プラットフォーム拡張など。準備には2〜4週間を見込みます。
典型的なアセット： ローンチビデオ（モーションデザインまたは創業者ナラティブ）、専用ランディングページ、ブログ投稿、プレス向けアウトリーチ、ソーシャルキャンペーン（全プラットフォーム）、全リストへのメール、内部増幅プッシュ。
Tier 2: 主要新機能
ユーザーができることを変える有意義な追加機能。それ自体で発表に値するが、本格的なメディア展開は不要。準備には1〜2週間を見込みます。
典型的なアセット： ローンチツイート/スレッド、ブログ投稿またはチェンジログエントリ、更新されたランディングページセクション、該当セグメントへのメール、2〜3プラットフォームでのソーシャル投稿。
Tier 3: 小規模な改善と反復
バグ修正、UIの洗練、段階的な改善。それでも発表する価値はあります。勢いと配慮を示すシグナルとなります。準備時間：数時間から1日。
典型的なアセット： チェンジログエントリ、単一のソーシャル投稿、ダイジェストでのオプションのメール言及。
階層の選択
「もし潜在的な顧客がこの発表を見たら、製品の能力に対する認識は変わるだろうか？」と自問してください。はい → Tier 1 または 2。品質や信頼性に関するもの → Tier 3。
迷ったら、階層を上げてください。過小ローンチは過大ローンチよりも一般的です。Tier 3であるべきTier 2のローンチは数時間の追加コストで済みます。Tier 3として扱われたTier 1のローンチは、成長の機会損失です。
メッセージングフレームワーク
メッセージングはすべてに優先します。メッセージングが確定するまでアセットを構築しないでください。優れたメッセージングを持つ平凡なビデオは、混乱したポジショニングを持つ美しいビデオよりも優れたパフォーマンスを発揮します。
メッセージングブリーフ
すべてのローンチ（任意の階層）について、以下を定義します：
-
名前 — これを何と呼びますか？SEOの可能性がある機能の場合、検索データを使用して選択します。人々が実際に検索しているものを確認します（例：「speech to text」 vs. 「transcription API」 — オーディエンスが一致する場合、よりボリュームのある方を選びます）。Google Trendsやキーワード調査プラットフォームなどのツールが役立ちます。
-
オーディエンス — 誰が具体的に恩恵を受けますか？正確に。「開発者」は広すぎます。「リアルタイム音声アプリを構築するバックエンドエンジニア」は、対象を絞って書くことができます。
-
主要な価値提案 — 一文。以前はできなかったが、今では何ができるようになったのか、または何が劇的に改善されたのか？これがあらゆる場所の見出しになります。
-
副次的な価値提案 — 2〜3の補足ポイント。ブログ投稿、ランディングページのセクション、スレッドのツイートを補完します。
-
証明ポイント — 数値、ベンチマーク、比較、顧客の声。価値提案を希望的観測ではなく具体的にするもの。
メッセージングテスト
主要な価値提案を声に出して読んでください。競合他社の製品も同様に説明できる場合、それは一般的すぎます。最高の価値提案は、ターゲットオーディエンスの誰かが、これが自分にとってのものかどうかをすぐに判断できるほど具体的です。
ローンチチェックリストシステム
すべての可能なローンチアクションを含むマスターチェックリストを、階層ごとに整理して作成します。新しいローンチごとに：
- マスターチェックリストを新しいインスタンス（新しいタブ、新しいチケット、新しいページ）にコピーします
- この階層/ローンチに該当しない行を削除します
- 残りの行に所有者と期日を割り当てます
- ローンチ日まで唯一の情報源として使用します
ツール
1つのシステムを選び、それにコミットします。特定のツールよりも一貫した使用が重要です。
- スプレッドシート（Google Sheets、Notionテーブル）— 最もシンプル。小規模チームに適しています。1つのマスターシート、ローンチごとに1つのタブ。欠点：組み込みの割り当てや通知がない。
- プロジェクト管理ツール（Linear、Asana、Notion）— チームに適しています。ローンチテンプレートプロジェクトを作成します。各ローンチは、割り当て可能なタスクと期日付きのコピーを取得します。LinearラベルやAsanaセクションは、以下の階層列にマッピングできます。
- ドキュメント + チェックリスト（Notion、Google Docs）— 中間点。チェックボックス付きのテンプレートドキュメント。コピーは簡単ですが、複数のローンチにわたるステータスの追跡は困難です。
どのツールを使用する場合でも、レトロスペクティブのたびにマスターテンプレートを更新してください。テンプレートは生きたドキュメントであり、ローンチを重ねるごとに改善されます。
チェックリストテンプレート構造
| カテゴリ | アクション | Tier 1 | Tier 2 | Tier 3 | 所有者 | 期日 | ステータス |
|---|---|---|---|---|---|---|---|
| メッセージング | メッセージングブリーフを作成 | ✓ | ✓ | ✓ | |||
| メッセージング | 命名のためのSEOキーワード調査 | ✓ | 任意 | — | |||
| アセット | ローンチビデオ | ✓ | 任意 | — | |||
| アセット | ランディングページ（新規または更新） | ✓ | ✓ | — | |||
| アセット | ブログ投稿 | ✓ | ✓ | 任意 | |||
| アセット | チェンジログエントリ | ✓ | ✓ | ✓ | |||
| ソーシャル | ローンチツイート/スレッド | ✓ | ✓ | ✓ | |||
| ソーシャル | LinkedIn投稿 | ✓ | ✓ | 任意 | |||
| ソーシャル | その他プラットフォーム（BlueSky、Threads） | ✓ | 任意 | — | |||
| 配信 | Product Huntへの提出 | ✓ | 任意 | — | |||
| 配信 | Hacker Newsへの投稿 | ✓ | 任意 | — | |||
| 配信 | プレス/ジャーナリストへのアウトリーチ | ✓ | — | — | |||
| 配信 | インフルエンサー/ネットワークへの再投稿依頼 | ✓ | ✓ | — | |||
| メール | 全リストへのアナウンス | ✓ | — | — | |||
| メール | セグメント固有のメール | 任意 | ✓ | — | |||
| メール | チェンジログダイジェストでの言及 | — | 任意 | ✓ | |||
| 内部 | #amplifyチャンネルへの投稿 | ✓ | ✓ | 任意 | |||
| 内部 | チームブリーフィング | ✓ | 任意 | — | |||
| トラッキング | すべてのリンクにUTMを設定 | ✓ | ✓ | 任意 | |||
| トラッキング | アナリティクスイベントが発火することを確認 | ✓ | 任意 | — | |||
| トラッキング | ベースライン指標を取得 | ✓ | ✓ | — | |||
| ローンチ後 | レトロスペクティブを予定（1週間後） | ✓ | ✓ | — |
ローンチタイムライン
Tier 1 タイムライン（2〜4週間）
3〜4週間前： メッセージングブリーフを確定。ランディングページとビデオ制作を開始。プレス向けアウトリーチを開始（ジャーナリストはリードタイムが必要）。
1〜2週間前： すべてのアセットを最終決定。ソーシャルコピーを作成。メールを準備。社内チームにブリーフィング。トラッキング（UTM、アナリティクスイベント）を設定。配信シーケンスのドライランを実施。
ローンチ当日： 配信を順番に実行 — 最初にソーシャル（午前）、次にメール、その後プレスエンバーゴ解除。終日コメント/返信を監視し、エンゲージメント。
1週間後： レトロスペクティブを実施。
Tier 2 タイムライン（1〜2週間）
2週間前： メッセージングを確定。ブログ投稿とランディングページの更新を開始。
1週間前： コピーを最終決定。ソーシャル投稿を作成。メールセグメントを準備。
ローンチ当日： ソーシャルに投稿、ブログを公開、メールを送信。レスポンスにエンゲージメント。
3〜5日後： クイックレトロスペクティブ（非同期、例：Slackスレッド）。
Tier 3 タイムライン（同日または翌日）
リリースします。チェンジログエントリとソーシャル投稿を作成。完了。小さな改善のバッチの一部である場合は、週次ダイジェストにまとめます。
ローンチ後のレトロスペクティブ
これをスキップしないでください。レトロスペクティブは、個々のローンチを複合的なローンチエンジンに変えるものです。
カバーすべき項目
- 何がうまくいったか？ どのチャネルが最も多くのトラフィック、サインアップ、エンゲージメントを促進したか？どのメッセージングが共感を呼んだか？
- 何がうまくいかなかったか？ どのアセットがパフォーマンス不足だったか？タイムラインはどこでずれたか？
- 驚きは？ 予期しないチャネルが爆発的に伸びたか？特定のフレーミングが予想以上にうまくいったか？
- 数値 — トラフィック、サインアップ、アクティベーション、ソーシャルエンゲージメント、プレスでの言及。データがあれば、以前のローンチと比較します。
- チェックリストの更新 — 学んだことに基づいて、マスターチェックリストに項目を追加または削除します。
レトロスペクティブの形式
軽量に保ちます。Slackスレッドまたは15分の通話でTier2には十分です。Tier1には短いドキュメントが適しています。重要なアウトプットは、チェックリストとプロセスへの具体的な変更であり、回顧録ではありません。
「すべてがローンチである」という哲学
月に複数回リリースしているが、四半期に数回しかローンチしていない場合、成長を機会損失しています。すべてのリリースは、ストーリーを伝え、存在を思い出させ、勢いを示す機会です。
これは、すべてのバグ修正にプレスリリースが必要だという意味ではありません。すべての改善には、その重要性に応じてスケールされた何らかの発表が必要だという意味です。Tier 3のローンチは数分で完了します。一貫した可視性の複合効果は計り知れません。
習慣を身につけましょう：PRがマージされたら、ローンチチェックリストが開かれます。
コンパニオンスキルとの連携
このスキルは戦略と計画を担当します。実行については、以下を参照してください：
- launch-tweet — ソーシャルコピー（ツイート、スレッド、LinkedIn、クロスプラットフォーム）の作成
- launch-email — メールの件名、アナウンス構造、セグメンテーション、チェンジログダイジェスト
- launch-blog-post — アナウンス投稿の作成（構造、SEO、AEO）
- launch-video — デモビデオ、GIF、スクリーンショット、Remotionを使用したプログラム動画
- launch-landing-page — ランディングページの構築（構造、緊急性の仕組み、SEO、コンバージョン）
- launch-distribution — チャネルごとの配信とローンチ当日のシーケンス
- launch-metrics — UTM設定、階層別KPI、ベンチマーク期待値、レトロスペクティブデータフレームワーク