【PdM】プロダクトの優先順位をどう決めるか？幹と枝の見極め

はじめに
まず、年単位の幹を決める
他部署からの要望にどう対応するか？
顧客からの要望にどう対応するか
顧客の期待値調整をどうするか？
まとめ

はじめに

プロダクトマネージャー（PdM）は、プロダクトのフェーズにもよるが、特にグロースフェーズでは、他部署ならびに顧客からの機能改善の要望が山のように降ってくるので、忙しくなりがち。

本記事では、PdMとしてプロダクトの優先順位をどう決めるか、持論を記載しておく。

かくいう私は、PdMとして系統的な訓練を受けたわけではないので（そういうのがあるのかも知らないのだが）、個人の経験からくる持論of持論なので、その点ご承知おきくださいm(_ _)m

まず、年単位の幹を決める

まず、年初めにプロダクトとして1年で何を達成するか、1年後のあるべき理想の姿を想像し、それを実現するためにやるべき大まかなことを、1つないしは2つ決める。

1サービスあたり、多くても3つまで。それ以上は考えることが多くなりすぎて、プロダクトの方向性も定まらなくなって、プロダクトが幕の内弁当になってくるし、意思決定に時間がかかり始める。

自分が代表でかつPdMも兼任している場合には、自分が理想と思うプロダクトの方向性を決める。一方で、自分が代表ではない場合には、PdMとして自分が考えた案を代表もしくは取締役会で提案して、議論し、合意を取る。

この幹は年単位で達成するべきKPIにも繋がるし、かつ絶えずPdMとして押さえておくべき指標にもなる。

他部署からの要望にどう対応するか？

個人的には組織として健全なのは、他部署がその部署内で出た要望をPdMに対してガンガン伝えて、それをPdMが判断して優先順位を振り分けていく状態。

ただ毎回「それは開発的にはできません」と言い返していると、取り合ってくれないんだとなり、要望そのものが上がってこなくなり、それが一番危険。

とはいえ、他部署からどんどん要望が上がってくると、優先順位の判断をその場その場で迅速にしていかないと、通知地獄にもなるしタスク管理地獄にも陥り、パンクしてしまう。

ここで、先ほど年単位で目標に掲げた、幹となる1つないしは2つのKPIを基準に照らし合わせて判断していく。

プロダクトチームとしても目指すべきKPIに合致している場合には優先度高く対応し、そうでない場合には、プロダクトとしては枝の機能であることを認識しながらも他部署としては重要な機能の場合には優先度中として対応していく。

八方美人で全ての要望にできるだけ対応しようとすると、開発チームに皺寄せがくるのと、「全部他部署からの要望に答えたのですが、（そのせいで）プロダクトチームで追っているKPIは達成できませんでした」では、「そんなこと言われても知らんがな」となってしまう。ある程度Noという力も大切。そのためにも、優先順位をPdMとして主体的に持っておくのが重要。そうでないと、顧客からの要望も他部署からの要望も全て優先度高く見えてしまう。

あとは頭の中で、月単位レベルで良いので大まかに、動いている大きい機能のタイムラインを描いておき、「この要望は2ヶ月後にこの機能が実装された後の方がスムーズに実装できるので、そのタイミングの方が二度手間がないな」などをその場で判断し伝えることで、レゴブロックのように、実装していく機能をできるだけ無駄がないようにタイムラインで頭の中で並べていく。

また、プロダクトチームとしては今年はこのKPIを追っていますというのを、毎月の定例や他部署とのmtgで共有しておくことも大切。ただ、プロダクトのKPI指標項目が4つ以上となると、そもそも自分の部署の仕事で忙しい他部署に認識してもらえない可能性が出てくる。人間、そんなに多くのことは覚えていられない。

顧客からの要望にどう対応するか

顧客からの要望に関しては、非常に重要ではあるが、同時に下記2点も重要。

顧客は課題の表層はわかるが、深層と解決策はわからない
顧客の要望は枝であり、プロダクトの大きな方向性（幹）はあくまでプロダクトチームが主体的に決める

課題のヒアリングは重要だが、それをそのまま間に受けて伝書鳩のように開発チームに伝えるのではなく、「その課題の場合、この解決策だといかがですか？」と、その場で顧客に、できるだけ開発が簡便な方法を逆提案して、その場で解決してしまうのが良い。

