事実：製品リリースのコミュニケーションは問題があります

製品リリースノートの目的は、社内のエンジニアリングからカスタマーサポートまでのチームと、外部の利害関係者（顧客やパートナー）に製品に変更があったことを知らせることです。 すべてが光の速度で変化するテクノロジーの世界では、リリースノートを介して製品アップデートを提供することは、実際には時代遅れの問題です。

私が働いていた全ての会社は、リリースノートを「適切に」得るのに苦労してきました。 しかし、それを正しく行うのは難しいことです；変更や製品のローンチの重要性は、オーディエンスや、その変更が特定のグループの機能との相互作用をどう変えるか、さらにそのグループが製品全体をどのように日々使用しているかに基づいて、異なるでしょう。

これらの製品リリースのコミュニケーション（一般的にはリリースノートとして知られる）は、異なることに関心のあるオーディエンスに届けなければなりません。 Guruの収益強化リーダーとして、私の構成メンバーは、製品のロードマップが彼らの仕事に影響を与える全ての人々です。

• 製品/デザイン/エンジニアリングチーム
• 営業チーム（営業業務、インサイドセールス、セグメント全体のアカウントエグゼクティブ）
• 顧客体験（成功マネージャーとサポート担当者）
• マーケティングチーム（製品マーケティング、成長マーケティング、ブランド、コンテンツが、製品のGTM戦略とプレスアウトリーチを担当します）
• ビジネス開発とパートナー

これら全てのパートナーは製品の更新を理解し、どの程度それを自分たちの仕事に適用すべきかをすぐに把握しなければなりません。 彼らはまた、エンドユーザーがどのようにその変化が自身に影響を与えるかを理解できるように、どのように手助けできるかを考えなければなりません。

リリースコミュニケーションを作成する人（またはチーム）は、製品の知識を消費する全てのオーディエンスを考慮する必要があります。 リリースの影響は、バックエンドエンジニアと小売業界の潜在的な顧客にとって何ですか？

リリースノートへのアプローチ方法

異なるオーディエンスのニーズを考慮するのは難しいことですが、製品マネージャーや製品マーケティングマネージャー（PMM）が5つの異なるバージョンの内部リリースノートを書くのは単純にスケーラブルではありません。 私の経験上、リリースノートは長すぎたり、文脈から外れたりする場合が多いか、技術的な知識が不足しています。 静的なリリースノートはこの洞察を提供せず、著者のために書かれていることが多く、何が変更されたかを理解する必要がある人のためではありません。 率直に言って、通常は見逃される機会です。  

私は、製品管理からの単調な声がスライド上の箇条書きを読み上げる週に1回の1時間のリリースノートの電話議題に座っていました。 電話が終了した後、同じ製品マネージャーがカスタマーサポートから営業チームまで、誰にとってその変更が意味するかを知りたいというメールや電話（それを覚えていますか？）、Slackなどを受け取ります。 電話を逃したら、ニュアンスや文脈を逃し、代わりに生の変更ログだけが受け取られました。

しかし、製品マネージャーにはこの神聖な翻訳を行う役割はありません。市場の問題を解決する製品を構築するのがその仕事です。 市場がその価値を理解できるようにするのはPMMの仕事です。

優れたソフトウェアリリースノートを書くための秘訣

私は大のサウンド・オブ・ミュージックファン（びっくりするでしょうが）で、エナブルメント専門家として映画の中の時代を超えた教訓が真実を響かせるのです。 「始まりから始めましょう・それはとても良い出発地点です」という言葉が、毎週私の頭をよぎります。 ですので、製品配信プロセスを形作るためには、まずその言語を学ぶ必要があります。

1. 内部用語集を作成する

このプロセスを掘り下げる最初のステップは、チーム全体が同じ言語を話すことを確実にすることです。 共有用語を社会化することは明白に思えますが、組織全体で行われていない可能性があります。 略語を知らないことや言語を誤解することは孤立を生み、チーム内で混乱やサイロを生み出す可能性があります。

例：私たちのマーケティングチームは、製品の機能を市場に投入する方法を説明するために「ローンチ」という用語を使用します。 しかし、エンジニアリングチームは、「ローンチ」という言葉を、機能がステージング環境にリリースされた時を指すために使用します。 機能固有のローンチは、顧客がそれについて知る前にエンジニアリングにとっては「完了」です。 これは混乱を引き起こし、内部で対立を生じさせます。

誰も自分が何かの意味を知らないということを公に認めるために恐れず、定義を求める人になりたくありません。 私たちの解決策：エンジニアリング、製品、製品マーケティングの代表を含むクロスファンクショナル作業グループで、私たちはニュアンスを具体化し、製品リリースの定義を文書化しました：

注意：もしカードの読み込みに失敗した場合は、ページをリフレッシュしてください！

2. リリースノートに含めるべき事項

共通の言語が確立され、チームがリリース用語を明確にできるようになった後、ノートを書けるようになります。 最も簡単なことは、リリースノートを書くための再利用可能なテンプレートを作成することです。 このようにして、関係者は数回の試行後に形式に慣れ、毎回新たに考える手間を省くことができます。

最低限、良いリリースノートには次の内容が含まれます：

• リリース日
• 内部および外部
• 機能やバグの説明
• 影響を受ける製品（複数ある場合）
• 複数のソフトウェア製品がある場合、バージョン番号も含めた方が良いかもしれません。
• 内部で質問できる場所

しかし、優れたリリースノートには以下が含まれます：

