見出し画像

チームを動かすプロダクトロードマップの描き方(前編)

もう2020年も師走ですね。
今回のアドベントカレンダーは、2020年の中でもに大きな変化にチャレンジした「プロダクトロードマップづくり」を振り返ろうと思います。
この記事はユアマイスター Advent Calendar 2020 6日目の記事です。

すでにPMとしてご活躍されている方にとっては当たり前の事ばかりかもしれません。ただ、私にとってはその当たり前を作っていくことの難しさや壁にぶつかってきたのでこの機会にしっかりと残しておこうと思います。

はじめに

私がユアマイスターに入ってから2年半、がむしゃらにプロダクトの改善を重ねて走ってきました。
毎月改善テーマを持ち、カテゴリーや機能別のPJでプロダクト改善を行ってきたのですが、2019年夏頃から、毎月を走り抜けるという短距離走の連続に疑問を持ち始めました。

そこで、勉強会に参加したり本を読み見よう見まねで作るも、そのロードマップは、この半年で作れそうなものを積み上げ式で単純にリストアップしたもの。しかも、戦略ではなく小粒の月単位での目標ベースでの積み上げでした。
当時ロードマップを作るために合宿することもあったのですが、1~3年後の構想はなく、3ヶ月たつとそろそろ考えなきゃ、、という自転車操業のようなロードマップでした。

▼Figmaで毎週のように更新し続けていたロードマップの抜粋
(各施策の分類ごとにボックスを色分けして、責任者の顔写真をつけていました。今改めて見るとツッコミどころありすぎる。)

ロードマップ

他社PMさんにもご相談する中で見えてきたのは「3年くらいの戦略を考えて、そこから逆算して作る」必要があること。
ただ、頭では理解できても、どこから手をつけ始めればいいかわからずに悩んでいるまま時が過ぎていました…
そんなロードマップの転機は2020年の9月にやってきました。

目次

2020年9月から、技術顧問でもありアドバイザーの明石さんにプロダクト部の戦略作りのテコ入れにお力添えをいただきました。
その際にやってきたことを順を追い、学びとともに軌跡を残していこうと思います。
長くなりそうなので今回は⓪〜④まで。次回の後編で⑤〜⑧をまとめていきます!

⓪そもそもプロダクトロードマップとは
①現状の課題の洗い出し
②あるべき姿のコンセプト化
③あるべき姿から導く2つの軸
④あるべき姿から逆算した機能の洗い出し
⑤価値のある機能にするためのランク付け
⑥価値ある機能を、あるべき時に実現するためのアサイン
⑦運用にむけたMTGやPDCAの設計
⑧運用開始!
その後~運用開始後に躓いたこと~

⓪そもそもプロダクトロードマップとは

まず、ロードマップのあり方としての捉え方の前提を残しておきます。
ロードマップとはプロダクトの戦略や方向性、優先順位、進捗の概要を経時的に示すために共有する行動計画のこと。

あくまでも目的や戦略を実現するためのツールであり、それらの前提が揺らいだまま作ってしまっていたことがこれまでのロードマップづくりにおける一番の課題点であり、反省点でした。

特にご指摘をいただいたのは以下の3点。(耳が痛い..)
- 今は提案されてきた案件の優先度で判断している案件計画リストでしかない
- プロダクト成長が会社の成長に繋がることを示せていない
- 今月やりきるという短期的な改善で、中長期的な資産になっていない

そもそもプロダクトロードマップは手段であり、目的ではない。目的となる戦略づくりが今回の活動における肝となりました。

①現在の課題の洗い出し

今回はプロダクト部部長星さんとエンジニアチームリーダー増井さん、稲垣(ディレクションチームリーダー)+アドバイザー明石さんというメンバーでスタート。

まずは今起きていることを客観的に捉えるべく、現状を掘り起こしました。
最初は部長の頭の中をホワイトボードに書き出してみたのですが、プロダクトづくりだけでなく、組織や技術などプロダクト部としての課題は多岐に広がっていました。

▼課題となる項目をマッピングした図

2020-08-27_明石さんMTGミーティング議事録_-_プロダクト部_-_Confluence

そしてチーム内のリソース配分も分類をしていきました。
プロダクトの価値を作る動き、他チームとグロースを目指す動き、MTGなど組織運営に必要な動き、それぞれの割合と目指すリソース配分をすり合わせていきました。
その当時は特に他チームとグロースを目指す動きに対するリソース配分がとても多く、プロダクトの価値を作る動きが鈍っていたのですね...
このリソース課題に関しては原因分析と現場のヒアリングを重ねていきました。

