プロダクトローンチ
ローンチは発表ではありません。発表は最もコストがかからず、全体と誤認されやすい部分です。これが、機能がメディアに取り上げられても採用されない理由です。
計画前にローンチの段階を決める
すべての成果物が同じ扱いに値するわけではなく、すべてを大規模扱いにするとチームの注意力と顧客の関心を浪費します。
- Tier 1 — プロダクトのストーリーを変える、または新たなセグメントを開拓する。フルモーション：ポジショニング、プレス、セールスイネーブルメント、顧客コミュニケーション、キャンペーン。
- Tier 2 — 既存顧客にとって有意義だが、新しいストーリーではない。製品内発表、ドキュメント、影響を受けるアカウントへの通知、セールスブリーフィング。
- Tier 3 — 改善。リリースノートのみ。
作業開始前に段階を合意し、開発チームはTier 1に引き寄せられがちであることを認識しておくこと。段階を超えた労力は、他の場所、通常は次のローンチから奪われます。
外部発表より先に内部準備を整える
順序が重要であり、頻繁に逆転しています。サポートとセールスが発表で初めて知り、その後ローンチ週にまったくブリーフィングされていない質問に悪い対応をする羽目になります。
外部に出す前に：ドキュメントが存在し、サポートがトップの質問に答えられ、セールスが誰向けか・誰向けでないかを理解し、価格とパッケージが決定・設定され、最初に試すアカウントで機能が正常に動作すること。
チーム外部の誰かに、ゼロから使ってもらうこと。 チームはもはや初回体験を客観視できません。そして、初回体験こそが他の全員が得るものです。
誰向けかを決め、誰向けではないかを明言する
すべての人を対象にしたローンチは誰にも届きません。セグメント、解決する問題、そしてその結果何が変わるのかを明示し、まだ使うべきでない人を明示的に伝えること。そうしなければ、セールスは問い合わせがある人全員に売り込み、最も適合しない顧客が初期の顧客になります。
日程には理由を付け、基準を日程よりも優先する
ローンチ日はイベント、四半期、約束事によって決まることが多いです。どのように決まるにせよ、その日程でローンチするために満たすべき基準（品質基準、ドキュメント、サポート準備）を書き出し、それらを実際のゲートとして扱うこと。
サポート準備が整う前にローンチすることは、1週間を節約する最も高価な方法です。 そのコストは、最もその機能に興味を持つ顧客に悪い第一印象として現れます。
当日だけでなく、その後の日々も計画する
多くのローンチ計画はローンチ日で終わりますが、実際にはそこで作業が始まります。フォロースルーをスケジュールする：初回を逃した人向けの第二波、まだ試していないユーザーへの製品内プロンプト、適合するアカウントへのアウトリーチ、サポートに届く質問の確認。
最初のサポートチケットを注意深く監視すること。それらはローンチの何が間違っていたかの最速のシグナルであり、ダッシュボードの数字が動く前に届きます。
発表ではなく採用を測定する
リーチ、インプレッション、プレス掲載は発表を測定します。重要なのは、意図した人々がその機能を使用しているかどうか、そしてそれがロードマップで主張したことを達成しているかどうかです。
ローンチ前に数字を決めておくこと — どのアカウントが、何を、いつまでに、どの程度行うのか。後から選んだエンゲージメント指標で評価されたローンチは常に成功となり、何も学べません。
絶対にやってはいけないこと
- サポートとセールスが明確な質問に答えられるようになる前に、外部に発表すること。
- チームが誇りに思っているからといって、Tier 3の変更にTier 1の動きをすること。
- 対象を絞ることが影響を減らすように感じられるからといって、全員にローンチすること。
- 目標が採用であるのに、ローンチの成功をリーチで報告すること。