product-launch-manager

プロダクトローンチマネージャー

テクノロジー企業向けの戦略的なプロダクトローンチの専門知識。ローンチ計画やティア分けから、実行、モニタリング、振り返りまでを扱います。

基本理念

優れたローンチは、派手な一発勝負ではありません。リスクを最小限に抑えながらインパクトを最大化する、緻密なオーケストレーションが重要です。

優れたプロダクトローンチのポイント：

1. インパクトに基づいてティア分けする — すべての機能に基調講演が必要なわけではありません
2. 徹底的に連携する — 部門横断の足並みをそろえることは必須です
3. 発表前に検証する — ベータプログラムによって、あらゆるリスクを軽減できます
4. 失敗に備える — ロールバック計画は悲観論ではなく、プロフェッショナリズムです
5. 重要な指標を測定する — 成功基準はローンチ後ではなく、ローンチ前に定めます

このスキルの仕組み

呼び出された際は、rules/ にある次のカテゴリ別のガイドラインを適用します。

• planning-* — ローンチ戦略、ティア分け、スケジュール、成功基準
• coordination-* — 部門横断の連携、RACI、ステークホルダー管理
• beta-* — 早期アクセスプログラム、ベータ参加グループ、フィードバックループ
• communication-* — 社内向けイネーブルメント、社外向けメッセージ、ローンチコミュニケーション
• execution-* — ローンチ当日のオペレーション、ウォールーム、モニタリング
• postlaunch-* — 振り返り、指標分析、改善

コアフレームワーク

ローンチティアモデル

ティア	基準	スケジュール	チャネル	例
ティア 1	新製品、大規模なプラットフォームの転換	8-12 週間	プレス発表、イベント、基調講演をすべて実施	新製品ライン
ティア 2	主要機能、大幅な拡張	4-8 週間	ブログ、メール、ソーシャルメディア、PR	エンタープライズ機能
ティア 3	機能強化、インテグレーション	2-4 週間	ブログ、変更履歴、メール	新しいインテグレーション
ティア 4	バグ修正、小規模な改善	1-2 週間	変更履歴、アプリ内	UI の改善

ローンチ準備状況モデル

┌─────────────────────────────────────────────────────────┐
│                    LAUNCH READINESS                      │
├─────────────────────────────────────────────────────────┤
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
│  │ Product │  │Marketing│  │  Sales  │  │ Support │    │
│  │  Ready  │  │  Ready  │  │  Ready  │  │  Ready  │    │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘    │
│       │            │            │            │          │
│       └────────────┴─────┬──────┴────────────┘          │
│                          │                              │
│                    ┌─────▼─────┐                        │
│                    │  GO/NO-GO │                        │
│                    │  DECISION │                        │
│                    └───────────┘                        │
└─────────────────────────────────────────────────────────┘

ローンチ RACI マトリックス

活動	プロダクト	マーケティング	営業	サポート	エンジニアリング	経営陣
機能要件	A	C	C	C	R	I
ローンチティアの決定	R	C	C	I	C	A
ローンチ日	R	C	I	I	C	A
社外向けメッセージ	C	R	C	I	I	A
社内向けイネーブルメント	C	R	R	R	I	I
技術的な準備状況	C	I	I	I	R	A
サポート向けドキュメント	C	I	I	R	C	I
Go/No-Go の決定	R	R	R	R	R	A

R = 実行責任者、A = 説明責任者、C = 協議先、I = 報告先

ローンチスケジュールのテンプレート

Week -8: Launch brief, tier decision, stakeholder alignment
Week -6: Beta program begins, messaging draft
Week -4: Sales/support enablement starts, PR outreach
Week -2: Go/no-go checkpoint, final content review
Week -1: War room setup, monitoring configured, runbook complete
Day 0:   LAUNCH
Week +1: Post-launch monitoring, quick fixes
Week +2: Launch retrospective, metrics review

成功基準のフレームワーク

カテゴリ	指標の種類	例
採用	使用状況の指標	DAU、機能採用率、アクティベーション
品質	安定性の指標	エラー率、P0 インシデント、ロールバック率
ビジネス	収益の指標	コンバージョン、アップセル、パイプラインへの影響
センチメント	フィードバックの指標	NPS、サポートチケット、ソーシャル上の反応

コミュニケーションテンプレート

ローンチ概要の構成

1. Executive Summary
2. Launch Tier & Rationale
3. Target Audience
4. Key Messages (3 max)
5. Success Criteria
6. Timeline & Milestones
7. RACI & Stakeholders
8. Risks & Mitigations
9. Budget (if applicable)
10. Approval Sign-offs

Go/No-Go チェックリスト

□ Product: Feature complete and tested
□ Product: Performance benchmarks met
□ Engineering: Rollback plan documented
□ Engineering: Monitoring/alerts configured
□ Marketing: All content published/scheduled
□ Marketing: PR embargo lifted
□ Sales: Enablement complete, battlecards ready
□ Support: Documentation live, team trained
□ Legal: Compliance review complete
□ Exec: Final approval received

アンチパターン

• ティア分けせずにローンチする — すべてのリリースをティア 1 のように扱うと、チームもオーディエンスも疲弊します
• 一斉ローンチだけを行う — ベータを省くと、本番環境で学ぶことになります
• エンジニアリング完了 = ローンチ準備完了 — コードの完成 ≠ 市場投入の準備完了
• ロールバック計画がない — 期待するだけでは戦略になりません
• 事後に成功基準を定める — ローンチ後に成功を定義するのは、後付けの正当化です
• 部門ごとに分断されたローンチ — マーケティングが知るのは、顧客と同じタイミングです
• ローンチして終わりにする — ローンチ後のモニタリングも改善もありません
• 見栄えだけのローンチ指標 — プレスでの言及 ≠ プロダクトの成功