こんにちは、マネーフォワードケッサイでPdMをやっている近江です。
今回はプロダクトマネジメントをPdMだけでなく、”チームで”取り組んでいくために、直近取り組んだ動きをまとめたいと思い書いています。
「プロダクトマネージャー」がいることで起きる“良くない分業”
1年ほど前まで、2023年10月に施行されるインボイス制度への対応に私達は追われていました…（請求業務に関わるプロダクトの皆さん、お疲れ様でした）
私は開発メンバーを開発業務に集中させたいという思いもあり、他部署との連携やユーザーと関わる機会のほとんどをPdMの私のみで行うという、いわゆる分業のかたちで進めていました。
このやり方は一見効率が良さそうに思える一方で、
- PdMだけが情報を持ち、プロダクトのことを考えないチームが出来上がってしまう
- 開発メンバー視点で、どう意思決定されてやることになったのか見えなくなる
- PdMが色々上流工程を整理してしまい、開発メンバーの意見が反映されづらくなる
といったことが起きてしまうと思います。
実際に「上流の決定の過程が見えづらく、設計時になぜこれが必要かわからなくなる時がある」、「エンジニアがもっと最初の段階から参加できていれば、開発目線を活かした他のアイディアが出た可能性もあるのでは」というフィードバックもありました。
分業がはまるケースもあると思いますが、より良いプロダクトを作っていくにはPdMだけでなくチームで考えていける方が強いと思いますし、弊社の開発メンバーはプロダクトへの意識が高いため、よくない状態になっていると思っていました。
そんな事を思っている中、この記事を読みました。
プロダクトマネージャーが出てきたがゆえに始まった“良くない分業” 「プロダクトマネジメントの根本」から考える、理想的なかたち
この記事ではプロダクトマネージャーというポジションが出てきたがゆえに、本来交わるべきチームが交わらなくなってしまい”良くない分業”が生まれていると書かれており、まさに私が陥っている状況でした。
特に以下の図が自分の状況と重なり、うまく言語化できずふわっと感じていたことから明確な課題意識に切り替わって、プロダクトマネジメントはチーム全員でやっていくべきと強く思うようになりました。
(https://logmi.jp/tech/articles/329057 より引用)
プロダクトマネジメントチームになるために取り組んだ4つのこと
ここからは私がプロダクトマネジメントをチームで考えていけるように取り組んだことを紹介します。
ちなみにマネーフォワードケッサイの開発チームは1チーム数人のスモールチームなので、そんな規模感をイメージして読んでもらえればと思います。
ロードマップ決定の場に招待
ロードマップに含めるマイルストーンには、「放置すると障害に繋がるレベルの課題への対応」や「既存ユーザーの解約に繋がるようなペインへの対応」、「新規ユーザーを狙う開発」などが混ざっていると思います。
障害や解約への対応についてはどう見てもやるべきというのも多く、みんな腹落ちしやすいですが、「新規ユーザーを狙う開発」については複数の案の中でAよりBのがいいと思う人、BよりAのがいいと思う人、意見が分かれやすくコミュニケーションや意思決定を疎かにすると腹落ち感なく対応する人が出てきてしまうと思います。 なので特にこの「新規ユーザーを狙う開発」について、開発メンバー+営業チームを集めて決めるようにしました。
実際にやってみた1度目、「どういう背景で決定しているのか見えてとても勉強になった」と開発メンバーからもフィードバックがありました。ありがたい声をもらった一方で、私の前提共有が不足していたためにあまり開発メンバーが議論に参加できていなかったことを反省点として感じていました。
数カ月後の2度目、今度は事前に情報を共有した上で、「今回は自分だったらどの案がいいか決めてMTGに望んで見てください」と先に伝えてMTGをしました。 実際その時は2案あり、試しに票を取ってみると6:4くらいで割れたのですが、その後営業・開発メンバー参加者全員から意見が出て、議論に参加した上で、最後は1つに決めることができました。
ロードマップをPdMが自信を持つことはもちろんですが、それを実現する開発メンバーも「自分で決めた」と思える状態作りは重要だと思うので、この決め方は継続したいと思っています。
重要指標ウォッチ
「PdMの役割はプロダクトマネジメントトライアングル全体を健全に機能させることだ」、とよく言われますが、私も全体を意識できるように毎月月初に営業、マーケティング、カスタマーサクセス、カスタマーサポート、審査、オペレーション、システムの特に重要な指標をウォッチしています。
このウォッチした結果のサマリーを開発メンバーにも毎月共有するようにし、自チームの課題だけでなくプロダクト全体に意識が向くよう取り組んでみました。
これにより今どこにボトルネックがあるか、どこがうまくいっているか、実は今自分がやっている開発よりあの部署の問題を解決する方が優先なのでは、のように視野を広げることができ、例えばロードマップにいきなり機能開発ではなく◯◯部署のボトルネック解決対応が入ることになっても、すぐに納得して取り組めるチームになれるのではと思っています。
ユーザーインタビューへの同席
エンジニアの場合、営業チームのようにユーザーと直接話す機会が少なく、機能要望をもらっても「なぜこの機能を求めているのか」「この機能だと満足しないのか」といった疑問が湧くシーンがよくあると思います。
そのため、ユーザーインタビューにエンジニアも同席、または自分で直接インタビューしてみるという機会を作り、しっかりとユーザーのペイン・運用を把握した上で設計できるように取り組んでみました。
これにより設計時の議論で、「この設計だとインタビューしたA社の運用には合わない」といった会話が、開発チーム内でできています。
運用を把握できていない場合どうなるかというと、営業チームに「この設計はA社の運用に合いますか？」というのを確認し、もし営業担当もわからなければA社に確認する、またはアポを取って確認するという流れになり、簡単に1週間動けないということもあると思います。
マーケイベントでプチ営業体験
これは私も経験がなかったのですが、1度参加してみて非常にいい体験だったので、その次のイベントでは開発メンバーにも参加を促して実際に参加してもらいました。
やることは自社ブース前を歩く方に声をかけ、立ち止まってくれたら名刺交換や簡単なサービス紹介をするという、1回数分の流れなのですが、これのいいところは「自分のプロダクトの何が初見の人に刺さるのか」というのがハッキリとわかることと、それを短く繰り返し体験できるということです。
営業の方なら普段からやっていることですが、開発メンバーではこういった機会がないので、プチ営業体験として非常にいいと思っています。
やってみると「ここを話す時が1番驚かれるな」、「デモだとここが1番刺さるな」といった本来のプロダクトの強みを、ユーザーの反応とともに記憶できます。
そしてマーケティングでリードを一本獲得することがどれだけ大変か理解できたり、明らかにリード獲得数が桁違いの営業メンバーを間近で見て、他部署へのリスペクトが強くなるきっかけにもなります。
まとめ
プロダクトマネジメントとしてカバーする範囲は非常に広いため、まずは第一歩ということでこういった取り組みをしてみました。
紹介したものは特にやってよかった、この動きは続けたい、と思っている取り組みになります。
プロダクトをより早く成長させていくために、最終的にはPdMだけでなくチームでプロダクトの今・将来のことを考えて、意見や新しいアイディアが飛び交うチームを目指せたらと思います。