launch-plan

賭けの大きさに応じてローンチし、野心の大きさに応じてローンチするのではありません。ほとんどの機能は、告知なし、または小規模なローンチで十分です。大規模なローンチは、本当に新しい製品や大きな方向転換のために取っておきましょう。Linear の原則は、早く、頻繁に、複数回ローンチすることです。

ローンチの段階

ティア 1：告知なしのローンチ

リリースして有効にし、どうなるかを見ます。告知はしません。

用途： バグ修正、小規模な改善、社内ツール、インフラの変更、実験。

チェックリスト：

• 機能がフラグで制御されているか、段階的に展開される
• モニタリング／アラートが設定されている
• ロールバック計画がある
• 指標を24時間監視する担当者が1人いる

ティア 2：小規模なローンチ

リリースして既存のユーザーに知らせ、広く展開する前にフィードバックを集めます。

用途： 既存ユーザー向けの新機能、大幅な UX 変更、料金変更、ベータプログラム。

チェックリスト：

• 変更履歴への記載、またはアプリ内通知を作成している
• ヘルプドキュメントを更新している（または新規作成している）
• サポートチームに FAQ を共有している
• フィードバック収集手段（アンケート、フィードバックボタン、Slack チャンネル）を用意している
• 既知の制限事項を文書化している
• ロールバック計画がある
• 広く展開する前に、1～2週間のフィードバック期間を設けている

例：リアルタイムコラボレーションのローンチ — 変更履歴：「一緒に編集し、カーソルをリアルタイムで確認できます。」サポート FAQ では、遅延の目安と同時に編集できるユーザー数の上限を説明します。機能フラグを使って3日間、チームの20％に展開し、その後100％にします。ロールバックする場合は、WebSocket 同期を無効にしてポーリングに切り替えます。フィードバックウィジェットは2週間利用可能にします。成功指標：2人以上のユーザーが同時に編集したチームの割合。

ティア 3：大規模ローンチ

最大限のリーチを目指して調整された、公開ローンチです。時間と注目を多く必要とします。

用途： 新製品のローンチ、大きな方向転換、リブランド、新市場への参入。年間最大2～3回です。

チェックリスト：

製品

• 機能が完成しており、大規模な負荷でテスト済み
• 5人以上の新規ユーザーを対象にオンボーディングフローをテスト済み
• 想定される負荷でパフォーマンスをベンチマーク済み

コンテンツ

• ランディングページまたは製品ページを公開済み
• ブログ記事／告知文を作成済み
• デモ動画またはスクリーンショットを準備済み
• ローンチ当日と翌日、3日後、7日後のソーシャルメディア投稿を下書き済み

配信

• 既存ユーザーへのメールを予約済み
• ソーシャルメディアへの投稿を予約済み
• コミュニティへの投稿を下書き済み（関連する subreddit、Slack グループ、Discord）
• Product Hunt でのローンチを準備済み（該当する場合）
• インフルエンサー／パートナーへの連絡を1週間前に実施済み

サポート

• ローンチ当日のサポート体制を整え、チームに共有済み
• FAQ と既知の問題を文書化済み
• エスカレーション経路を定義済み

測定

• ローンチ前に成功指標を定義済み（ローンチ後ではありません）
• アナリティクスの計測を確認済み
• 最初の1週間、毎日のレビューを予定済み

ローンチ後

ティアにかかわらず：

1. 1日目： 指標を監視します。問題があれば修正します。すべてのフィードバックに対応します。
2. 3日目： 最初の振り返りを行います。うまくいっていること、うまくいっていないこと、予想外だったことを確認します。
3. 1週目： 改善を続けるか、展開を拡大するか、縮小するかを決めます。
4. 2～4週目： 得られた学びをまとめます。実際のデータに基づいてロードマップを更新します。

ガイドライン

• 重要：基本はティア 1 または 2 とします。強い理由がある場合のみ、ティア 3 に引き上げます。ローンチが多すぎると、告知疲れを招きます。
• ロールバック計画なしでローンチしてはいけません。元に戻せないのであれば、準備ができていません。
• 必ずローンチ前に成功指標を定義してください。ローンチ後ではありません。事後に指標を作るのは、後付けのストーリーにすぎません。
• 金曜日にローンチしてはいけません。監視と改善に一週間を使えるよう、月曜日から水曜日にローンチしてください。
• 最初の24時間は、必ず担当者を1人決めてください。担当者がいないローンチは、方向性を失います。
• 既知のバグがある機能を大規模にローンチしてはいけません。まず小規模にローンチし、修正してから広く展開してください。

---

Linear の「複数回ローンチする」という理念に基づいています。productskills のスキルを使用しています。