既存プロダクトのプロダクトマネジメントを代行したときにやったこと
こんにちは、株式会社POLでエンジニアをしているmotikomaです。
最近の趣味は週末温泉旅行です。毎週楽しみでしょうがないです。
はじめに
さて、今回は急遽既存プロダクトのプロダクトマネジメントを代行する必要がでてきたときにやったことを備忘録としてまとめておきたいと思います。
※やるべきことを全てやったというわけではないです。書きながら脳内整理しているので加筆修正すると思います。
実は昨年度大きな体制変更がありました。その際に自チームのプロダクトマネージャーが一時的に不在になる期間があり、急遽自分がメインでプロダクトバックログを整備する必要があったという感じです。ちなみに現在はプロダクトマネージャーもジョインして肩の荷が降りました（ふいー）
そんなこんなでいざ「プロダクトバックログを整備するぞい！」という状況に立ったときに、自分のプロダクトに対する理解が曖昧で、優先度、内容検討、実施の有無を判断できなくて死ぬかと思いました。。
というわけで急いで下記を実施しました。
プロダクトを使い倒す
プロダクトコンセプトの可視化
マッチングジャーニーの可視化
プロダクトを使い倒す
とにもかくにも自分が提供しているプロダクトの仕様を知らないと何も始まりません。カスタマーサクセスから「Aという機能の〜について相談したいんですが」となったときに「Aってなんだっけ？？」ってなってたら最適な体験なんで提供できないですからね…。できる限り仕様を網羅的に知るべく、ヘルプページを読みながらプロダクトの機能を実際に使い倒していきました。もちろん管理画面も使い倒して、何がどうなったらこうなってというのを紐解いていきます。
プロダクトコンセプトの可視化
プロダクトに対する思いを再確認する
ミッション, ビジョンの確認や経営層が内外で発しているメッセージなども振り返りつつ、「なぜこのプロダクトは生まれたのか」という部分について自分なりに咀嚼して理解を深めました。代表の加茂が語る創業時のエピソードなどを見直して「なるほどなあ。こんな思いがあったのね」と共感することができて普通に楽しかったです。
プロダクトコンセプトを確認する
自分が考える「プロダクトコンセプト」は最低限下記がまとまっているものになります。
誰が、
どのような状況で、
どのような課題を解決しようと考えていて、
解決策の候補として代替品が挙がっているなかで、
自社プロダクトが選ばれる場合、その理由は「hogehoge」
自社プロダクトが選ばれる理由を支える独自資産は「fugafuga」
要は現時点での「プロダクトが顧客から選ばれるパターン＝勝ち筋」を可視化したドキュメントですね。
ちなみに勝ち筋は下記の公式の分だけ複数存在すると考えています。各変数が具体的であればあるほど増えていくので、可視化する際にはある程度抽象化して捉える必要があります。
勝ち筋の数 = 誰 ✖︎ 状況 ✖︎ 課題
ここら辺が毎回、頭を悩ましながらやっている部分ですね（使用する用語も毎回変えたくなる。「課題」を「利用目的」に変えたりとか…）プロダクトコンセプトの整理にはリーンキャンバスをカスタマイズして使用していますが、みんなどのように整理しているのかとても興味津々です。
なお、開発ロードマップやプロダクトバックログを検討する際の判断軸としては色々あると思いますが、自分は下記のように思考しています。
ミッション,ビジョンに沿っているか？
勝ち筋を強めることにつながるか？
選ばれる理由を強めることができるか？
選ばれない理由を弱めることができるか？
勝ち筋を増やすことにつながるか？
選ばれる理由を増やすことができるか？
上記に当てはまらないもの、例えば既存の勝ち筋を失ってしまうような施策は実施しないという判断ができると思います（そもそもコンセプトをガラリと変えましょうという話なら別ですが）
まずは一旦、手持ちの知識でプロダクトコンセプトを埋めましたが、如何せん解像度が粗い状態でした。そこで、調査を実施することにしました。
ユーザー調査
POLが提供しているLabBaseは企業と理系学生のマッチングを生み出すことで価値を提供しています。まずは企業に対しては事例インタビューや受注理由,解約理由などを全て見て、勝ち負けパターンをできる限り網羅的に整理していきました。学生についても同様にインタビューに同席したり過去の動画やアンケートを確認します。
自社の勝ちパターンの把握
ユーザーインタビュー結果
自社の顧客事例
学生の利用サービス比較検討
自社プロダクトの受注理由と件数
NPSの数値が高い自由解答
自社の負けパターンの把握
ユーザーインタビュー結果
狭義の「競合プロダクト」の顧客事例
学生の利用サービス比較検討
自社プロダクトの失注理由と件数
自社プロダクトの解約理由と件数
NPSの数値が低い自由解答
プロダクトコンセプトの解像度を徐々に高める
顧客調査を進めることで、ある程度プロダクトコンセプトを整理することができたので、WIPの状態でビジネス側の各責任者に見せてヒアリングを実施しました。おおむね勝ち筋については想定通りというところもあれば、自分が認識不足だったパターンも見えてきました。その場で相談しながら加筆修正を実施して、プロダクトコンセプトの解像度を高めていきました。
マッチングジャーニーの可視化
はい。プロダクトコンセプトも徐々に整理できてきたということで、この頃には自分も既存のプロダクトバックログアイテムの実施有無について、ある程度方針を判断できるようになっていたと思います。とはいえ、まだまだプロダクトバックログアイテムの内容を検討したり、優先順位を考えるには情報が足りません。そう、必要なのはユーザーの利用状況の把握ですね。というわけで、マッチングジャーニーを可視化していきました。
利用状況と心理を洗い出して時系列でマッピング
私としては人事と学生が相思相愛に至るまでのマッチングジャーニーを可視化することで、「心理的に不安になったり、機能として使いづらい点」を改善していきたいと考えていました。
マッチングジャーニー自体はFigjamで作成し、手持ちの情報をペタペタと切り貼りしてマッピングしていきました。企業と学生の利用状況と心理が時系列で並び、その間に両者のコミュニケーションを滑らかにする機能を記載するという感じですね。なお可視化する際にはプロダクトコンセプトを確認した際の調査結果も踏まえつつ、下記の情報を参考にしました。
企業,学生のインタビュー記録
Sales,マーケ,カスタマーサクセスからの要望（の背景にあるユーザーの具体的な利用状況と心理）
これまでのアンケート結果（NPS含む）
購買データや行動データの分析結果
マッチングジャーニーの解像度を徐々に高める
マッチングジャーニーもプロダクトコンセプトと同様にある程度の流れを可視化した段階でビジネス側の各責任者に見せて一緒に作ることにしました。利用状況と心理に対するフィードバックをもらいつつ、定期的に施策を検討しています。
現状の体制についてはある程度分化が進んでいるため、企業側と学生側のそれぞれの視点で価値を高めるチームが分かれています。とはいえ、両者への価値提供は表裏一体なんですよね。なので、それぞれの視点は持ちつつも同じ目線でマッチングジャーニーを練り上げていく必要があると感じていました。結果的にチームを跨いでコミュニケーション方針の意識を合わせることができたので実施してよかったです。
まとめ
プロダクトを使い倒して仕様への理解を深め、プロダクトコンセプトとマッチングジャーニーを可視化することで、プロダクトバックログを整備することができるようになったよという話でした。まあ、一旦最低限という感じが強いですね…。まだマッチングジャーニーの解像度が粗いなあという気持ちがあります。ユーザーインタビューや仮説検証型の開発サイクルを回していきたいのですが、余力が足りないので誰かに助けてもらえると嬉しいです（チラチラ）
というわけでプロダクトマネージャー募集しているので、ご興味がある方はお気軽にカジュアル面談しましょう。
最後に自分が業務を進める上で参考にしている書籍を記載しておきます。
※あくまで参考にしているだけで書籍に記載されている方法論をそのまま完コピしているわけではありません