見出し画像

プロダクトマネージャーに必要な13のこと

はじめに

私はsalesforce.comでAI製品であるEinsteinの日本のプロダクトマーケティングマネージャーという役職になってから、サンフランシスコにある本社の開発チームとコミュニケーションをすることが多くなりました。

さらに今年からマーケティングではなく、プロダクトマネージャーとして、AI製品や、それ以外にもコアと呼ばれるメインの製品やEmerging Productsのような最新の製品の日本のプロダクトマネージャーをやっています。

Twitterもぜひフォローしてください!

今回、日本から見る海外の超大規模な製品開発の動きを客観的に見て知ったプロダクトマネージャーに必要な13のことをまとめてみました。

アジャイル開発、スクラムをベースに行われているSalesforce本社の開発の姿を、あくまでも製品の機能開発をもたない日本のプロダクトマネージメントチームから見た姿であることはご了承ください。

Product Manager Responsibilities

1. “Voice of the customer ”になることができる。
2. 製品の戦略と競合のポジショニングを理解できる。
3. ビジネスを前進させ、短期、中長期のゴールとのバランスをとることができる製品を提供する
4. 製品開発の管理を手伝い、タイムスケジュールと成果物について開発部門と連携できる。
5. 市場の問題点やアイデア、社内からのリクエストなどを特定し、フィードバックを収集して管理できる。
6. 機能要件を収集し、ユーザーストーリーに分解できる。
7. 機能開発の可能性を定量化し見極め、優先順位を付けられる。
8. ソリューション設計のブレインストーミングとSolution Document Designsができる。
9. 製品開発のバックログの保守を含む、製品オーナーになる。
10. ユーザーリサーチを実施して、顧客の要件とVertical Trendsを深く理解できる。
11. 市場のリサーチや分析、業界の動向、顧客の視点に基づいて新しいビジネスチャンスを見つけられる。
12. Win/Loss分析の実施ができる。
13. 開発チームとの日々のミーティングに参加することができる

これがプロダクトマネージャーに必要な13のことです。
下手くそながらGraphic Recordingしてみました。

図で俯瞰的に見ると、プロダクトマネージャーのステークホルダーは大きく、①顧客(市場)、②開発スクラムチーム、③会社があることがわかります。

以下では、この俯瞰図をもとにそれぞれについて簡単ではありますが解説しています。

①"Voice of the customer ”になることができる。


これは製品開発において最も重要なことの一つです。なぜならは、製品は顧客に使ってもらってこそ価値ができるからです。日本でもVoCという言葉が流行っていますが、ここでポイントなのはVoCを"聞くこと"や"調査すること"ではなく、"Be the voice of the customer"という点であることです。

つまり、顧客の声をヒアリングしたり調査するだけではなく、プロダクトマネージャーとは顧客の代わりであり、顧客の声の代弁者として、製品開発に貢献しなければいけないということです。

②製品の戦略と競合のポジショニングを理解できる。


プロダクトマネージャーは製品という大きな船の舵取りをしなければいけません。自分たちの製品を、顧客、会社の方針に合わせてどのように戦略立てて開発していくのか。そして競合の動きや、市場の動向に合わせてどのように適用させていかなければいけないのか、それを深く理解することが必要です。

製品開発の始まりは、思いつきやテクノロジードリブンではありません。もちろんアイデアや閃きも重要ですが、しっかりした製品戦略がこそが素晴らしい製品開発のための羅針盤になります。

③ビジネスを前進させ、短期、中長期のゴールとのバランスをとることができる製品を提供する。

製品の開発は最も重要です。しかし、一企業に勤めている限り好き勝手に自分の思い通りの製品を開発できるわけではありません。会社が目指している、ビジョン、そして短期・中長期のゴールに沿った製品や機能を実現し、顧客に提供しなければいけません。

そのためにsalesforceの開発チームでもV2MOMと呼ばれる全社共通のフレームワークに沿って、毎年年初に目標を定めて、開発を行っています。

