見出し画像

to BプロダクトのPMが成果を出すために持つべき13のスキル

メルペイのPMやってます、さとじゅんです。

to B向けプロダクトをやってきて、成果を出しているPMが持っているスキルについて考えてみたので、後から振り返りできるようにnoteに記しておきます。

プロダクト開発をしていく上では、ここに記載した以外にも大切なことはいろいろあると思います。

ですが、今回はその中でも特に必要ではないかと思ったことをピックアップして書いてみようと思います。

※ ちなみにto BプロダクトとはビジネスモデルがB to B(C)やB to B to Cの事業において企業向け(to B)に提供しているプロダクトを指します。
※ 基本的にはto C向けプロダクトのPMと同じスキルな部分もあると思うのですが、微妙に違うところもあるのではと思ったのであえてto B向けとして定義しています。


1/ 一次情報を重視する

人から伝えられた情報を受け取り続けるのではなく、自ら情報を取りに行って一番新鮮な状態を真正面から受け取り、自分の血肉にしていく

こういった取り組みを続けているからこそより成長していけるのだと思います。

一次情報といっても種類はさまざまです

例えば他社サービスに触れることもそうだし、顧客の声を直接聞くこともそうだし、自分でなにかをやってみることもそうだと思います。

ここには情報をただ受け取るだけではなく、自ら受け取りにいく姿勢が見られるので、主体性が勝手にInstallされていきます。

余談ですが、特に B to B to C系サービスにおいて、特定の領域でシェアが高かったり、昔から人気のサービスだったりの場合、サイト上には書いてない料金プランが存在したりすることがあるので自分で体験することはとても重要だと思います。

また、to B向けサービスだと自分で利用するのにはハードルがあったりするので申し込みをためらってしまう人も多いと思うが、気にせず申し込んでみて実際に体験するのをおすすめします。

アライアンス系の案件でBizDevが基本的に相手企業の担当とのコミュニケーションを行っている場合でも、PMは会議に同席するなどして相手担当の顔を知っている場合は、直接話をしてみることも必要だと思います。

こうした一次情報を主体的に得ることがより良い打ち手につながり、さらに自分自身の良い習慣につながっていくのではないかと思います。

主体性良質なインプットにつながるポイントだと思います。

2/ 顧客の業務や課題にDeep Diveする

顧客が実際に行っている業務はどんなことでしょうか。

それは、自分たちが想像していたよりもっと複雑で、やらなければいけない回り道を理由があるからあえてしていることも多々あるはずです。

そういった顧客のワークフローの細部や、点在する課題のひとつひとつをすべてDeep Diveして解像度高く理解していなければ、正しい打ち手を考えることはできません。

自分たちが想像していたよりもっともっと現実は違うことが起きているはずで、そこにさまざまなヒントが隠れているはずです。

自分の先入観をとっぱらって事実と向き合う。

観察することで本質的な課題をあぶり出していく。


相手の気持ちに立って考え、問いを投げかける。

これらが課題発見力(観察力、質問力) につながるポイントだと思います。

3/ 人の話を鵜呑みにせず常に「なぜ」を問い続ける

PM的にはSalesからの要望はいつもいろんな人がいろんなことを言ってくるなーと思うことが多いと思います。

それはさまざまな顧客が、さまざまな悩みを、さまざまな観点で伝えてくれるので仕方ないことでもあると思います。

ただ、こんな時PMならSalesからの話をすべて鵜呑みにしていては真実にたどり着けません。

重要なのは、人の話を鵜呑みにしないためにも「なぜ」を何度も何度も問いかけて、シンプルな形に仕上げてから、自分なりの仮設を考えてみること

この「なぜ」をいかに深く問いかけられるかで、いかにシンプルな答えにたどり着けるかどうかも変わってくるのではないかと思います。

なぜの深掘り仮説思考につながるポイントだと思います。

4/ シンプルなアイデアでExcutionする

課題の深掘りができても、よいアイデアが加わらなければ良いExecutionにはつながりません。

