version: "1.0.0" name: growth-launch description: プロダクトのローンチ・集客・グロース戦略を設計・実行するスキル。「公開したのにユーザーが来ない」状態を脱し、AARRRファネルを計測しながら継続的に成長させたいときに使う。

ローンチ・集客・グロース

目的

プロダクトを適切なチャネルで繰り返しローンチし、AARRRファネルの各段階を計測・改善することで、ユーザー獲得から継続・収益化までの成長サイクルを回す。

使うタイミング

• MVPが完成し、最初の100ユーザーを獲得したいとき
• 機能追加・価格改定など「再ローンチ」のタイミング
• 集客施策の効果が計測できておらず、何を改善すべきか分からないとき
• AARRRファネルのどこで離脱しているかを特定したいとき

進め方

フェーズ1: ローンチ前準備(公開2〜4週前)

1. LP(ランディングページ)を整える

• ファーストビューに3秒で価値が伝わる見出し(誰の・何の課題を・どう解決するか)
• スクリーンショットまたはデモ動画を掲載
• CTAは1つに絞る(登録 or 試す)
• ウェイトリストフォームを設置し、メールアドレスを収集

1. ベータユーザー10人を確保する

• 知人・コミュニティから対象ユーザーに近い人を口頭でスカウト
• Slackグループ・Discord・Connpassなどオフライン接点を活用
• 濃いフィードバック(画面共有で使ってもらう)を10人分取得してから公開

1. 計測基盤を先に仕込む

• イベント計測: 登録完了・主要アクション・課金をGA4またはMixpanel/PostHogで計装
• ファネルビュー: LP→登録→Activation→有料転換の各ステップ離脱率を可視化
• エラー監視・アラートを設定(Sentryなど)

1. ローンチチェックリストを作成

• 告知文ドラフトをチャネルごとに準備
• 負荷確認と障害対応フロー(→ [[non-functional-requirements]])

フェーズ2: 初回ローンチ(公開日)

1. チャネルを1〜2本に絞って集中投稿

• 海外: Product Hunt(朝12:01 PT)、Hacker News(Show HN)
• 日本: Zenn/Qiita(課題解決系の記事として)、note、はてなブックマーク
• SNS: X(Twitter)でbuild in publicとして開発過程も含めて投稿

1. ローンチ後24時間は張り付く

• コメント・質問に30分以内で返信
• バグ報告を即時対応できる体制を確保
• 初日の数値(訪問者・登録・アクティベーション率)を記録

フェーズ3: 継続的グロース

1. AARRRファネルを週次でレビューする

1. コンテンツSEOを積み上げる

• ターゲットユーザーが検索する「課題系キーワード」で月2〜4本の記事
• 記事→LP→登録の導線を明確に

1. フィードバック導線を維持する

• アプリ内にフィードバックボタンを常設
• 週1回はユーザーと15分の会話を設定

1. 機能追加ごとに再ローンチする

• ローンチは一発勝負でなく、改善サイクルの節目ごとに繰り返す
• 「v2.0」「〇〇機能追加」を理由にProduct HuntやSNSで再告知

成果物テンプレート

# ローンチ計画: [プロダクト名]
 
## ローンチ日
YYYY-MM-DD
 
## チャネル別タスクと担当
 
| チャネル | タスク | 担当 | 期限 |
|---|---|---|---|
| Product Hunt | プロダクト登録・画像準備 | - | D-7 |
| X(Twitter) | 告知ツイート3本作成 | - | D-3 |
| Zenn | 課題解決系記事ドラフト | - | D-7 |
| メール | ウェイトリスト向け告知文 | - | D-1 |
 
## 告知文ドラフト
 
### X(メイン告知)
[プロダクト名]をリリースしました。
[誰の][どんな課題]を[どう解決するか]1文で。
→ [URL]
#[関連ハッシュタグ]
 
### Zenn/Qiita 記事タイトル案
「[課題キーワード]を解決するツールを作った」
 
### Product Hunt タグライン(60字以内)
[英語でone-liner]
 
## 計測する指標(初週・初月の目標)
 
| 指標 | 初週目標 | 初月目標 |
|---|---|---|
| ユニーク訪問者数 | - | - |
| 登録者数 | - | - |
| Activation率(登録→主要アクション) | - | - |
| 7日リテンション率 | - | - |
| 有料転換数 | - | - |
 
## ローンチ後アクションリスト
-[ ] 24h以内: コメント全返信
-[ ] 48h以内: バグ報告対応
-[ ] 1週後: ファネルレビューとボトルネック特定
-[ ] 1ヶ月後: チャネル別CPAを比較し、注力チャネルを決定

チェックリスト

ローンチ前

• [ ] LP: 3秒で価値が伝わる見出しがある
• [ ] LP: スクリーンショットまたは動画がある
• [ ] LP: CTAが1つに絞られている
• [ ] ウェイトリストまたは登録フォームが動作する
• [ ] ベータユーザー10人からフィードバック済み
• [ ] 登録・主要アクション・課金のイベント計測が実装済み
• [ ] チャネルごとの告知文が準備済み
• [ ] 負荷確認・障害対応フローが確認済み

ローンチ後(1週間以内)

• [ ] 全コメント・質問に返信済み
• [ ] バグ報告ゼロまたは対応済み
• [ ] ファネル各段階の数値を記録した
• [ ] ボトルネックのステージを特定した

継続フェーズ

• [ ] 週次でAARRRファネルをレビューしている
• [ ] 月2本以上のコンテンツを公開している
• [ ] 週1回以上ユーザーと会話している
• [ ] 次回再ローンチの日程を決めている

アンチパターン

• 公開しただけで宣伝しない: 「作れば人が来る」は幻想。開発と同じだけ集客に時間を使う覚悟が必要
• ローンチ日にバグ修正で潰れる: ローンチ前に負荷テストと障害対応フローを整備する(→ [[non-functional-requirements]])
• 計測なしで施策を打つ: どのチャネルが効いているか、どこで離脱しているか分からないまま施策を重ねても改善できない
• 全チャネルに薄く手を出す: まず1〜2チャネルに集中してトラクションを確認してから横展開する
• ローンチを一発勝負にする: 初回が振るわなくても再ローンチで巻き返せる。機能追加のたびに告知する
• フィードバック導線を後回しにする: ユーザーの声なしに仮説を検証できない。アプリ内フィードバックは初日から設置

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

関連スキル

• [[orchestration]] — マルチエージェント協調の共通原則
• [[mvp-development]] — ローンチ対象のMVPを作る
• [[market-research]] — ターゲットユーザー・競合の調査
• [[monetization]] — 収益化モデルの設計
• [[non-functional-requirements]] — 負荷・セキュリティ・可用性の確認
• [[idea-generation]] — プロダクトアイデアの発散・検証
• [[monitoring-operations]] — 本番環境の計測・アラート設定
• [[documentation]] — LP・告知文・コンテンツの整備