toB SaaSの新米プロダクトマネージャーがまず初めにやるべきこと

はじめに

※この記事は初めてプロダクトマネージャーになる人が、最初にやるべきことを自分の経験則からまとめたものになります。特にtoB SaaSのプロダクトマネージャーに関しての事柄になります。

プロダクトマネージャーの業務内容は多岐に渡ります。プロダクト戦略の立案、ロードマップの作成、要件定義書の作成、関係部署からの開発要望収集、開発機能のサービスイン、リリースノートの作成、リリース後のKPIの確認、プレスリリースの作成、開発機能の法務チェックなど。

多岐に渡りすぎていて、プロダクトマネージャーは総合格闘技と評している人もいます。そのため、初めてプロダクトマネージャーになった人は何から初めていけばいいかわからなくなると思います。そういった人たちに向けてまずはこれをやれば間違いないというのを書き留めました。

シチュエーションごとに顧客に会う

一番初めにやることは、前々から思い描いていたセクシーな機能の企画書・要件定義書を書くことではありません。

色んな記事で書かれていたりあしますが、まずは顧客に会いに行ってください。それもシチュエーションごとに顧客に会うということを意識してください。

シチュエーションごととは以下のような状況が違う顧客のことを指します。

・プロダクトの営業を受けている状況の顧客
・受注が決まり導入のオンボーディングを受けている状況の顧客
・契約の解除・解約をした状況の顧客
・実際にプロダクトを使っている状況の顧客

なぜシチュエーションごとに顧客に会いにいくのかというと、toB SaaSの顧客は状況（シチュエーション）ごとで行なっている業務や持っている課題が異なるからです。

例えば、プロダクトの導入の決裁権を持っている人と、実際に導入してからプロダクトを使う顧客というのは別であることが往々にしてあります。決裁権を持っている人はマネージャーレイヤー以上が多いため「ダッシュボードで簡単に数値を見たい」という要望があったりますが、毎日プロダクトを使うメンバーレイヤーからすれば「ダッシュボードが充実しているよりも、日々の入力の手間を省いて欲しい」という別の要望を持っていたりします。

そのため、営業時に刺さる機能やプロダクトのコンセプトが、実際の運用時にはあまり重視されていないなどのギャップが存在することがあります。機能開発の際にトレードオフを考えることができるようになります。
「Aという機能を開発するとしたら、営業時には武器になりそうだけど、運用時には使ってもらうユーザーには手間がかかってしまいそうだな」など。（もちろんそうならないようにUI/UXを最適にする努力はします。）
そのため、シチュエーションごとの顧客に会いに行って、顧客のそれぞれの立場からプロダクトを見ることをオススメします。

また、自分が行なった中で最もインパクトがあったのが、実際にプロダクトを使っている状況の顧客に会いにいくことです。

それもプロダクトを導入している顧客にお願いをして、一日その顧客について周りどのような業務をしているのか、その業務の中でどのように自分たちのプロダクトを使っているのかを実際に生で見ることです。
これをすることで、顧客の業務とそれに付随する課題の解像度が別次元になります。この経験が開発機能の要件定義やプロダクトロードマップを考える時に、非常に大きな材料になります。

仮にあなたは在庫管理システムのプロダクトマネージャーだとします。担当している在庫管理システムに検索機能を作ることになったと仮定します。
要件定義書や開発メンバーには以下の2つのうちどちらで伝えるとよりよい機能となるでしょうか。

「多くの顧客から検索機能を作って欲しいと要望されています。全体検索の際には "商品名" を入れることが多いということを聞きました。」

「多くの顧客から検索機能を作って欲しいと要望されています。主に使うユーザーは営業メンバーの方で、顧客から電話で注文を受けて商品の在庫があるのか確認し、あればすぐに販売しています。この時に、顧客から“商品名”を言われることが多く、現状は検索検索機能がないので、商品の一覧から探し出しており、見つけるのに2分ほどかかっていました。」

後者の方がよりよい検索機能が作れると思いませんか？

百聞は一見に如かず。ヒアリングは大事ですが、実際に自分の目で見て感じることの方が情報量が遥かに多いです。
様々なユーザーにお願いしてプロダクトを触っている所を実際に横で見せてもらうようにしましょう。

関係各所の部門長に1on1をお願いする

プロダクトマネージャーの仕事を実際に始める前に、関係各所の部門長に1on1をお願いしましょう。
目的は以下の2つです。

・密にコミュニケーションが取れるように仲良くなる
・今の事業課題やプロダクト課題をヒアリングする

プロダクトマネージャーは開発メンバーだけでなく、機能要望の収集、ロードマップの作成、開発した機能のサービスインなどで関係部門と密にコミュニケーションを取ることになります。
その際にスムーズにコミュニケーションが取れるようにするため、各部門の部門長と仲良くなっておきましょう。
挨拶回りなどをした際などに思い切って1on1をお願いするといいと思います。1on1でグッと距離を縮めましょう。

また、1on1の際に事業課題やプロダクト課題をヒアリングするようにしましょう。部門長レベルになると、その人なりの事業の課題やプロダクトの課題などを必ず持っています。特定の部署だけでなく様々な部署からヒアリングすることによって、事業の流れの中でどこがボトルネックになっているのかがわかってきます。

「営業の人はプロダクトの中のAの機能が武器だと言っていたが、マーケティングの人はBの機能を売りにしている。マーケティングの際に伝えていることと、営業時に伝えていることでギャップが生まれてしまい、商談後からの受注率が低くなっているのかもしれない」ということがわかったりします。（これは極端な例なのでそういった明確な齟齬は起こらないと思いますが、小さいなところで解釈の違いなどはあると思います。）

プロダクトマネージャーは事業のボトルネックを特定し解決することが仕事です。しかし、なったばかりだとボトルネックを特定することは難しいと思います。最初の頃は各部門長に聞いて回って、ボトルネックに当たりをつけていくことが大事だと思います。

まとめ

プロダクトを触って機能を把握する、競合調査をする、ロードマップを作成する、バックログを作成するなど、プロダクトマネージャーはやるべきことは多くあると思います。
ただ、この記事で挙げた2つは見落としていたりすることも多い事柄だと思いますので、プロダクトマネージャーになったばかりの人はぜひやってみてください。
今後多くの問題が立ちはだかるであろうプロダクトマネージャー生活の、大きな財産になるはずです。

さまざまな意見があると思いますので、Twitterなどでご意見いただければと思います。

\Twitter/

Tweets by ryouzi_pm