• 予想されるよくある質問（FAQ）
• 新しい公開ドキュメントへのリンク（利用可能な場合）
• 機能について：
• 機能の名前
• その機能のスクリーンショット
• 機能のデモ方法のビデオ
• その機能が存在する理由
• 関連するバイヤー/カスタマーペルソナへの影響

こちらはテンプレートです、私たちが内部で使用しているものです（自由にコピーしてください！）：

💡注意：このタスクには、直接責任を持つ個人を割り当てることが役立ちます（誰も所有していないグループの努力に任せない方が良いです）。 エンジニアリングまたはプロダクトマネージャーはノートの技術的な側面（名称/バージョン/製品/日付/スクリーンショット）を担当し、製品マーケティングマネージャーまたは営業エンジニアは文脈情報（バイヤーペルソナ/なぜそれが重要か）を担当する必要があります。

製品配信プロセス戦略の実施

一貫したコミュニケーション形式を作成する

用語を統一し、テンプレートを書いたら、次のステップは、一貫した配信メディア（つまり：Slack、メール、Loom、Guru、Google Docs）とメソッドに同意することです。 一貫した配信メディアは、リリースノートの関係者がどこに行けば良いのか、どこを見るべきなのか、何に登録すればいいのか（引き出すため）を知っていることを保証します。

これはまた、変更管理にとっても必須です。なぜなら、通常は、誰かに何かを伝えるためには、複数回知らせる必要があるためです。 リリースの種類、UI/UX（ユーザーインターフェースとユーザーエクスペリエンス）への変更、および顧客への影響に応じて、リリースノートのオーディエンスは製品知識を促す必要があります（プッシュするために）。 Guruでは、プッシュとプル両方の方法を採用しています。

プル：知識の見つけ方

私たちにとって、関係者はSlackの#release-notesチャンネルでフォローし、バグ修正から新機能まで全てに対する一貫した消化しやすい形式を持ちます。 あなたのそれぞれのオーディエンスが、リリースが行われること（Slackやメールでのプルを介して）を認識する必要があるだけでなく、それより重要なのはそれが文脈でなぜ重要なのかを知っておく必要があることです。

リリースが単に行われるか、行われたという知識は、あなたのチームが実際にそれを活用できない限り価値がありません。 一貫したフォーマットを開発するために、私は営業担当者、アカウント開発担当者、ビジネス開発担当者（そのすべて）に調査を行い、私たちが呼ぶ製品配信のテンプレートを確立しました。「機能の内訳カード」をここで見つけることができます。

エンジニアリングマネージャーが新機能の開発を開始すると、直接責任者がAsanaを介してアラートされ、リリースノートテンプレートを使って機能固有の機能内訳カードを作成します。 新しい機能内訳カードは、リリースしている「機能の脳」として、頑丈で真実の情報源となります。 専門家（SME）- たとえば PMM と営業エンジニアは、リリースがどのように貴重で、誰に重要で、該当する場合は、機能をデモする方法のガイダンスを含めます。

リリースノートのステークホルダー、特にアカウントエグゼクティブは、機能内訳カードの動的な知識が信頼できる、関連性があり、適用可能であることを学んだので、同じカードに何度も戻ります。 オーディエンスは今や同じ言語を話し、同じ（動的な）プレイブックを読み取っています。 機能内訳カードへの戻りは、依然として「プル」メソッドの一部です。なぜなら、それは自己ペースで、営業やサポートの電話を準備するためや、見込み客がロードマップについて質問がある場合に行われるからです。

プッシュ：知識を積極的に提供する

プッシュメソッドは、リリースに関する知識が時間に敏感な場合や、特定のチームにとって重要な場合に実行されます。 ここでは、Guruのアナウンスメント機能を通じて実現されます。 内部オーディエンスに対する影響に基づいて、私はアナウンスメントを関連グループに押します。 アラートを認識したり読んだりした人の報告を確認し、まだ認識していない人々を公然と恥ずかしめます（またはリマインドします）。  

なぜ知識主導の文化が鍵なのか 🗝

上記に関わらず、用語の合意、優れたリリースノートの作成、動的な製品配信のためのメカニズムの作成は、実際にはそれほど簡単ではありません。 チームは知識に関して協力し、時間をかけてフィードバックを行うことができる必要があります。 フィードバックを提供し、知識を共有することによって向上させることは、チーム全体の役割と責任です。

私たちにとって、それは、知識消費者（この場合はリリースノートの関係者）が質問を持っている場合や新しいことを学んだ場合に、機能内訳カードにコメントすることを意味します。 私たちは、知識を継続的に向上させる手段として、Slackでの質問と回答をコメントに組み込んでいます。 主題専門家（通常はPMM）は、その新しい知識や関連する質問をレビューし、それを特定の機能内訳カードに文脈を付けて組み込むことができます。

私たちはまた、全てのリリースノートを簡単にアクセスできるようにし、私たちの機能内訳ボードの今後のセクションまたはローンチしたセクションに置き、内部でさらに整理することができます。 その結果、一目で分かりやすいものになります。 あなたがGuruを使っていない場合は、リリースノートのページまたはリンクされた変更ログを作成することをお勧めします。

他のプロセスと同様、これも常に進化しています。 製品配信とリリースノートは、単なる一回で完了するものではありません。 ビジネスのニーズが変化するにつれて、プロセス、責任、およびテンプレートもそれに応じて変更される必要があります。 しかし、理解しやすさ、文脈、使いやすさを追求することで、失敗することはありません。