見出し画像

【UX/PdM】PdM時代に私がやったプロダクトロードマップ作り方

せら🎨UX/UIデザイナー

私は中国と日本をつなぐ越境ECプラットフォーム(B2B2C)でプロダクトマネージャー（以下PdM）として働いていました。

今回はPdMになって割と早い段階で求められるアウトプットの一つである

プロダクトロードマップについて

振り返りも兼ねてここに書き記します。

※コンプラ的にサービスの細かい話しは省いています。

そもそもロードマップとは

ロードマップとはただの機能リストと思われがちですが、そんな単純なものではありません。

プロダクトマネージャーの視点から話すとコミュニケーションツールとして活用するという事が本来正しく、そこには、ビジネスの戦略とプロダクトの戦略が見える状態にすることが目標です。

さらに、プロダクトマネージャー一人で作るのではなく、ステークホルダーを巻き込んでしっかり作るプロセスが大事だと思います。
そうする事で後々出てくるであろう問題に事前に気づく事もできますし、みんなで納得した上で機能開発に進むことができます。
何がどのようになってどう決まったからこの順番なのか、コンテキストをしっかりステークホルダーと議論した上で進めないと、プライオリティーの決め方が雑になってしまい、ビジョンを正しく遂行でないなんてことになります…

私は初めてロードマップを作成した際、一人でちゃちゃっと作ってしまい考慮もれも多く、双方向からダメ出しが来てしまい大失敗しました…

ビジョン実現のために必要な認識

プロダクトビジョン実現に向けてロードマップを作成するにあたり、各ステークホルダーと話していて、どのようにユーザーへの価値提供が進化していくのかという視点が抜けていると気がつきました。

実際に使用した図

ただ良いものを作れば売れるというわけではないこの時代に、考えなければならないのは、ビジネスにプラスの影響を及ぼす顧客の行動変容。つまり起こしたいインパクトや達成したいビジョン。どうすれば顧客はもっと行動変容してくれるのか？から逆算しメンバー内で議論し決定していきました。

行う施策の判断基準と妥当性

あらかた見えたところで、施策何やるねん。ってなるかと思うのですが、施策はアウトカム実現に向けてユーザーにとって一番良いアウトプットは何かを考え優先付けします。

私の現場でよく起こったのは、営業と経営層の圧力が強く、ビジョンの実現からブレてしまう内容でした。
「これやりたいってお客さんが言ってるので！」というやつです。
B2Bではよくあると上司が言ってました。笑

営業の圧が強く心が折れそうになりましたが、プロダクトマネージャーとして、ビジョン実現のためにリクエストをロードマップに絡められないか前向きに議論し、反映して行けるものはして、できないものはNoと断る。

私は一度、何でもかんでもぶち込んでこようとする営業にムカついて言い合いになってしまいました…営業は営業でKPIがあり、担当のお客さんのことを考えています。それぞれのステークホルダーのKPIや本当に気にしていることに気を配れるとベストです。

どんな時も広い心と傾聴力が大事…!⇦超大事です！人の話しちゃんと聞けない人の話しなんて誰も聞いてくれませんから。


ICE法を活用し説得力のあるロードマップを作る

以下使用したフレームワーク。

  • Weighted Shortest Job First(WSJF)

  • ICE

ロードマップ作成時にいくつか使えるフレームワークはあり、最初はWSJF法を使用しましたがICE法を知り、施策に対してどの程度自信があるかどうかを数値で示すことができ、より納得感のあるものを作れることからICE法へ変更しました。

ドキュメント作成

PlanDocを作成し、ビジネスの戦略とプロダクトの施策がどう議論されどう決まったのか。1つのPlanの始まりから開発後の計測までを記録するドキュメントを作成しました。最初はなんとなく作成していたのですが、私だけに属人化してしまい、主体的に行動できる人がおらずタスク過多になっていた頃、復業でお世話になっていたデザインコンサルティングファームで使用しており、早速チームで実践しました。

ドキュメントの情報は以下です。

  • 解決したい課題

  • ゴール計測方法

  • 基本方針・制約

  • ユースケース(SVO情報)

  • 現状診断

  • アイデア・ワイヤー

  • 開発側からの意見/見積もり

  • 最終アウトプット

※補足：MVPリリース後はアジャイル開発で進めました。
アジャイル開発の良いところは、みんなで施策を試し失敗や成功をチーム内で蓄積し学びにできる点です。PdMが基本的に決定をしますが、過程が共有されていないと他責のメンバーや全ての責任がPdMにのしかかるような構図になってしまうので密に共有し、チームを巻き込むと精神的に楽になれますし、新しい角度の意見をもらえるきっかけになります。

プレイヤー上がりの私は抱え込む癖があるのですが、大事なのはプロジェクトの成功なので一人で抱えれば良いというものではありません…
周りをしっかり巻き込んでチームで作るという点を意識すると自責のメンバーも増え円滑に進むようになりました。

SSCでロードマップをレビューする

ロードマップは市場の動向とプロダクトの成熟度合いによって振り返りを行う期間はそれぞれ違うと思いますが、私の現場ではSSCで毎月メンバーと一月末に振り返りを行い、ずれの調整を行いました。

  • start　新しく始めるのか

  • stop　やめるのか

  • continue　そのまま続けるのか

変更する場合、リソースが限られているので予算も大幅に動かせるほどなかった為、どの程度変更するのか以下3つの基準を設けて取り組みました。

  1. 今あるロードマップアイテムを少しずつ変更する

  2. 今あるロードマップアイテムを新しいものにする

  3. 今あるロードマップアイテムに載っていない新しいものを始める

初めは基準を設けておらずスコープが無限に発散されており、反発もありましたが、この基準を設けたことで開発側からの不満も少し抑えられたと思います。

※PJとは別で、自身の振り返りもおすすめです！
振り返る癖がつく似たような失敗が起こりにくくなります。

最後に


ロードマップ作成はちゃんと作ると結構時間がかかります。
いかにステークホルダーを巻き込んだコミュニケーションができるかという点と、意見が割れることがたまに起こるので、最終判断はPdMが総合的に判断するために状況をしっかり理解しそれを数値などの具体的な根拠で持っておくことが大事だと思っています！

最後まで読んでくれてありがとうございました。
良いプロダクトを作っていけるよう精進してまいります！

この記事が気に入ったらサポートをしてみませんか？