見出し画像

プロダクトロードマップの作り方ver2024

INDEX


はじめに

プロダクトロードマップの作り方に決まった手順とかないと思いますが、2024年現在において今までの経験から自分だったらこうする、という思いを文章にまとめてみようと思いました。
ですので、ここに書いてあるやり方が正しい、と言うことではありませんのであしからず。

本記事では、プロダクトの起案者が別におり、PdMとして途中からジョインするケースを想定しています。
起案者自身がPdMの場合は、プロダクト企画時に必要な資料をすでに作成していると思われるからです。

進め方の手順

先に進め方の手順についてまとめます。そのあと各手順について詳細書いていこうと思いますので、手順だけ知りたい方はこの章だけ見れば全体感がつかめると思います。

全体感つかんだあとに、気になるポイントを見ていく感じが良いかと思います。では、手順を以下に示します。

  1. その企業におけるプロダクトの位置づけを把握する

  2. 事業戦略に沿ったプロダクトビジョンを確認する。ない場合は作る。

    1. プロダクトビジョンが存在しない場合、事業推進者にプロダクト創出の経緯を聞く

    2. プロダクト創出経緯やエレベーターピッチ資料、ビジネスモデルキャンバスから、プロダクトが解決する課題と提供価値を整理する。

    3. 上記から、プロダクトのミッション・ビジョン・バリュー(MVV)を作成する。

      1. この辺の記事が参考になりそう。

  3. プロダクトMVVから直近数年で目指すべきプロダクトゴールを策定する。

  4. 現状と数年後のプロダクトゴールのギャップから、必要な価値提供の取り組みを洗い出す。

    1. その際、プロダクトのフィットジャーニーを意識して取り組みを整理すると良い。

  5. 事業戦略の優先順位と照らし合わせながら、価値提供の取り組みをタイムラインに沿って並べる→これがプロダクトロードマップとなる。このロードマップはプロダクトゴールに向かってMVVを実現するための開発計画であり、WBSとは異なる。

    1. 取り組みの依存関係があるものは、親タスクを先に配置し、子タスクと矢印でつなぐ。(この記事は参考になります

    2. 優先順位の観点として、「事業戦略上の重要事項>プロダクトコア価値(特に自社アセットを活用した競合差異)>ターゲットユーザーの課題解決>あると良い価値(UX改善など)>現時点で必須でない価値」という基準で策定している。

      1. 施策の優先順位をユーザーに問う方法として狩野分析法がある。

  6. プロダクトロードマップの直近部分を区切り、取り組み内容を詳細化する。

  7. 取り組みをオブジェクトごとに整理し、達成手段としてKRを設定する→四半期ごとのプロダクトOKRとなる。

1.企業におけるプロダクトの位置づけを把握する

企業におけるプロダクトの位置づけは、ロードマップのゴールを大きく左右します。
まずはじめに会社の事業ゴールを明確にし、そのゴールに対してプロダクトがどのような役割を果たすべきかを考える必要があります。

パターン1:収益の中心はコンサル主体でプロダクトはその補佐役

このパターンではSLGでエンプラ向けにサービスしているtoB SaaSのケースを想定しています。

  • コンサルを軸としたエンプラ企業への価値提供が事業戦略の中心。

  • プロダクトはコンサルの価値提供から定型化された部分を切り出した存在。

  • プロダクト単体では収益化が難しい状況。

このような場合のゴールとして、以下の2つの方向性が考えられます。
方向性1:プロダクト単体での価値提供と収益化を目指す
方向性2:コンサルの補助ツールとしての価値をさらに強化する

パターン2:プロダクト運営が収益の中心で、コンサルは一部顧客向けのプレミアムサービスである

こちらのパターンは、SMBに対してPLG戦略を行うtoB SaaSや、toC SaaSがメインのケースを想定しています。

  • プロダクトを中心としたSMBやtoC向けの価値提供が事業戦略の軸。

  • PLG戦略により、フリーミアムモデルで無料ユーザーを獲得し、魅力的な機能追加で有料化を促進。

  • toB SaaSの場合、一部のエンプラ企業にはアカウントマネージャーを配置し、SLGで導入コンサルを提供。

このケースでのプロダクトゴールは、以下の方向性から検討します。

方向性1:単一プロダクトでビジョンの実現を目指す
方向性2:機能単位で複数プロダクトに分け、それぞれでビジョンの実現を目指す(コンパウンドSaaS戦略)

2.事業戦略に沿ったプロダクトビジョンを確認する。ない場合は作る。

自分がプロダクトの起案者ではないため、このフェーズでは過去の情報収集に重点を置きます。プロダクトのフェーズごとに状況を整理し、PdMが取るべきアクションを以下にまとめます。

新規事業のプロダクトは0→1フェーズ、1→10フェーズ、10→100フェーズと事業拡大のフェーズごとに区分して語られることが多いです。ここでもこの区分を使いましょう。

0→1フェーズのプロダクトの場合

0→1フェーズでは、担当者が社内に在籍している可能性が高いため、直接ヒアリングを行いましょう(退職している場合は、チームメンバーへのヒアリングやドキュメントでキャッチアップします)。

このフェーズでは、PoCやPMFの検証中であることが多いです。マーケットに対する価値検証の仮説を把握することが最優先です。また、プロダクト誕生の経緯も重要です。社内の新規事業コンペから生まれたのか、経営層のアイデアからトップダウンで始まったのか、撤退基準は設定されているのかなど、背景を理解しましょう。

このフェーズでは、PMF仮説の検証軸がそのままビジョン設計の中心となります。

1→10フェーズのプロダクトの場合

1→10フェーズでは、プロダクトの初期ビジョンの確認が必要です。この段階では起案者が退職している可能性が高いため、残されたドキュメントの確認と初期メンバーへのヒアリングが中心となります。

このフェーズでは、PMFを達成してGTMに向かう段階にあります。ただし、PMF達成前に販売を開始しているケースもあります。前者は健全、後者は不健全な状態です。

不健全な場合でも、クライアントからのネガティブフィードバックを活用し、PMFに向けた方向性を見出す必要があります。これらの知見がビジョン設計の軸となります。

健全な場合は、PMFをさらに強化する価値の特定がビジョン設計の中心となります。

10→100フェーズのプロダクトの場合

10→100フェーズのプロダクトは、多くの場合立ち上げから5年以上経過しており、初期メンバーはほとんど残っていません。この段階では初期のプロダクトビジョンが形骸化し、適切に運用されていないことが多いです。また、初期とは異なるニーズにフォーカスしたり、市場ニーズを十分に満たしているプロダクトもあります。

このフェーズで最も避けるべき状態は、目先のKPI達成のみを追求する運営です。多くの場合、そのKPIはKGIを単に分解しただけのものです。

この状態で事業を進めると、事業ニーズだけに焦点を当てた機能開発が進み、ユーザー価値を損なうことが多くなります。ユーザビリティ改善で対処しようとしても、本質的な価値提供としては不十分です。

結果として、ユーザーの離脱が進みサービスが終了する事態に陥ります。短期的な売上にフォーカスして失敗するプロダクトは数多くあります。
このような失敗を避け、10→100フェーズを成功させるには、プロダクトビジョンの再構築が極めて重要です。

では、具体的に何をすべきでしょうか?

私は「考古学」と呼んでいる作業から始めます。長期在籍している社員から事業の歴史を学び、過去のドキュメントを丁寧に調査していきます。

過去の経緯を理解したら、現在の事業戦略を確認します。売上が低下している場合、以前はフィットしていたPMFが市場ニーズの変化により適合しなくなっている可能性があります。その原因について仮説を立て、新しいプロダクトビジョンの軸としましょう。

プロダクトチームでブレインストーミングしてビジョンを再構築しようとするケースがありますが、そこには本質的な答えはありません。チーム作りの観点では有効ですが、まずはそのフェーズのプロダクトが解決すべき課題を明確にすることが先決です。

この方向性の誤りは長期的な影響を及ぼします。プロダクトが解くべき課題設定を慎重に行うことが極めて重要で、経営企画部門と連携して進めることをお勧めします。

新たなPMFに向けた仮説が設定できたら、NSMの設計に移ります。KGIに直結したKPIの追求は避け(モニタリングは継続)、NSMを軸に施策の効果を評価しましょう。

3.プロダクトMVVから直近数年で目指すべきプロダクトゴールを策定する。

2でプロダクトのMVVについて理解は深まりましたか?プロダクト開発の背景、解決すべき課題と提供価値、初期リリースで検証したい仮説など、重要なポイントを押さえられたでしょうか?

ここではそれらの観点を元にプロダクトゴールを策定していきます。

プロダクトゴールの設定方法は、現在の進捗状況によって異なります。以下の3つのケースに分けて考えてみましょう。

  1. 立ち上げ期のプランが未実装、もしくは一部実装だが残タスクが多い状態

  2. 当初のプランがPMFせず、ピボット後にPMFを達成したものの、今後の価値提供の方向性が不明確な状態

  3. 立ち上げ期のプランをほぼ実装完了し、市場シェアを確保、現在は細かな改善を進めている状態

それぞれの状況に応じた適切なアプローチを見ていきましょう。

近未来の状況をイメージしたゴール設定

1と2の状況では、バックキャスティングアプローチが効果的です。これは、近未来の理想的な状態からゴールを設定する方法です。

3〜5年後のマーケットにおいて、プロダクトがどのような成果を上げ、どのようなポジションを確立しているかを具体的に描きましょう。
このアプローチには未来志向の思考が不可欠です。

まず、プロダクトの業務ドメインで既に予定されている変化や展開を整理します。未来年表は、この作業の強力なツールとなります。

toC SaaSの場合、生活者の動向予測は困難ですが、避けては通れません。過去から現在までのトレンドを分析し、将来ニーズを予測しましょう。ただし、文化差があるため海外事例の参考価値は限定的です。

一方、toB SaaSでは、先行する海外の動向が有用な指針となります。例えば金融DXなど、海外が先行している分野では、その状況から日本の将来像を予測できます。

将来像が明確になったら、その世界でプロダクトが目指すポジションを具体化し、それをプロダクトゴールとして設定します。
この策定プロセスは、経営企画部門と協働で進めることを推奨します。

現状の積み上げでたどり着くゴール設定

3の状況では、現状の維持・強化を重視したフォアキャスティングアプローチが適しています。
あるいは、既存事業の価値を更に高める新規プロダクトの立ち上げを検討すべき時期かもしれません。

4.現状と数年後のプロダクトゴールのギャップから、必要な価値提供の取り組みを洗い出す。

バックキャスティングの場合、3で描いたプロダクトゴールから逆算し、現状と未来のギャップから不足している価値のリストを作成します。
フォアキャスティングの場合は、現状から積み上げていくべきタスクを洗い出してリスト化します。

リストを作成する際は、取り組み間の依存関係を可視化しておくと、後工程がスムーズになります。

「実装すべき価値」を検討する際の重要な視点は、その価値がターゲットユーザーにとって真に必要とされているかを見極めることです。

この判断が、プロダクトを「あれば便利」なNice to Haveの段階にとどめるか、「なくてはならない」Must Haveへと発展させるかの分岐点となります。

プロダクトアウト・アプローチで仮説を立て、価値検証を行う

ゴールギャップから見出した不足している価値について、その効果を仮説として立て、紙芝居レベルのプロトタイプをターゲットユーザーに見せて反応を確認するアプローチです。

このアプローチは、ホリゾンタルSaaSのように対象ユーザーが広く、最大公約数的な価値の把握が困難なプロダクトに有効です。

アルファ版を一部のユーザーに提供して反応を見ることもありますが、プロダクトアウトであっても開発工数は使うべきではないというのが私のポリシーです。
なぜなら、仮説が間違っている可能性があり、開発してしまうとそれを捨てることになるからです。開発せずにその価値がユーザーにとって本当に必要なものかを検証することが重要です。

マーケットイン・アプローチで解決すべき課題から価値を考える

こちらは、ターゲットユーザーの課題解像度を徐々に上げながら、真に必要な価値を探索する手法です。

狩野分析法などを使い、ユーザーが本当に解決したい課題を洗い出してから、その解決策を考えるアプローチです。

このアプローチは、エンタープライズ向けのtoB SaaSに適しています。特に、ターゲットユーザーに対してバーティカルSaaSで価値提供する場合に有効です。

5.事業戦略等の優先順位と照らし合わせながら、価値提供の取り組みをタイムラインに沿って配置する

タイムラインにおける施策のマッピングは、以下の2つの要素で前後関係を定義します。

  • フィットジャーニーにおける順番

    • SPF中にやるべきタスク

    • PMF中にやるべきタスク

    • GTMになってやるべきタスク

  • タスク同士の依存関係・親子関係における順番

フィットジャーにについてはこちらのサイトでまとまっています。

これらの観点でタスクを時間軸に並べていきます。依存関係がある場合は、タスク同士を矢印で接続します。
ツールは何でもいいですけど、自分はFigjamで最近作ることが多いです。miroは動作が重すぎるんですよね。

ここまでで、プロダクトロードマップのドラフトが完成します🎉。

ただし、事業戦略とロードマップ・ドラフトにずれが生じている可能性があります、このタイミングで事業責任者とすりあわせしましょう。

事業戦略をそのまま実行すると、事業都合が優先されすぎてユーザーに受け入れられない可能性があります。そのため、以下の手順で調整を行います:

1.事業戦略のタイムラインと事業拡大規模を把握する
2.その取り組みをユーザー価値に変換し、プロダクト価値向上が事業戦略に寄与する形を作る(ここがめっちゃ重要)
3.2に沿ったタスクを見つけ、必要な場合は補完する

優先順位については、以下の順で整理します:
事業戦略上の重要事項>プロダクトコア価値(特に自社アセットを活用した競合差異)>ターゲットユーザーの課題解決>あると良い価値(UX改善など)>現時点で必須でない価値

優先度の低い項目はプロダクトバックログのみで管理し、ロードマップには記載しなくても構いません。
優先度高の項目は太字や強調色で一目で分かるようにしましょう。

6.プロダクトロードマップの直近部分を区切り、取り組み内容を具体化する

ここからはプロダクトOKRの作成に移ります。以下のサイトでさまざまなOKRについてまとまっていますが、ここで言われているプロダクトレベルOKRのことです。

ロードマップ上の直近の施策がObjectiveとなり、それを達成するための具体的なアプローチがKRとなります。

KRを設定する際は、プロダクトバックログにある進行中のチケットも参考にしてください。

ロードマップに含まれていない進行中のチケットについては、保留にする可能性も考慮して整理を行います。

7.KRをObjectiveごとに整理し、プロダクトOKRが完成

これらを整理し、四半期ごとの達成目標を設定して運用を開始します。

ただし、重要な注意点として、OKRは営業目標ではないので、達成度による評価は避けるべきです。評価指標として使用すると、チームは挑戦的な目標を避け、確実に達成できる控えめな目標だけを設定するようになってしまいます。

OKRはプロダクトの進化の方向性について、チーム全体で認識を合わせるためのツールです。それ以上でも以下でもありません。この本質を理解し、適切な運用を心がけてください。

終わりに

以上が2024年時点での自分のプロダクトロードマップに対する考え方や作り方のまとめになります。

来年もいろんなことが起きてこの内容がアップデートされていくんだろうなとも思いますので、ここに書いてあることが答えではないと重ねて書いておきます。

2025年に向けた抱負としては、BizDev側の知識をもっと吸収して、事業拡大しながらプロダクト価値を持続でき、ユーザーのペインが解消する「三方よし」なビジネスを構築できるようになりたいな、と言うところです。MBAとか別にいらないですが、プロダクトとビジネスが相反しない世界を作るにはどうすればいいか?というテーマで知見を深めていきたいと思っています。

こういう本がオススメ!などありましたら是非教えてください!!では、良いお年を!!

いいなと思ったら応援しよう!