プロダクトマネジメントのコツとテクニック
概要
ハンドブックのこのセクションは、プロダクトマネジメントの実践で活用できるプロダクトマネジメントプロセスのコレクションです。中には、プロダクトマネージャーの日常業務で必須ではないベストプラクティスや提案もあれば、成功する結果につながる試行錯誤された経路として強く推奨されるワークフローもあります。これらは当社のプロダクトマネジメント部門から提供され、ディレクター以上のプロダクトマネジメントリーダーによって定期的にレビューされています。
コツとテクニック
社内および社外への伝道
新機能や更新された機能を出荷する前に、社内および社外で機能を擁護することはあなたの責任です。何かがリリースされたとき、次のチームはそれを知る必要があります。彼らは皆、それに対して何かをする必要があるためです:
- Marketing: 機能の重要性に応じて、さまざまなコミュニケーションチャンネルでこの機能を宣伝するために Marketing の助けが必要です。
- Sales: セールスは、セールスプロセスで新規または既存の顧客を説得するためのより良い議論を持てるよう、製品で何が新しい／変更されたかを知る必要があります。
- Support: ユーザーや顧客と継続的に接触しているため、サポートは当社の製品がどう動作するかを正確に知る必要があります。
作業を宣伝する方法はいくつかあります:
- リリースされるものをドキュメント化し、このドキュメントを上記のチームと共有することから始める
- 重要だと思う場合は、上記のチームとミーティングをスケジュールする
書面でのコミュニケーションで Issue を参照するとき、Issue 番号 #123456 とリンクだけを使うのは 低コンテキストコミュニケーション ではありません。代わりに、Issue のタイトルとリンク、または Issue 番号とその Issue が解決する問題の説明を使ってください:
- 良い:
次に [MR で コードカバレッジレポートを検出して表示する](https://gitlab.com/gitlab-org/gitlab/-/issues/21549) に取り組みます。または次に [gitlab#21549](https://gitlab.com/gitlab-org/gitlab/-/issues/21549) に取り組みます。これは、MR をレビューする際に別のツールを見てコンテキストを失う代わりに、開発者が GitLab で直接コードカバレッジレポートを表示できるようにするのに役立ちます。 - 避けるべき:
次に #21549 に取り組みます。
findability をサポートし、特に製品の方向性、カテゴリの変更、投資テーマの変化、エンジニアリングの優先順位に関して、考えを変えたときに明確に表現する ために、プロダクトマネージャーは、ユーザーや顧客が認識できるよう、これらの変更をマルチモーダルなコミュニケーションチャンネルで伝道する必要があります。
コミュニケーションのための 社内 方法には次のものがあります:
#product、#s_、#g_、#f_などのさまざまな製品ベースの Slack チャンネルで更新を共有する- 方向性やカテゴリの変更を #customer-success にクロスポストし、ユースケース に影響する場合は認知のために
@cs-leadershipをタグ付けする - 方向性の更新について議論する短い動画を録画し、Customer Success と共有する。効率的なコミュニケーションを促進するために 必要に応じて 同期ミーティングを使用する。
- Field（Sales、Customer Success、Channel & Alliances）チームのためにより大規模な社内コミュニケーションプラン／アプローチが必要かどうかを判断するために Field Communications チームとコラボレーションする。
- 組織全体でセクションレベルで月次方向性ページ更新のハイライトを集約し、共有する
方向性ページにリンクするために考慮する 社外 チャンネル:
- Twitter、LinkedIn、その他のソーシャルアカウント
- アカウントチームを介したアウトリーチメールの共有
- Unfiltered でウォークスルーを録画し、ソーシャルアカウントで宣伝する
- 重要または破壊的な場合は、変更についてブログを書く
アクションを促す書き方
PM として、アクションへのバイアス（および 緊急性の感覚、提案する、退屈なソリューション、書き留める、待たない、両方向ドアの決定 などの他の価値観のアクション）を覚えておくことが重要です。これは PM が非同期の議論をアクション指向に推進することを可能にします。コメントを書いたり Issue を作成したりするたびに自問してください: これは私たちがアクションを取り、前進することを可能にしますか？
機能について書く
PM として、私たちは出荷する機能とアップグレードについて、ブログ投稿で、何かを宣伝するために社内で、顧客に送るメールで、常に書く必要があります。機能について書くときに考慮すべきガイドラインがいくつかあります。最も重要なのは、ユーザーのために解決している問題を明確に伝えることです。
機能について書くときは、明確な社内および社外メッセージングを生成するのに役立つ これらのメッセージングガイドライン をカバーするようにしてください。また、他者が認識しない可能性のある略語（例: Minimal Valuable Change を表す「MVC」）の使用を避けるべきです。さらなるガイダンスについては、ライティングスタイルガイドライン を訪問してください。
上記のメッセージングガイドラインを具体的な例で強調しましょう。リポジトリでのシークレットの防止です。これは 8.12 で出荷 しました。
- コンテキストから始めます。機能なしの現在の状況を説明します。痛点を説明し、Value Drivers（この場合は
Reduce Security and Compliance Risk）に結びつけます。
シークレット（キーや証明書など）をリポジトリにコミットするのは悪いアイデアです。それらはリポジトリにアクセスする誰のマシンにもクローンされます。たった 1 つでも安全でない場合、情報は侵害されます。残念ながら、これは簡単に起こります。
git commit -am 'quickfix' && git pushと書いて、突然ローカルに留まるべきだったファイルをコミットしてしまいます！
- この問題を修正するために何を出荷したかを説明します。
GitLab には、シークレットを含むコミットがリポジトリに入らないようにする新しい push ルールがあります。
- 機能の使用方法を簡単な用語で説明します。
リポジトリ設定の push rules の下のチェックボックスをチェックするだけで、GitLab は .pem や .key などの一般的な安全でないファイルがコミットされるのを防ぎます。
- ドキュメントとその他の関連リンク（以前の投稿など）を指し示します。
インスピレーションのために、いくつかのよく書かれたリリースブログ投稿の追加例を以下に示します:
- Issue Board Work In Progress Limits
- Parent-Child Pipelines
- Drag-and-drop Design badges
- Render charts in GitLab issues using a Grafana URL
機能をショーケースする動画の録画
書面媒体に加えて、動画はあなたが達成しようとしているさまざまな目標やオーディエンスの学習スタイルに対応する重要な媒体です。 録画する動画のタイプに応じて、考慮すべきガイドラインがいくつかあります。
当社のドキュメントガイドラインは、動画コンテンツのリンクを 積極的に推奨 しているため、ドキュメントスタイルガイドの言語セクション に従い、テクニカルライティングチームと協力して、製品ドキュメントの関連場所にスピードラン、ウォークスルー、デモへのリンクを含めることを検討してください。
GIF を使う
アニメーション GIF は、画像だけでは足りない機能をマーケティング目的で見せたり、機能をより詳細に説明したりするのに素晴らしい手段です。GIF の作成 のガイドをご覧ください！
スピードラン
スピードランは、単一のワークフローとそのワークフローを実行するための体験に焦点を当てた非公式な動画です。多くの計画は必要なく、通常短時間です（5 分未満）。この動画タイプは、情報を提供することを目的とし、必ずしもバイヤーに影響を与えることを目的としていません。
例:
デモ
デモは、バイヤーに影響を与えることを目的としたスクリプト化された録画です。一般的により高い制作価値を持ち、通常はスライドスタイルのプレゼンテーションおよび／またはライブの画面共有の両方が含まれます。期間はカバーするトピックによって異なります。
例:
ウォークスルー
製品ウォークスルーは、主に社内オーディエンス向けの非公式な動画で、製品批評の録画された視覚的形式です。ウォークスルーは通常、プロダクトマネージャーの 製品スコープ 内のカテゴリやワークフロー間のユーザーエクスペリエンスに焦点を当てます。製品階層 の境界を越える（マルチカテゴリ、マルチステージ、マルチセクション）ウォークスルーには特別な利点があり、シングルアプリケーション全体の不連続な体験を浮き彫りにするのに役立ちます。
ウォークスルーは、より広い範囲をカバーし、しばしば「ライブ」のトラブルシューティングを含み、計画なしで実行するのが最適なため、通常長めです。ウォークスルーを作成するときは Product walk-through Issue テンプレート を使用してください。
例:
bfd74782)