PMからSales/BizDevに伝えたい、プロダクト開発における4つの大切な考え方

メルペイのPMのさとじゅんです。

to B向けプロダクト開発のPMとして働く上で、SalesやBizDevの方(以下Sales)から、「あの会社が◯◯で困っているから✖️✖️という機能が欲しいのだけど検討できないか」という話を貰うことはたくさんあります。

こんな時にPMの人がどんなことを考えているかについてまとめていきたいと思います。

そしてそれによってSalesの方々がPMの思考を理解して、お互いに建設的な議論がたくさんできるようになると良いなぁと思っています。

PMの現状

いろんな人から要望を受ける

まず大体の場合、PMの人数とSalesの人数はSalesのほうが多いはずです。

この場合1人のPMに対して複数のSalesが要望を上げることになると思います。

いろいろな人からいろんなことを言われるPMからすると、より課題感の深い問題に取り組みたいし、インパクトを算出するためにも数字感など具体的ななにかが欲しいと思うことが多いです。

このあたりの情報がないままに工数だけ算出するなんて絶対にやりたくないと考えています。

なにを作りたいかだけを伝えられることが多い

さっきの例で言うと「What(何を作りたいか)」をいきなりSaleが提案してきていますが、他にも方法はあるかもしれません。

解決方法がそれだけとは限らないし、課題の本質が見えてない状況の中で、いきなりWhatを提案されるのは、あまりうれしくないので出来れば避けたいと考えています。

同時並行で一気にいろんな開発をしない

Salesとしては営業を戦略的に進めるため、あるいはクライアントの課題を解決するためにも、複数のプロダクトや機能をたくさん開発して欲しいと思うでしょう。

しかし、開発の現場では限られたリソースの中でやりくりが必要なので、なるべくたくさん並行稼働して開発を同時に進めることを基本的にはしません。

じゃあどうすればいいの？

ではここからは本題の、Salesのみなさんが知っておくとPMとの仕事がうまくいきやすくなる考え方について書いていきます。

1/ 開発は優先順位表の上から1つ1つ対応していく

プロダクト開発をする際にだいたいBacklogというものをPMは管理しています。

これは簡単に言うと、やりたい施策が1つの表の中に優先順位の順番に直列で書かれたものです。

プロダクト開発は上から順番にひとつずつ開発をしていきます。

Salesから「◯◯の修正を既存のクライアントから依頼されたんだけど簡単そうだからサクッとできません？」みたいな話はよくある話で、確かに空いた時間にさくっと終わらすことはあるけれど、基本的にはタスクの優先順位に基づいてやることを決めているので、そこにはトレードオフが発生しています。

上記で開発がサクッと対応したのは「他のタスクとの優先順位とROIを考えた結果、いまのタイミングで対応した方が都合が良い」と考えた結果であり、依頼者が思っているように簡単なことだからすぐに対応しただけではないことが多いと思います。

「PMは優先順位の表の中でなんらかのトレードオフのもと、施策の意思決定をしている」事実は知っておくと良いと思います。

そうすると、「◯◯の開発対応についてクライアントから温度感が上がっているから優先度あげてやってもらえるとうれしいけど、その場合どういう影響がありますか？」みたいな話ができ、PMとの間で建設的な話につながりやすくなると思います。

2/ 「やること」より「やらないこと」を決めたい

Salesとしては、例えばPJの立ち上がり時期にはマーケットに対して、どれが刺さるかわからないから、いろんな機能を開発してトライアンドエラーしてみたいと思うことがあるでしょう。

ただプロダクト開発においてリソースは有限であり、すべてを開発していたらマーケットシェアは取れません。

あまたのやることから本当に必要な一手を見つけ出し、繰り出していくのがPMの真骨頂です。

だから「なにをやるか」より、「なにをやらないか」について決めることの方がとても大切です。

時にはリリース中の機能を止めることもあるでしょう。

Salesとしては既存クライアントで少しでもその機能を利用していたら中止に反発するでしょうが、PMはもうすこし大きい視点でその機能をなぜ中止にすべきか理由を持っているはずです。

なにをやらないかについてSalesはPMと一緒に話をしていきたいと思っています。

3/ 「なにが欲しいか」より「なぜ欲しいか」が聞きたい

冒頭の例のように具体的になにを作って欲しいかをSalesからPMに要望をあげることはとても多いと思います。

でもPMが欲しいのは「Why（なぜ作るのか）」です。

Salesは「なにを作るか」を気にすることが多いですが、PMは「なぜつくるのか」、そして「だれのどんな課題を解決するのか」のほうがずっと興味があります。

それはPMがプロダクト開発を顧客の課題解決におけるやり方のひとつであると捉えているからだと思います。

だから、なぜその機能が必要と言われたのか背景や前提をたくさんPMにインプットしてほしいです。

その議論が終わったらもしかしたら別の解法のほうがよかったみたいな話が出てくるかもしれませんし、プロダクト開発しなくても解決できる方法があるかもしれません。

または前提が間違えていて、正しにいく必要があるかもしれません。

Salesが「What」よりも「Why」をあつく語るとPMは喜んで話を聞くし、前向きに議論を進めるはずです。

4/ やりたい事のインパクトを数字で語ってほしい

よくあるのが「あの企業がこう言ってたからこの機能があるとうれしい」という話。

でもPMは前述の通り、優先順位を付けたやることリストの中の上からやることを決めています。

開発の対応優先度を上げるには、PMが優先度を上げたくなる情報を提供することが必要で、特に定量的なフィードバックが効果的だと思います。
（もちろん定性的な情報も必要ですが）

そのためには、自分のクライアントが言ってることだけでなく、Salesチームが担当するクライアント全体を通してどれくらいその課題を持っている会社が多いのかや、その課題が解決されない事で発生しているネガティブなインパクトはどの程度のものかなどを伝えてもらえるとPMは優先順位の検討がしやすくなります。

顔が見える1社のための課題解決も重要ですが、その課題を解決することでどのくらいのクライアントの課題解決につながるのかを知ることができると、PMは喜びます。

Salesの方がここに対して効果的な情報を提供すると、PMは施策の優先順位を上げることに対して前向きな議論をすることができると思います。

数字で会話するためには

ここはPMもSalesもお互いに努力できるところはあるはずです。

例えばPMはBIツールなど使ってデータを可視化してSalesが数字をより意識して動けるようにフォローしてもいいかもしれない。

Salesは出来ればクエリを書いて自らデータの鬼になるとPMはうれしいはずです。

双方の歩み寄りによって数字で語る文化が作られるのではないでしょうか。

さいごに

PMもSalesに歩み寄る姿勢が重要です。

ここに書いたのはPMの頭の中なのでSalesのみなさんにもたくさんの言い分があるかもしれません。

今回は「PMの人の頭の中ってそういうこと考えてるんだ」と思ってもらえるとうれしいなと思って書きました。

偉そうに書いてしまった部分があるかもしれませんが、PMとしてはSalesの方々が多くのクライアントの窓口として接してくださっていることに敬意を持っていますので、さらによりよい関係値を築くための相互理解の方法としてPMの考え方を書き連ねてみました。

こんなようなことをTwitterでも日々つぶやいていますので、よかったらフォローしてみてください
https://twitter.com/junsam22

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

※あくまで私見を書いているだけなので、所属する企業の意向・見解とは一切関係ありませんので、その旨ご理解いただけますと幸いです。