上記から「短期的な施策実装が中心となっており、中長期的に資産となり事業成長に繋がるプロダクト開発ができていない」という課題が浮き彫りになり、その要因も色々な側面から見えてきました。
日頃より感じている課題も普段の話し合いの中では断片的な情報になってしまっていたこと、そしてその課題を解決していくためには網羅的にその要因を見つけていくことが必要だったのだと気付かされました。


②あるべき姿のコンセプト化

続いて、プロダクト部として、プロダクトとしてのあるべき姿をコンセプト化しました。
特に事業課題とプロダクト課題とも関連していた事業者さんの体験(DX)向上にフォーカスし、「事業者さんへの価値提供を強化する」ために事業者さんのDXを改革していくコンセプトが作られました。(ユアマイスターではそれをパートナーDXと呼んでいます)

ここでポイントになるのはプロダクト成長と事業成長が同じベクトルを向いていること。プロダクトが事業課題を解決できる道筋を作ることが今後プロダクト戦略を成功する上での鍵になっていきます。

また、プロダクト開発において資産になるような価値を作ろうとした時には中長期的(Q単位~)な動きになってきます。経営や他チームに新たなプロダクト戦略を理解してもらい協力を得るためには、プロダクト部の言語ではなく、共通の言語に翻訳し直すことが重要であるということを学びました。

③あるべき姿から導く2つの軸

さて次に、上記のコンセプトに対して次の2つの軸を作っていきました

1つ目の軸は「習熟度」。
これまでのロードマップづくりや機能づくりにおいても欠けていたと痛感したのが習熟度という考え方。利用する事業者さんがまだ機能を使い始めの"認知レベル"にいるのか、それとももう機能を十分に使いこなしている"習熟レベル"にいるのか。これにより作るべき機能や作る時期というものが明確になっていきます。
*ユアマイスターでは、この習熟度を4段階に分類しました。
(この習熟度ができたことでMVPの見極めや営業チームとのすり合わせがスムーズになっているのを日々感じています。)

続いて2つ目の軸は「提供価値を生む変化」。
価値ある機能を提供した時にはお客様の体験に変化が生まれていきます。例えば、"可視化"されることで習慣が生まれたり(noteのいいね数とか見ちゃいますよね)、"業務効率化"により新たな時間が生まれたり。提供価値を生むDXの変化分類に名付けをすることで、チームメンバーだけでなく、他チームとの共通言語にもなっていきます。
*ユアマイスター では、この提供価値を生む変化を8段階に分類しました。(Q単位でこの分類の中からフォーカスする分類をピックアップして、チームメンバーと共有しています。)

④3年後までに必要となる機能の洗い出し

②③での考えをもとに、3年後をスコープとして必要な機能を洗い出しました。なんと出てきた機能は約300個...!

機能の洗い出しでやったことリスト
- 競合の機能との差異
- 目安箱*からのリストアップ
- 営業・CS・経理チームへのヒアリング
- 未来の事業ブレストからのピックアップ
*お客様からサービスの改善点などを投稿してもらっているリスト

3年後というスコープは、長期的に考えられる期間の最長期間かなと思いました。技術革新なども生活に浸透するまでは3年ほどかかっているのかなと思うので、最新技術などをここで考慮しておくことも重要だなと思います。

また、日頃からお客様や事業者様との対話を大事にしている文化があるため必要とされているであろう機能は見つけやすかったです。ここでポイントになるのは、お客様や事業者様が自分たちでも気づいていない未来の姿をどこまで想像力を持って考えられるか。
今回はアドバイザーの明石さんからたくさんのフィードバックやご意見を聴きながら定義していったのですが、ここを再現していくには自サービスの業界だけでなく、他サービスで起きている変化の波を日頃から捉えておく必要があるのだと痛感したのでした...!


さて、ちょっと息切れしてきたので、前編としてはここまで。
ちなみにこの①〜④までで約3週間、毎週4~5時間をとって集中的に進めました。
これまで私が経験してきた仕事は色々なフレームワークを活用するという動きが多かったのですが、今回のプロダクト戦略づくりは新たにフレームワークを築き上げていくという難しさがあったなと思います。

それではまた後編で!




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