顧客からの要望を聞きながら、リアルタイムで、頭の裏では「なるほど。これをこのまま開発するとなるとこのくらい時間がかかりそうで、今、開発チームはAとBをやっているから、やるにしてもこのタイミングで対応となり、、、」などと考えて、

「でも、このお客さんの要望って、もしかしたら、こういう風にすれば解決するんじゃ？」「ここが課題と言ってはいるが、実際に困っているのはXXXっぽいな」みたいなことも考え、その場で逆提案していくのが重要。

いずれにしても「一旦持ち帰って検討します」はダメで、その場で、「対応するのかしないのか、する場合はいつまでに対応する見込みか」を伝えないと、顧客の期待値調整ができなくなると、他にもタスクは降ってくるので消化しきれなくなし、後からは忘れてしまう。

そういう観点では、PdMもある程度、UIUXに関する知識はもちろんのこと、サービスとプログラミングの知識があった方が、より早く開発チケットに落とし込むまでを判断でき、サービス全体の開発速度に繋がる。個人的には、開発スピードのボトルネックの相当部分は、PdMの段階でいかにその場で判断して開発可能なチケットレベルの優先順位に落とし込めるかにかかっていると考えている。よくサービス開発スピードとなると、開発人数に焦点を当てられがちだが。。。

顧客の期待値調整をどうするか？

とはいえ、もし仮に、プロダクトチームで幹となるKPIを持っていないもしくは、PdMの中で現在明確にこれを最優先でやるべきことが決まっていない場合の、顧客からの要望に対してどのように判断するか？

一つの解決策としては、顧客と開発チームを全員同じグループに入れて、そこで一つ「改善要望」というチャネルを作成し、顧客からの要望を、他の顧客にも開発メンバーにも可視化させるというのがある。

これは実際に、私が創業したメルプで行ったことで、それまでは、私に対してお客さんから機能の不具合や改善要望のメールが届いていたが、これだと下記のボトルネックが出てくる。

顧客からすると、開発要望に関する窓口・連絡先がPdM1人になるので、PdMからのレスがないと（忙しくて往々にしてレスが滞ることも出てくる）、「自分の要望がいつまで経っても叶えられない」と不満が溜まりがち
顧客は自分の抱えている不満が一番重要だと思っており、他の顧客からの別の改善要望は分からない
PdM1人に顧客要望が集約され、PdMが逼迫する

というわけで、途中から「だったら、お客さんも全員入れてしまって、開発要望チャネルを作って可視化しよう」と思い、Slackに全員招待して、下記のようなチャネルを作成した。

Discordなどでよくあるが、自己紹介チャネルや、サービスの情報共有、リリース予定の機能などに追加して「開発要望」チャネルを作成し、ここに開発チームも全員招待した。

このようにすることで、下記3点のメリットが生まれた。

開発の優先順位を可視化できる

自分がSlackのチャネルであげる開発要望に対して、他の人もぜひこれは対応してほしいと思ったものは、投稿に対して「いいね」を押すので、いいねの数で開発の優先順位を客観的に判断できるし、それを開発メンバーも分かるので、顧客にも開発メンバーにも納得感が得られやすい。
多くの顧客からの要望は、小枝からより大きな枝に格上げしていくイメージ。幹にまでなるかどうかは、あくまでプロダクトとして追っているKPIに合致しているかどうかで判断する。

顧客の期待値調整をできる

メールや電話でPdMと1:1でのやり取りだと、他の顧客からの要望も見えないのと、開発が複数のタスクをもとに優先順位つけて取り組んでいて、今すぐは対応できない場合があることを構造的に顧客は理解しづらい→いつ対応してもらえるか不安になり不満に繋がる。
Slackでグループ化したことで、自分からの要望以外にも数多くの要望が上がっており、自分のあげた要望の優先順位も可視化されるし、多くの要望に対して開発対応を順次していることが可視化されるので、不安が減る。

PdMボトルネックがなくなる

それまでは、サービス開発において、PdMが顧客と開発チームをつなぐハブであり、良くも悪くも単一障害点になっており、PdMがどんどん忙しくなっていたが、開発メンバーもグループに入れて、顧客と開発メンバーで直接やりとりをしてもらうことで、PdMが楽になりかつ、開発メンバーも顧客の生の声が分かるのでモチベーション向上にも繋がる。