④製品開発の管理を手伝い、タイムスケジュールと成果物について開発部門と連携できる。

製品を開発するエンジニアは最も尊重しなければいけません。salesforceの開発チームでは、プロダクトマネージャーとエンジニアリングチームは上司と部下という関係ではありません。あくまでも別々のラインであり、ともに製品開発を行うチームになります。しかし、エンジニアたちは個別の機能開発に最も注力しているので、プロダクトマネージャーは開発全体のバランスを見て、製品開発スケジュールを調整する必要があります。

そのために開発のバックログを管理し、チームの進捗をコントロールする必要があります。

⑤市場の問題点やアイデア、社内からのリクエストなどを特定し、フィードバックを収集して管理できる。

一つの製品や機能を提供したらそれで終わりではありません。製品開発は常に改善を続ける作業です。今ある機能をより良くしたり、全く新しい機能を提供したり、常により良いものを作る必要があります。

そのために、今のマーケットで問題になっている点を顧客や社内からの要望、チーム内でのアイデア、リサーチ会社のレポート、市場から評価をフィードバックとして適切に収集して、管理する必要があります。

そこで集まったフィードバックたちは次に製品開発に繋がっていきます。

⑥機能要件を収集し、ユーザーストーリーに分解できる。

さまざまなところからのフィードバックを集めたら、それらをもとに機能要件をまとめ、さらにそれらをユーザーストーリーに分解する必要があります。

ユーザーストーリーとは、エンドユーザーの視点で「誰が」「なぜ」「何を」「どのようにして」その製品を使うのかというのを簡単な文章で記述する、ソフトウェアのアジャイル開発の最初のステップです。

集めた機能要件や要望は粒度もバラバラで、何が必要で、それぞれがどのように影響し合うか全体を掴むのは難しいです。ユーザーストーリーによって、それらの機能を流れで整理することができ、抜け漏れなく、そして完成時の利用イメージをチーム内でバラつき無く明確に持つことができます。

ユーザーストーリーに落とすことで、エンジニアとの会話のズレを無くし、開発プロセスを整理することができます。

⑦機能開発の可能性を定量化し見極め、優先順位を付けられる。


ユーザーストーリーに落とされた機能たちは、次に優先順位づけしなければいけません。そのために必要なのは、それぞれのユーザーストーリーの実現可能性を定量的に見極めることです。ここでいう実現可能性とは、今あるテクノロジーで開発できるのか?というよりは、「与えられているリソースでリリース時期までに開発が間に合うのか?」というような観点です。

そのために、プロダクトマネージャーは、一つひとつのユーザーストーリーに対して、ストーリーポイントというのを付与します。ストーリーポイントというのは、そのストーリーを実現するのに必要な工数をポイント制にした架空の単位です。

このストーリーポイントをベースに、エンジニアと会話をし、そのストーリーの実現可能性を定量的に見極めます。

そして、リリース時期に合わせて、優先順位をづけを行い、元々想定していた全体のユーザーストーリーの中からどこまでが実現できそうかの線引をプロダクトマネージャーが責任を持って行います。

⑧ブレインストーミングとSolution Document Designsができる。


さて、ストーリーポイントが付与され、エンジニアと適切にコミュニケーションが取れれば、製品や機能は時期に合わせてリリースすることができます。次にプロダクトマネージャーがやらなければいけないことは、次に何を作るのか?を考えることです。⑤でもお話したように、製品開発とは常に改善を続けなければいけません。その中で重要なのは新機能の開発です。

市場の動向やアイデア、顧客の要望などから、新機能や改善すべき新しい機能のアイデアをブレインストーミングをして考える必要があります。そして、そこで着想を得た製品アイデアを、ドキュメントデザインしなければいけません。ここで言う、ドキュメントデザインとは機能を説明するプレゼンテーションや資料などのドキュメントに、ソリューションを落とす作業を指します。(他にもソースコードや社内/社外のFAQ、契約書類や開発に必要なドキュメントも含みます。)

