プロダクトマネージャー

顧客からの要望、営業の提案、開発上の制約をすべて受け入れると、作業は増えても、製品がどこへ向かうのかが曖昧になります。
プロダクトマネージャーは、顧客の課題と事業の目的を結びつけ、チームがどの問題に取り組むかを判断する役割です。
職務の範囲や決定権は組織によって異なるため、肩書きと合わせて責任を明確にします。

顧客価値と事業の成り立ち

Marty Caganは、権限を持つプロダクトチームにおいて、プロダクトマネージャーが主に価値と事業性のリスクに責任を持つと説明しています。
利用者にとって役立つかに加え、販売、費用、運用などの条件を満たし、事業として提供し続けられるかを考えます。
デザイナーやエンジニアと協力し、使いやすさや技術上の実現可能性も含めて案を検討します。

たとえば、法人向けサービスで「すべての画面を顧客ごとに変更したい」と要望されたとします。
個別の契約に役立っても、変更箇所が増えるほど保守が複雑になり、他の顧客に届ける改善が遅れる可能性があります。
どの顧客に共通する課題なのか、設定で対応できるか、追加費用を含めて提供できるかを調べます。

優先順位の根拠をつくる

機能名だけで依頼を受けると、別の解決策を比較できません。
「CSV出力を追加する」という案なら、誰が、どの作業のために、どの情報を持ち出したいのかを確認します。
報告書の作成が目的なら、出力以外の方法で課題を解決できることもあります。

判断に必要な情報として、次の点をそろえます。

  • 対象顧客と、その顧客が困る具体的な状況。
  • 解決によって期待する行動や事業上の変化。
  • 現在の証拠と、まだ確かめていない前提。
  • 他の課題に比べた優先度と、後回しにする理由。
  • 結果を確かめ、判断を見直す時期。

これらをプロダクトロードマップやチームで使う記録に残すと、依頼者も開発者も判断の理由を参照できます。

プロダクトオーナーとの関係

プロダクトオーナーは、スクラムに定義された責任です。
プロダクトマネージャーという職種と同じ人が担う場合もありますが、名称だけで責任の分担は決まりません。
別々の人を置くなら、顧客との対話、プロダクトゴール、バックログの順序について、誰がどの判断を担うかを共有します。

また、チーム全員の上司であることを前提とする役割ではありません。
優先順位を決める権限と、製品を改善するために必要な情報へのアクセスをそろえることで、判断に責任を持てる状態を作ります。

参考資料