日頃からさまざまなサービスに触れていることで引き出しの数が多く、また自分なりに仮説を立てて他社サービスがなぜその機能を作ったのか考えていることで、自分の引き出しにより意味のある情報をしまっておけると思います。

その良質なinputが良質なoutputにつながり、良いoutcomeにつながっていきます。

また、課題に対して何度も何度もなぜを問いかけていくと、不要な要素がどんどんと取れていき、最終的にとてもシンプルなアイデアに着地することがあり、この場合振り返ってみていいアイデアだったなと感じる事が多いように思えます。

企画力・提案力につながるポイントだと思います。

5/ ビジネスの因数分解とP/Lを意識した設計をする

to B向けの新規事業の立ち上げを経験してきたPMは、エンジニアリングだけでなく、ビジネスで考えるべきポイントを抑えている傾向にあると思います。

ビジネスを推進するために必要な要素を因数分解して、整理することで事業のドライブに必要な力点を把握する。

さらにP/Lを意識してマネタイズ設計を行い、プロダクトの持つ価値とビジネスを合致させる。

特にto B向けにビジネスを展開する上で重要なことは、大きなシナリオを描いてその線の上にさまざまなプロダクト戦略とビジネス戦略を同時に載せていき、最高のUXをInstallさせた形で顧客にDeliveryしていくことかと思います。

プロダクトとビジネスが密接に関わる必要があるので、ビジネス設計力につながるポイントだと思います。

6/ 事前にステークホルダーとしっかり握る

外部ステークホルダーとの合意があいまいなまま開発を進めると、あとでどんでん返しが起きたり、直前で待ったがかかったりと、PM的には不幸な結果を生みやすくなってしまいます。

その点を理解しているPMは、まずステークホルダーとの合意を明確にします。
これをこのnoteでは「握る」という言葉で表現します

不確実性をビジネスサイドでつぶしてから、プロダクト開発に入ることで、安全にリリースまでの道のりを進むことができます。

その握りをしっかりと行うためには、交渉力と調整力が必要で、このスキルを持っているPMは強いと思います

7/ リリース後の使われ方や業務設計を考え抜く

どんな仕様にするかだけでなく、リリースされた後にどんな使われ方をするかというイメージやストーリー、ワークフローの設計までもが考え抜かれていると、プロダクトの価値を最大化できると思います。

プロダクト仕様やUIだけでなく、利用する方の前後の体験をいかにシンプルかつなめらかに設計するかというUX部分があって、はじめてプロダクトが価値を発揮して提供できる状態になっていくのではないでしょうか。

UX思考につながるポイントだと思います。

8/ エンジニアリングと開発の推進に必要なことを理解する

自分でコードを書いた経験はmustではないと思います。

重要なことはDBの構造を理解していたり、システムアーキテクチャが理解できていて、エンジニアと同じ言葉で話が通じること。

そして、なにか新しい機能を作りたくなった時など、どこにどう手を入れていけば実現でき、どういったデータが必要となり得るのかを理解できていることかと思います。

またscrumなどHowはさまざまですが、開発サイクルを回して、チームのSPRINTを回して改善していき、常にチームをアップデートさせていけるのかが重要になると思います。

PMにおけるエンジニアリング理解ということだと思います。

9/ 巻き込み力が高く大胆にPJ推進する

特にステークホルダーの多いPJだとこの推進力がかなり重要になります。

さまざまな壁が立ちはだかる中、あらゆる人を巻き込んで、壁を越えようとする姿勢こそが、PJの推進力につながり、メンバーのリズムを作っていくと思います。

大胆なPJ推進は時に間違ったことをしてしまうかもしれない恐怖との戦いでもありますが、迷わずやりきれる人、間違っても大胆に方針転換して勢い変わらずPJ推進していける人が結果的に成果を出していくのではないでしょうか。

10/ 定量的な分析を通じて数字にDeepDiveする

とにかくアクションを起こした後も検討段階でもさまざまな数字に触れて事業の解像度をあげていく。

なにが想定内でなにが想定外だったのか。
いくつかの分析軸に切り分けてひたすらに数字にDeepDiveしていく。

特にBIチームがいる場合は一緒になって答えを導いていくのがよいと思います。

