プロダクトマネージャーの役割は物事に変化をもたらすこと
プロダクトマネージャーは、プロダクト作りや運営にあたって組織内のさまざまな役割の人たちと関わっていく存在。丹野氏は、架空のタスク管理ツールを提供している組織を例に、開発、マーケティング、営業、そして経営陣と、立場の異なる4種の関係者とコミュニケーションをとるシーンを通して、プロダクトマネージャーの役割や振る舞い方を解説した。
提供するサービスは、カンバン方式のタスク管理ツールで、主に非IT部門の利用者が多い。無料3か月のトライアル期間の後、本契約となり、直近で単月黒字を達成したものの、売上成長は見込みを下回っているという設定。
プロダクトマネージャーの設定は、経験3年目で、課題を発見して解決策を考案したり、開発チームと解決策を実現したり、KPIを定義して効果を測定したりできるような存在。会社の方針や社内でのやりとりに課題を感じている。
丹野氏は、冒頭にプロダクトマネージャーの役割について「物事に変化を起こすこと」と定義した。そして「例えば、困っているユーザーの課題を解決することです。皆さんは、社内の関係者との関わりに変化を起こせていますか？ 会社の方針や各部門のやり方など、社内のさまざまな人たちとの関係性に積極的に変化を起こすことが、プロダクトマネージャー3年目の壁を突破する鍵になると思っています」と投げかけた。
開発チームとはビジネスのゴールや戦略をもとに、やるべきことの意識合わせをする
最初のシーンは、プロダクトマネージャーにとって身近な存在である開発チームとのコミュニケーションだ。新たな機能として、タスクに複数の担当者を設定できるという機能を追加したい件について開発チームに相談したところ「なぜこの機能を作る必要があるのですか？」と問われた。また、開発チーム内のデザイナーもやるべきことが決まって降りてくる現在の仕事のスタイルにやる気を感じていない。想定されるユーザーの課題を説明しても、メンバーが納得していないといった設定だ。
こうした状況について丹野氏は参加者に解決策を問うと、チャットには「開発者とデザイナーをユーザーヒアリングに同席させる」「ユーザーが課題と感じる状況をロールプレイしてみるべき」「いきなり解決策を示すのが間違いで、先に課題を相談して解決策の意見を集めたほうがいい」といった意見が寄せられた。
開発チームに「Why？（なぜこの機能が必要かというユーザーの課題）」を説明したにもかかわらず、納得を得られない場合の背景として丹野氏は、開発メンバーが持つ疑問を提示した。そもそもユーザーの要望に応えることがよいことなのか？ 機能を追加した場合のROIは？ なぜこの機能を今優先するのか？ といった「Why now？（今どんな成果が求められているか）」を示す必要があるという。
丹野氏は、Why nowを示すためにはビジネス分析が必要とし、今回の設定での分析の例では「既存顧客が追加ライセンスを購入した際に売上がアップした」ことや、ユーザーの利用状況を分析した結果「多くの部門で利用している顧客の収益貢献が高い」を挙げた。
このようなビジネス分析から、売上目標達成のために追加ライセンスを増やしたいといったゴールを設定し、契約ライセンス数の多い企業のユースケースを広く展開、そのために新しい機能を追加する……といった戦略を共有するというのだ。
「当初の案が本当にベストな解なのか議論になることもあると思います。皆で議論することでより良いアイデアが出る可能性も高まるでしょう。プロダクトマネージャーとしてはそれをうまく評価して優先順位を決定していくことがよいと思います。ビジネス分析によって課題の目線を上げていくことで、開発チームは、単に機能をデリバリーするアウトプット志向ではなく、最終的にどんな価値を提供するかというアウトカム志向に変化していくでしょう」と丹野氏は付け加えた。
