プロダクトマネージャーの役割は、近年テック業界で人気を博しています。より多くの企業が組織図にPMを追加するにつれて、プロダクトとエンジニアリング間の最適な調整を見つけるためのチームセットアップの実験がまだ多く行われています。これら2つの機能はこれまでにないほど密接に連携しており、高い成果を上げるチームのレシピと言われていますが、多くの企業はまだ良好な協力レベルを達成するのに苦労しています。
うまくいくための戦略はMartin Fowlerのウェブサイトでよく取り上げられていますが、この記事ではエンジニアの視点と、良いプロダクトマネージャーに対する私たちの期待により焦点を当てます。
期待してはいけないこと#
エンジニアとして、私は両側から摩擦が生じるのを観察してきましたが、生産的なパートナーシップも見てきました。チームや組織が結果に影響を与えると主張することもできますが、それは主に各機能がどれだけ他方と協力する意思があるかによります。
これらの期待を逆に考える練習をしましょう。PMの役割はまだ初期段階にあり、そのため、特に製品開発戦略を構築し始めている成熟度の低い企業では、さまざまな形を取ると思います。現在テック業界で働いている場合、以下のステレオタイプのいくつかに馴染みがあるかもしれません。
Excelマネージャー#
マクロのエースで、毎週のステアリングでの進捗報告のマスター。プロジェクト全体は、「Delivered」という単語を入力すると緑に変わる赤いセルの列と水平に整列した、互いに積み重ねられた棒を持つ幾何学的な芸術作品のように見えます。Excelマネージャーは製品ライフサイクルにほとんど関心がなく、開発者にそれらの締め切りにコミットさせることにすべてのチップを費やします。
フィーチャリスト#
360度の市場調査のトップスペシャリスト。彼女はスティーブ・ジョブズとiPodの話をすべて知っており、製品ライフサイクルに関心がありますが、「ディテールが重要で、正しくなるまで待つ価値がある」ため、戦略を構築する時間を無駄にする余裕がありません。レスポンシブデザインとソーシャルシェアボタンを構築する限り、お金が流れ始めるでしょう。「Avoiding Featurism」をチェックしてください。_featurist_という言葉はそこから借りました。
引退したプログラマー#
永遠にコードモンキーでいるというアイデアに不満を持ち、彼女は幸せと成功を求めてエンジニアリングを去りました。残してきた人生を後悔しながら、引退したプログラマーは良い味方であり、ソフトウェアアーキテクチャのアイデアと大学でプログラミングプロジェクトでA+を取ったという話を共有することと引き換えに、リーダーシップの期待を管理し、締め切りを延期する意思があります。
王の手#
自分のアイデアを共有するのはなぜですか？私たちは皆、より大きな目的を果たすためにここにいるのですから。オールパスフィルターのように、王の手は自分の方向に指が向かないようにリスクを取りません。彼女は単なるメッセンジャーであり、同意しない場合は、マスターから指導を求められるようにエスカレーションを期待してください。
プロダクトマネジメントの単一のアイデア#
さて[真面目なトーンで]、上記のステレオタイプに共通していること（意図的に）は、それらすべてがビジネスの決定をリーダーシップ層に委任していることです。これは、プロダクトマネージャーの役割に関する最大のゲームチェンジャーだと思います。デザインや実装以上に、PMはアイデアから実装、顧客フィードバック、市場パフォーマンスに至るまでの製品ライフサイクル全体に責任を持ちます。良いPMは下位レベルのCEOとして機能し、ビジネスの小さな部分（製品）の成功に責任を持ち、この責任をリーダーシップからオフロードします。さらに良いPMは、この責任を製品エンジニアリングチーム全体で共有します。
そうは言っても、パートナーシップがどのように実装されるかは別の話です。私が参加した最も成功したチームは、PMがそこにいて、時には同じリーダーシップ/報告ラインの下にいるチームです。2つの機能間の摩擦が少ないほど、結果は良くなります。PM & EM: Rules of engagementは、PMとEMを超えてプロダクトとエンジニアリングに拡張できると思う3つの基本ルールを確立しています：信頼、共同責任、別々の所有権。各機能が異なる役割を果たすことは重要ですが、共有責任を持つチームとして働くことで、何をしているのか、なぜしているのかに対する全員の調整が高まり、何かを完了するために必要な官僚主義が減り、PMが製品戦略を反復的に構築し適応させるためのより良い柔軟性を得ることができます。
チームをビジネスにオンボードする#
私を常に悩ませてきたことの1つは、エンジニアが構築している製品についてどれだけ知らないかということです。驚くかもしれませんが、構築しているソフトウェアを誰が使用し、どれだけのお金を稼いでいるかを知らずに一生働くことは可能です。より低いレベルでビジネスを行う利点の1つは、この障壁を打ち破ることができることです。製品のパフォーマンスや北極星やその他の関連KPIについてのチームとの定期的な議論は、イノベーションを促進し、モチベーションレベルを高く保つ強力な方法です。
すべてを支配する1つのロードマップ#
プロダクトチームで働きながら技術ロードマップを構築することは、私が経験した最も非生産的な経験の1つでした。支払う必要がある技術的負債を追跡することは重要ですが、プロダクトからの賛同がない場合、経験上、それらのタスクは決して実装されません。
進行中のプロジェクトにいくつかのタスクを詰め込むことは持続可能ではなく、ある時点ではコードベースも持続可能ではなくなり、開発者のバーンアウトと製品パフォーマンスの低下につながります。良いPMは技術的負債を支払わないコストを理解し、製品戦略の一部として含めることができます。
締め切りではなく、目標日#
エンジニアにストレスを与えたい場合は、ETAまたはリーダーシップによって設定された締め切りへのコミットを求めてください。プレッシャーの下でソフトウェアを構築することは、人々がより多くのミスを犯すことを余儀なくされ、後でお金がかかったりチームの速度が低下したりする可能性があるという意味で、ビジネスに害を与えるだけです。
エンジニアが大量の時間を無駄にする自由があることも受け入れられませんが、PMは目標日を移動させるか、スコープを削除するかのいずれかを許可するのに十分な柔軟性を持つべきです。
最後に#
完璧なPMがどうあるべきかはまだ未解決の問題ですが、プロダクトとエンジニアリングの両方が効果的なパートナーシップの構築に向けて取り組めば、サイロで働く（結果ではなく活動によってグループ化される）のとは対照的に、はるかに生産的な結果が得られることは明らかです。チーム内から製品を構築することは、スタートアップ企業と同様に、高いレベルの調整、モチベーション、生産性がより可能性が高い、より良い協力環境を構築するための鍵です。エンジニアの観点から見ると、理想的なPMはステークホルダーではなく、より広い会社内の小さなスタートアップのCEOのようなピアです。
