入社して半年間ロードマップを回してわかったこと
こんにちは、gifteeのプロダクトマネージャーの渡邊です！
gifteeでは上期、下期と半年間ずつ事業の予実評価を行っています。
私は去年の8月ごろ（2023年の下期）入社し、最初の方はプロダクトや組織についてのキャッチアップや、所属する海外事業部の課題のあれこれについて取り組んでいました。
そして今年に入り、今月末で2024年の上期がもうすぐ終わろうとしています。そんな中で実際にプロダクト開発において、この半年間のロードマップについて振り返ってみたいと思います。
結論
お忙しい方もいると思うので、最初から結論ですが、プロダクト開発におけるロードマップで気づいたポイントは
機能ありきのロードマップはやっぱりうまくいかない
チーム内に発言力が強い人がいる場合、その意見に依存する
一次情報がない場合、間違った開発をしてしまう
読んでいる方の中には、当たり前に感じる方も多くいらっしゃると思いますが、これらのポイントは結構根が深く、一度回すことで改めて実感できることが多くありました。
それぞれについて、深ぼってみます。
機能ありきのロードマップはやっぱりうまくいかない
私の所属する海外事業部では、日本での提供サービスを一部タイムマシンする形で、東南アジアを中心にローンチしました。
ところが、タイムマシンの時期を誤ると、その市場には、すでに市場を独占している先行プレイヤーがおり、どれだけ頑張っても、先行プレイヤーを追いかけ続ける構図になってしまいます。
こんな時のプロダクト開発はどうしたらいいんでしょう。
よりリッチで使いやすいプロダクトを先行プレイヤーよりも早く提供する？
先行プレイヤーよりも価格を落として、彼らの抱えるクライアントをリプレイスしていく？
チーム内で協議し、この先行プレイヤーを追いかける構図を変えるために少しでも彼らに打撃を与えたい。
私たちは上記の2点をそれぞれのチーム（ビジネスサイド、プロダクトサイド）で分担しやることにしました。
プロダクトチームのミッションは、競合が提供している機能をいち早く作りリリースし、機能価値の差分を埋め、クライアントのリプレイスを図る上で、機能が失注の要因にならないようにすることを目指しました。
事実クライアントから「この機能がないと困る」ということでなかなか受注につながらないということがよくありました。
ただ、今振り返ると、この戦略は明確に「失敗だった」と言えます。
なぜかというと、結構シンプルで、顧客はサービスの全体体験が重要であり、機能はその一要因でしかないからです。
私たちが定めたプロダクトロードマップは競合が提供している機能と同じようなものをなるべく早くつくるというものでした。そしてたくさんの機能をリリースしました。たくさんの機能開発で、開発チームとビジネスサイドが衝突することもありました。
その後、リリースしてみると、特段の変化はなし。
リリース後に数ヶ月が経過しても、特段の変化はなし。
先ほど失敗だったと書きましたが、失敗 = 開発コストに対する効果、つまりROIが全く合わないという状態でした。
この状況では開発チームからも「何で売れもしない機能をつくったんだ」と言われても仕方ありません。
ここでの反省ポイントは、BtoBのモデルのプロダクトを開発する場合、顧客は必ずと言っていいほど要望を口にします。
その要望は機能であることが多いです。
しかし、実際その機能を提供しても、受注や顧客とのリテンションにつながるかと言われると怪しいことも多いです。
クライアントの口にする要望を、しっかりと因数分解した上で機能だけではなく、サービス全体でどのような体験を求めているかリサーチするべきだと思いました。
それは例えば、細かい日々のメールの対応や、ミーティングでの親切さ、カスタマーサポート、プロダクトを利用する際のわかりやすさ、などなど多岐に渡ります。
機能ありきのロードマップは、事実、機能はたくさんつくることができます。ただし、ROIが重要な観点となる組織。つまり予算が限られているチームや、スタートアップにおいては、顧客価値につながらない機能開発は命取りです。
予算を垂れ流しにしないために、ROIがその開発によってどの程度見込めるか、一次情報をなるべく集め、チームで吟味した上でロードマップを決めていく必要があると感じました。
チーム内に発言力が強い人がいる場合、その意見に依存する
先ほど、チームで吟味した上でロードマップを決めていく必要があると書きましたが、重要な前提条件があります。
それは関係するチームメンバーが全員同じ解像度で、対等に意見し、認識ずれが全く起きていいないという条件です。
ここも一見シンプルですが、やっぱり働いているのは人であり、スムーズにいかないこともあります。
私たちの場合だと、特定の国での競争が激しかったことが背景にあり、その国の業績上、プロダクト開発の優先度を上げていました。その国のチームではこれまで数年にわたってサービス提供をしてきたこともあり、マーケットの解像度においては当然そのチームが圧倒的に高いです。
そのため、じゃあプロダクト戦略をどうしようかとなった時に、マーケットの解像度を高く持っているチームの意見は当然強くなります。それ自体は問題ないですが、解像度が低いメンバーが意思決定に参加している場合、そのチームの意見に従うしかないという状況が問題でした。
解像度が低いメンバーがいても、別の分野においては専門性を持っていたりもします。このチームはとても強い意見を押しているが、この観点では本当に大丈夫か？懸念がありそう…など実は内に意見を秘めていたりします。
あるべき論は、ここでみんなが解像度を同じレベルに持ち、懸念事項を潰すことですが、冒頭に戻ると、一緒に働いているのは人同士。言いずらさや遠慮、論破されるなどが発生し、コミュニケーショントラブルが起きてきます。
こうなってしまうと、その発言力の強いチームやメンバーに従う形で、開発も始まってしまいます。
しかし、プロダクト開発において、こういったチーム内のコミュニケーションのエラーは、やはり命取りです。
チーム内に解像度が高いメンバーがいる場合、発言力が強くなる傾向はどうしてもありますが、それも仮説に過ぎません。チーム全員がその仮説に納得感を持ち合意できなければ、そもそも意思決定における議論の土台すら立てていないと言えるかもしれません。
急がば回れ。
議論する前に、意思決定する前に、必要な情報を収集し、意思決定参加者全員が同じ目線に立つ。
これが、実は最も効率的に意思決定をしていくことなのかもしれないなと思いました。
一次情報がない場合、間違った開発をしてしまう
これまで書いてきたことのまとめになりますが、課題において共通していることはやはり「情報の不足」です。
何らかのサービスを顧客に提供する場合、一番の窓口になるのは営業チームやマーケティング、カスタマーサポートチームなどです。
この構造上、どうしてもそれらのチーム→プロダクトチームという情報の受け渡しの力学が組織内で発生しがちになります。
痛感しました。この力学は大変、意思決定をする上で危険です。
組織規模が比較的大きい場合は、責任範囲というものがチーム単位で発生してきます。当然プロダクトチームは開発チームと連携し、機能や新規プロダクト開発に取り組むことがメインの責任範囲になってきます。
組織によっては、プロダクトチームが一次情報を取得する上で、営業チームやマーケティングチームにヒアリングするということに、ビジネスサイドが抵抗感を示すケースもなくはないと思います。
そうだとしても、プロダクトの責任と予算管理をすること、そして良い価値を効率的に届けることはプロダクトチームのミッションです。
一次情報はもう取りに行くしかない。と思いました。
一次情報を取りに行くことに不安を感じる必要はないのかもしれません。不安になることとしては、例えば他のチームから何でそんなこと知りたいの？感を出されること、または他のチームから顧客と向き合っていないのにわかるの？などが考えられます。
私はカミナシにいた頃に、実際リサーチは誰でもできること、そしてデスクリサーチでかなりのレベルまで解像度を上げられることを学びました。
日々足元で動く開発アイテムと向き合いながら、どのくらいの温度感や期待値でリサーチをしていくか迷うところですが、リソース意識を持ったりタスクとして取り組むというよりも、好奇心や興味関心をベースにチーム文化としてゆるく長く確実に取り組むことが重要なのかもしれません。
私のこのあと半年のミッションは、リサーチをプロダクトチームが定常的に行なっている習慣をつくり、一次情報が体系的・構造的に一元化されている状態をつくることです。（ガンバル）
ではでは👋