プロダクトマネージャーになって半年がたった
プロダクトマネージャーになってから半年が経ちました。
自分にとってプロダクトマネージャーは本当に面白く、向いている仕事だなと実感しています。一人立ちから半年も経つと色々できることも増え、全体概要も把握できたかなと感じていますので、半年なりの学びを共有したいと思います。
この記事では、PMの概略とそれに必要なスキルなどについて触れています。まだまだ経験の浅い自分ですが、半年前に知りたかったことをメインに書かせていただきます。なお現場によって異なる部分も多いので、個人の体験、意見として捉えていただけると幸いです。
プロダクトマネージャーとしての仕事について
それでは具体的に「プロダクトマネージャーとは」という部分に触れていきましょう。
プロダクトの方向性
PMの仕事はざっくり言うと「プロダクトの方向性を決め、その実現に対してコミットする」です。もちろん現場によって微妙な違いはあると思いますが、大枠はどこも同じでしょう。
プロダクトの方向性を決めるということはすなわち、プロダクトがどういった目的で存在するのか、誰にどんな価値をどのように提供するのか、といった部分を決めることになります。この大元をしっかり言語化することで全ての施策や行動の判断基準となり、自分たちの向かうべき場所を明確にしてくれます。この部分が弱いと各ステークホルダーがそれぞれの立場で良いと思ったもの、またその時々で良いと思ったものがプロダクトに反映され、ユーザーはプロダクトが迷走しているように感じ、いつしか離反するでしょう。プロダクトの方向性を言語化しチームと関係者に浸透させることは、いいユーザー体験を届けるための基礎になります。
自分が担当しているプロダクトではOKRを定めました。プロダクトの存在意義としてのOとそこをモニタリングする指標のKRを設定し、各活動を検証できるようにしました。OKRじゃなくても良いのですが、プロダクトの方向性とそこに近づいているのか定量的に観測する仕組みはチームに作る必要があります。
「プロダクトの方向性を決め、その実現に対してコミットする」
先ほどこのように述べました。では、”その実現に対してコミットする”とはどういうことか？これはマインドセットと活動自体の意味の２つを含んでいます。
マインドセットという意味では、「泥臭さ」が求められます。プロダクトの成長を阻害するものがあれば積極的に自分がタスクを拾っていく必要がありますし、加えてまだ見えてない課題を見つけるところから始める必要があります。これを尻込みするような態度はあまりふさわしくありません。泥臭くプロダクトの成長に向き合う必要があります。
そして、プロダクトマネージャーの仕事の詳細は、「プロダクトの目指す世界の実現に対してコミットすること」、これに紐づいています。これが先述した活動自体の意味という部分です。先ほどまでプロダクトの方向性という言葉を使っていましたが、少し解像度を上げました。理想の世界が目的で、それに近づく手段としてプロダクトが存在する、このような関係性です。その上で、プロダクトマネージャーの業務はプロダクトが手段として正しく機能することを目的としています。
ユーザーについて深く知る努力
プロダクトマネージャーはユーザーを深く理解する存在であるため、インプットをし続ける必要があります。 なぜならプロダクトは目指す目的があり、そのためには利用するユーザーの満足度をあげてユーザー数を増やす必要があるためです。ユーザー価値を最大化するためにはユーザーを理解する必要があります。なので、ユーザーからのFBや要望は全て目を通し、気になった定量情報は積極的に取得し、ユーザーとの会話の機会（ユーザーインタビューなど）に積極的に参加する必要があります。プロダクトのペインポイントはどこで、プロダクトの何を気に入っていただいているのか、理解するための努力は継続しましょう。（もちろん難しいことではありますが）
ここで大事なのが、ユーザーの声を鵜呑みにしないということです。もちろんユーザーの声は大切です。しかし、ペインポイントを解消するためには、要望を文字通り受け取ることは避けたほうが良いでしょう。ユーザーの声から垣間見えるインサイトに対して議論することが根本的な問題の解決になります。
仕様や要件の検討
新機能ないし、プロダクトに搭載する機能についてまとめます。 まず、ユーザーストーリーを記載します。ユーザーストーリーには、誰にどんな理由でどんな価値を提供したいのかを明記します。これが該当の要件の軸になります。ユーザーストーリーを目的として仕様を検討し、逐次確認する事で提供したい価値から仕様がずれる事を防ぎます。
次に、どういう機能なのか、どんな外部仕様なのかを仕様書に書いて言語化します。先ほど述べたように、ユーザーストーリーが目的なので、目的を実現する手段としての仕様は複数ある場合があることが多いです。これは色々な観点から検証して最適解を探っていく必要があります。社内はもちろん、できればユーザーにヒアリングしたいところです。また、定性情報だけでなく定量情報も確認しましょう。ユーザーの行動データを見て、ペインポイントを解消するにはどれが最適か検証することが大事です。
仕様書に期待している動作を誰が見てもわかるように書くことは意外と難しいです。言語化が綺麗にできれば最高ですが、そうもいかない場合も多いので、文字だけでなくペーパープロト、もしくはそれに同等のものも見せながらエンジニアやデザイナーに説明できるといいと思います。
バックログの作成、管理
プロダクトマネージャーは、プロダクトバックログアイテム（以降PBI）を作成し管理します。PBIには、概要とユーザーストーリー、受け入れ条件を記載します。この記載内容は現場によってそれぞれだと思います。
※ちなみに自分のチームではPBIに親子関係を持たせて、親は開発では取り扱わず、子を開発で扱うようにしています。githubのマイルストーンとissueで管理しています。（自分がエンジニアなので、githubを採用しました。）
そして、バックログに優先順位をつけていきます。優先順位をつけることでどの順番で製品に機能を追加したりしたいかを明確にします。リソースは限られているので、リリースの時期やたくさんの変数から何を優先すべきか意思決定することで製品価値を最大化させます。
この辺のスケジューリングや進捗のマネジメントも重要な業務です。開発の知識も必要でしょう。
関係各所との調整
プロダクトにはさまざまなステークホルダーが関わっており、プロダクトを成長させるためにはそれらの方々の協力はとても大切です。プロダクトの責任者として協力を仰ぐためには、簡潔にわかりやすくコミュニケーションする必要があります。人当たりも大切な要素です。
これはヘコヘコするような態度ではなく、立場や役割が違う中でその違いを踏まえた上で適切なコミュニケーションができるかどうかをさします。やはり、立場や役割が異なるとどうしてもそれぞれで利害関係が生まれます。同じ事象に対する見方もそれぞれで異なります。そういった中で画一的なやりとりをするのではなく、関係者の立場に応じて適切にコミュニケーションできることが大切です。
リリース
プロダクトは終わりがないですが（そう仮定する）、実際のリリースにおいてはリリース日があります。ここまで色々なステークホルダーにコミュニケーションをとり、依頼事項を依頼し、プロダクトマネージャーとしてプロダクトの成長を第一に考えてきました。ただ、ここで気を抜いてはいけません。リリースしてから問題がないように成果物をPM自身でしっかり触ってみましょう。仕様書と今までやってきたプロセスを振り返り、何か問題がないか最後の最後まで確認します。問題なければ無事リリースとなります。チームと関係者にお礼を言い、ユーザーの反応を待ちましょう。
リリースした後の効果測定
もちろん、リリースした後もプロダクトは続きます。検証をしないと今後立てる仮説の質が上がらず、プロダクト全体として成長しません。
まずは定量情報として、リリースした機能がどのくらい使われているのか確認しましょう。そして定性情報で確認できるものは確認しましょう。ここから推察できることを挙げて、次回のリリース、その次のリリースと反省点を反映させることが大切です。常に検証することは意識づけておきたいです。
必要スキル
開発知識
最低限の開発知識は必要です。自分はフロントエンドのエンジニアも兼務しているので、苦労はありませんでしたが、エンジニア経験のないのPMの場合はキャッチアップする必要があります。開発知識がないと、各施策や実装がどのくらいの工数がかかるのか見通しを立てられませんし、どんな仕様が問題を生むのか予測ができません。ここは ITプロダクトであれば必須となります。
デザイン
デザインについても理解があるとなお良いでしょう。UXやどんなデザインがユーザーライクなのか知識として知っておくと、より良い案を検討することができます。加えて、関係者で議論しているときに具体的なデザインを定義、提示することで共通認識を取れるメリットがあります。そのため、figmaやXDなどのプロトタイピングツールを使えることも大切です。
データ分析
ユーザーの行動データや施策を検証する際に必ずデータを分析します。その際、基礎的な統計学の知識とSQLは必須です。統計学を抑えていると、データが提供している事実をしっかり事実として見ることができるようになります。もちろん深く学習しようと思えばいくらでも深く学習できると思いますが、基礎だけで構いません。また、欲しい情報をSQLですぐ確認することはどの業務でも必要になります。実際に書かないとなかなか覚えられないのですが、SQLは使いこなせるとベストです。
ビジネス
最低限のマーケティングや営業の知識は必要になります。ビジネスサイドと議論することは必ずあるので、共通言語として最低限押さえておきましょう。また、BtoBであれば営業の方が日々ユーザーと接しているので、営業の方にヒアリングする機会はあると思います。ビジネスと開発で溝ができないように気を付けましょう。
まとめ
プロダクトマネージャーは業務が抽象的でよくわからないと言われます。しかし、全ての業務は一貫していてプロダクトの成長を常に考えることです。そのために必要なスキルは幅が広く責任もありますが、とても楽しいです。
半年経過したけど、これからも頑張ります。
参考文献
この記事が気に入ったらサポートをしてみませんか？