作った機能をお客様に使ってもらうために必要なのは結局組織間連携の強化だった

こんにちは。ReproのProduct Planning Teamでプロダクト企画を担当している正木です。

今回は前回の記事の続きで、なぜGoToMarketの改善活動の効果がなかったのかの原因と、そこへの対策についてお話をしていきます。

tech.repro.io

結論から先に言うと、機能提供から利用開始されるまでのリードタイムが減り、活用度も上がるという結果になりました!

GoToMarket改善活動はなぜ効果がなかったのか?

大きく2つの理由がありました。

プロジェクト型組織構造によるナレッジの局所化

当時のReproの開発組織はプロジェクト制を取っており、何かの開発が決定すると都度プロジェクトが発足し、開発が終わると解散するという流れでした。

GoToMarket活動を行う前にプロジェクトチームが解散されてしまうことで、すべての機能のGoToMarketを担当するPMMだけにナレッジが蓄積され、PMMがGoToMarket活動のボトルネックとなっていたのでした。

以前の開発体制-プロジェクト制でナレッジが溜まりづらい状態

他部署との連携不足

CS(Customer Success)やSalesの方々から見るとGoToMarket活動はあくまで「Devがなんか勝手にやってくれてる活動」でしかありませんでした。

要件定義の段階でお客様はこの機能をどう使うのか、どういうマーケティング施策を打ちたいと思っているのかといった視点が欠けていたのです。

ゆえに、いくらリリースされる機能の理解をしても、お客様に説明したり使ってもらうためにCSが払うコストが大きく普段の業務を圧迫しており、提案しないほうが楽だと思われていたのです。

GoToMarket活動を担える開発体制に

2023年から「小さいチームで素早く作る」をコンセプトとし、開発組織はプロジェクト制を廃止しました。

また、ナレッジをチームに蓄積し機能開発に伴う各種判断を行いやすくするために、各チームの責務を明確にしたうえで、チーム毎にPdMを配置しました。

現在の開発体制 - 作るものと人を固定しチームにナレッジが溜まりやすい状態

これにより、PMMに一極集中していたGoToMarket活動が各機能開発チームの中で行える準備が整ったのです。

GoToMarketプロジェクトチームの組成

これまでの活動から、GoToMarket活動は機能開発チームだけでは実現が難しいことがわかっていました。

そこで、機能開発チームに対しGoToMarket活動を推進するCS、Marketingメンバーをアサインしてもらいました。

各チームやメンバーが担う責務と領域を明確に

GoToMarketプロジェクトチームが作られて何が変わった?

他部署との連携が強化された

Devと相対する他部署のメンバーが固定化されることで他部署との連携における阿吽の呼吸が生まれ、GoToMarket活動にまつわるコミュニケーションがスムーズにやり取りできるようになりました。

GoToMarketに関わる全ての部署において「これは誰に確認すればいいんだろう?」と考えることの地味なストレスから開放され、各々が自分で考えて行動できるようになり、機能の提供スピードが格段に上がりました。

小さく早く試すことができるようになった

CSとの連携が強化された結果、開発途中の機能に対するフィードバックが多く取り入れられるようになりました。

これまでは開発が考える必要最低限の価値とCSが考える必要最低限の価値が擦り合わないまま機能がリリースされ、CSのコスト増につながることも多かったのですが、すり合わせができている状態、つまりお客様にも使ってもらいやすい状態での必要最低限の価値提供ができるようになりました。

今後

今はとりあえず早く使ってもらうことを意識して取り組んでいますが、今後は顧客のフィードバック集めから機能の企画に落とし込むまでの全体をGoToMarketプロジェクトチームのメンバーに担ってほしいと思っています。(私は全体の取りまとめ役)

そのためには開発速度のスピードアップ、機能を小さく作ってどんどん出してフィードバックを得る機会を増やしていくことが大事だと思っています。

その状態を実現するために、人もたくさん必要なのでぜひ興味があればお気軽に話をしましょう。

herp.careers

おわり。