このプロセスを継続的に行うことで数字が頭に叩き込まれてくるので、発言の中にも具体的な数字が随所に入ってきて、意思決定のスピードもあがっていきます。

またひとりで数字を見るのではなくBIツールなどを駆使して、チーム全員が意識できるように道標を作るとチームの成長に貢献することもできると思います。

ここは分析力つながるポイントだと思います。

11/ 仕組みを作って人に任せる

自分がいなくても回る仕組みを作って任せて、自分はまた別の課題解決に向かう。

これがPMの仕事なのかもしれません。

いつまでも自分がボールを持ってしまわないように、いろんな仕事にチャレンジするための身軽さを忘れないために、仕組みを作って任せていきます。

数字も誰でもわかる状態にし、運用ルールを決めて、チーム間の責務を決まる。

この一連の流れで仕組み化が完成して、ワークフローをグルグルまわしていきます。

12/ 施策の優先順位にストーリーがあり選択と集中をする

PMの基本的なスキルではありますが改めて、優先順位をどう決めていくか、そして、選択と集中ができていて、やらないことが明確になっているかが重要です。

施策の優先順位に関しても、ストーリーとして語れる必要があり、それがないと説得力がなくなってしまいます。

PMはストーリーテラーとして施策の優先順位を語れる必要があると思います。

そのためにも、あるべき姿から逆算していまなにをどの順番でやるべきかを理解している必要があると思います。

その上で優先順位の絞り込みが必要なのではないでしょうか。

13/ プロダクトとビジネスのあるべき姿を語れる

PMならプロダクトビジョンを語れる必要はありますが、セットでビジネスとしてどうあるべきかを語れるとなお良いと思います。

あるべき姿があって、そこから逆算して打ち手を考える。

あるべき姿があって、今どこにいるのかなるべく解像度高く現在地を把握する。

これらはすべて中長期的にプロダクトを伸ばしていくためにも必要なことのひとつだと思い、プロダクト、ビジネス両方の課題解決ができる人材になるとツヨツヨな人材になれるのかもしれません。

プロダクトビジョンにつながるポイントだと思います。

ここまでがスキルの話です。

プロセス別にスキルをマッピング

ではそれらのスキルがプロダクト開発においてどのプロセスで大事になるかも合わせてまとめていきます。

(1) issueの選定・Whyの深掘り

・主体性・良質なインプット
・課題発見力(観察力・質問力)
・「なぜ」の深掘り・仮説思考


(2) What・Howの構築

・企画力・提案力
・ビジネス設計
・交渉力・調整力
・UX思考
・エンジニアリング理解


(3) 開発推進・リリース

・エンジニアリング理解
・調整力
・推進力


(4) 分析・検証・仕組み化

・分析力
・仕組み化


(5) ビジョン・ロードマップ

・プロダクトビジョン
・優先順位の絞り込み

これ以外にも大事な要素はありますが、今回は特に重要だと思われる13項目のプロットをしてみました。

番外編

いつも相手を思いやり丁寧なコミュニケーションができる

PMとしてエンジニアリングとビジネスを理解していると、ビジネスサイドの方の発言に強気に出てしまうシーンがあったりします。 

またはプロダクトの仕様を理解していない人に強めに当たったりしてしまうことあるかもしれません。

いつも謙虚に優しく接することができる人が最終的に信頼されるPMなのではないでしょうか。

やさしいPM is 大事!!

これが基本中の基本。

ねばり強くやり続ける

ちょっとやそっとのことでは折れない。

成果が出るまでやり続ける。

これがシンプルだけど一番できない。

だけどとてもとても重要なこと。

さいごに

なんとなくこんなスキルを持った人が活躍しているなと思ったことをまとめてみました。

他にもあるかもしれませんし、異論もあるかと思いますが、あくまで自分の備忘録的なものなのであしからず。

ということで、今日はここまで!

最後までお読みいただきありがとうございました。

※ to Bプロダクト開発のあれこれをTwitterでもつぶやいてます。

興味持ってくださった方はよろしければTwitterフォローもお願いいたします。

https://twitter.com/junsam22

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