ここでアイデアをしっかりと形にする能力がプロダクトマネージャーには求められます。ドキュメントにする必要はいくつかあり、下記にまとめてましたが、改めてnoteに書きたいと思います。

⑨製品開発のバックログの保守を含む、製品オーナーになる。


プロダクトマネージャーはその製品の責任者でなければいけません。バグやエラーがあったり、リリース時期に間に合わないことがあっても、エンジニアのせいではなく、その責任はプロダクトマネージャーにあります

そのために、スクラムチームではバックログを管理しなければいけません。バックログとは大きく2つにわけることができ、①プロダクトがユーザーや顧客に提供する価値を記述する「プロダクト・バックログ」と、②当面の作業計画を示す「スプリント・バックログ」です。①は前述したユーザーストーリーで管理され、②はそこに付与されたストーリーポイントをベースに管理します。

これらのバックログをプロダクトマネージャーは責任を持って管理する必要があります。


⑩ ユーザーリサーチを実施して、顧客の要件とVertical Trendsを深く理解できる。


⑧のブレインストーミングの際に重要なのはユーザーリサーチです。すべての新機能が閃きのアイデアから出てくるわけではありません。戦略的で計画的なユーザーリサーチを行って、顧客ですら気づいていない顧客の要望を見つける必要があります。

ユーザーリサーチを通して得た複数の顧客の要件は、業種業界の個別のニーズやトレンドを理解することに繋がります。

⑪市場のリサーチや分析、業界の動向、顧客の視点に基づいて新しいビジネスチャンスを見つけられる。


⑩で示したユーザーリサーチの他にも、市場や業界の分析、競合の分析を通して、新しい製品開発のビジネスチャンスを見つけなければいけません。そして、これらのリサーチはすべて顧客視点に基づいていなければいけないということも忘れてはいけません。

顧客視点にもとづいた全体を俯瞰的に見たリサーチによって、新たなビジネスチャンスを見つけることができます。

⑫ Win/Loss分析の実施ができる。


リサーチ、分析、提案、開発を通してやっと製品が提供されます。そして、今後の改善のために、Win/Loss分析をしなければいけません。一企業におけるプロダクトマネージャーは仕事であり、もちろん競合他社も同じように力をいれているわけですから、勝つことも負けることも、想定とは違うことも起きます。そのために、失敗してしまっても落ち込むことはなく、しっかりと分析して次に活かす必要があります。また順調に勝っていたとしてもそこでおごること無くさらなら改善を目指す必要があります。

そのために、実際に負けてしまった商談を分析したり、MAU(Monthly Active User)やAdoptionを分析したり、ユーザーからのヒアリングを通して、Win/Loss分析を行うことが重要です。

⑬ 開発チームとの日々のミーティングに参加することができる。


最後になりましたが、このようないくつもの役割は到底プロダクトマネージャー一人ではなりたちません。前述したような開発チームや、スクラムマスター、データアナリストやデザイナーなどと日々コミュニケーションを取ることで、効率的で効果的な製品開発を実現し、世の中に最高のプロダクトを提供することができます。

おわりに

私自身、新卒でSalesforceに入社し、まだまだ開発の現場は知らないことだらけですし、プロダクトマネージャーとしても日がまだまだ浅いです。

ただ、13のことすべて"○○できる(ようになる)"としたのは、自分自身が今後このようなプロダクトマネージャーになれるようにという意味も込めて書きました。
もちろん、今回まとめたプロダクトマネージャーに必要な13のこともこれが全てではなく、その時々にそれぞれに最適なやり方や、求められることがあると思います。

イノベーションが最も重要なコアバリューの一つであるSalesforceにいることを貴重な経験とし、世界で最も革新的な企業のプロダクトマネージャーの姿をこれからも日々学んでいきたいと思います。


この記事が気に入ったらサポートをしてみませんか?