プロダクトリーダーシップ
Principles - Processes - Categories - GitLab the Product - Being a PM - Leadership
一般的なプロダクト組織構造
GitLab のプロダクトチームには、当社の プロダクト階層 のさまざまな範囲で、組織レベル を横断したさまざまなレベルの プロダクトマネジメント職務役職 を持つチームメンバーが含まれます。その結果、層を横断したピア同士が同じ役職を持たない場合があります。私たちは常に GitLab の階層構造 に従います。
| レベル | ジョブファミリー | 階層スコープ |
|---|---|---|
| IC | Product Manager | Group、Stage |
| Manager | Group Manager Product、Director of Product | Section |
| Senior Leader | VP | All Sections |
| Executive | Chief Product Officer | 部門全体 |
プロダクトリーダー
プロダクト部門の Director 以上はすべてプロダクトリーダーとみなされます。彼らは @gl-product-leaders ハンドルを使用して参照できます。本ドキュメントは、プロダクトマネジメントチーム特有の重要なリーダーシップの概念を説明します。GitLab の一般的なリーダーシップガイダンス に関するページもあわせてご覧ください。
プロダクトリーダーシップチームの構造
Director+ であり、恒久的に Chief Product Officer に直属するプロダクトチームメンバーは、プロダクトリーダーシップチーム（PLT）のメンバーです。一時的に Chief Product Officer に直属するチームメンバーや Director+ でないメンバーは PLT オブザーバーです。PLT オブザーバーは PLT ミーティングや活動に一時的に参加する機会がありますが、恒久メンバーではない場合があります。PLT オブザーバーはすべての PLT 活動に含まれない場合があります。
このグループは、GitLab.com の Issue で @gl-product-plt ハンドルを使用して参照できます。
プロダクトリーダーシップ ReadMe
以下は、チームを管理する Product 部門のリーダーの ReadMe です。
プロダクトマネージャー/リーダーのコラボレーション
プロダクトチームリーダー として、組織のトーンを設定することは重要です。 私たちは PM 個々人を Directly Responsible Individuals (DRI) として前面に押し出し、 プロダクトリーダーとしての私たちのサポートを受けて正しい判断ができるという信頼と権限を委ねます。 このセクションは、PM とそのリーダー間の業務に関するベストプラクティスを概説することを目的としています。 PM とともに働く際にリーダーが持つべき責任と期待についてのガイダンスが含まれていますが、 強固な業務関係を築き、効果的に優先順位を付けることに代わる厳格なルールであることを意図しているわけではありません。
注 - これは、プロダクトディレクター または プロダクトのグループマネージャー のジョブディスクリプションの補足として、特に PM とそのマネージャー間のやり取りに焦点を当てたものです。 一般的な職務責任はそのリンク先で確認できます。
効果的なプロダクトリーダーは次のことを行う必要があります。
- グループに影響を与える複数の声が実行チームに混乱をもたらすことを尊重し、優先順位を変えながら突然現れることを避ける。 PM はそのグループとの 日常的なやり取り を所有しており、 リーダーは直接責任のある PM を通じて影響を与えるべきです。
- 個人的な達成に焦点を当てるのではなく、PM を通じて成功への道筋とする。 私たちは個々の PM をエンパワーする文化を持っており、権限を集中させるのではありません。 成長する中でそれを引き続き強化する必要があります。
- PM にとって 重要な内部および外部の顧客 は誰かを理解する手助けをし、 継続的に建設的な対話があり、フィードバックが入り、機能が社内で採用されるようにします。 内部顧客 は、カテゴリエピックの内部顧客セクションを最新に保ちながら、 少なくとも月次のチェックインが必要です。
- ポートフォリオを D および E グループとの日常的なやり取りで代表する。 特に、リーダーシップからのインプットを優先順位付けして、短期/中期で安定し、PM にとってアクションを取れるものにし、 チーム間の取り組みを整合させ、上級リーダーシップグループに対して PM の勝利を見える化する責任を負います。 これは、自身の部下の成功を上級リーダーシップグループに対して「チアリーダー」として広報することを含みます。 これには、会社の他のメンバーが使用できるポートフォリオレベルの方向性アイテムを公開することも含まれます （また、このポートフォリオレベルのビジョンを実現する DRI である PM がレビューして理解する必要があります）。
- 次回リリース、3か月ビジョン、OKR などへの更新について PM をサポートし、その責任を持たせる。 ウェブのカテゴリビジョンエピックを使用するチームでは、リリースに整合した非常に良い月次更新フローで実施でき、 包括的な MR の中での議論を通じて行うことができます。 ただし、どのようなプロセスであれ、リーダーはここでサポートとガイダンスを提供することで PM の責任を持たせるべきです。 特に組織の優先順位が明確であることを確認することに関してです。今後のポートフォリオレベルのマイルストーン、 リリースの期日、カレンダーに影響のある特別プロジェクトなどが見える化され、常に明確にコミュニケーションされていることを確認してください。
- PM を積極的にコーチし、彼らが成長してより良くなれる箇所を察知する。 このコーチングは、一貫して、明確に、アクションを取れる形で提供されるべきであり、 「サプライズな問題」を避けることを意図しています。同様に、PM からのコンテキスト、アドバイスなどのリクエストへのフォローアップは優先事項です。 ソクラテス的手法 は、PM と特にうまく機能する素晴らしいアプローチとして推奨されます。
- 採用を優先し、新しい人材と一緒に働く PM（および EM/チームメンバー）をプロセスに含めるようにする。
- 必要な組織変革のための構造と動機付けを提供する（より データ駆動 になる、 ストーリーを伝える、拡張的な思考のための時間を提供する）。
c955a93f)