プロダクトマネジメント組織で浸透した7つの言葉と習慣
Retty執行役員VPoPの野口です。2021年、この1年を通じてのRettyプロダクトマネジメント組織の変化について紹介します。どこかで聞いたことのあるワーディングのタイトルですが、アウトカム、ロードマップ、事前検証などなど・・・7つの言葉と習慣に着目しました。この記事は「Retty Part1 Advent Calendar 2021」の24日目です。
はじめに
改めまして、RettyでPM・デザイナー・CS・コミュニティマネージャーが所属する部門を担当している野口です。
今年はpmconf2021で登壇機会を頂きました。600名近くの方々にライブ視聴いただきました！感謝🙇♂
このセッションではPMスキル・評価制度導入に主眼を置いておりました。今回はそちらの内容にも少し触れながら、Rettyプロダクトマネジメント組織にこの1年を通じてどんな変化が起こったかをご紹介します。
今年2つ目のアドベントカレンダーです。マネジメントをテーマにした1つ目の記事もぜひご覧ください。
本記事で使う用語や組織
・PM：プロダクトマネージャーを指します
・PM、プランナーのRetty社定義：以下の図のイメージです
それでは今年組織に浸透した7つの言葉と習慣を紹介していきます。
①PMスキル定義・評価制度
②アウトカム
③ロードマップ
④事前検証
⑤問いを立てる力
⑥既知と未知
⑦因果ループ
①PMスキル定義・評価制度
2020年に運用を開始したPMスキル定義・評価制度。約2年で細かいチューニングを行いながら、しっかり運用に乗せることができました。
この副産物を紹介していきます。
フィードバックの目線が揃うようになった
Rettyでプロダクトマネジメントをやっていく上で必要なスキルを言語化しているので、フィードバック時はこの中から何が足りないか、何ができているかで会話ができるように。今までは0から考えてフィードバックのワードを考えるか、逐一本や文献から引用してフィードバックしていました。その頃と比べると、ベースとなるスキル定義がある分、フィードバックの質が上がりました。メンバーも全体像を踏まえてフィードバックを咀嚼できるということで、うまく回っています。
PMが増えた
昨年も含めですが、PMを2名増やすことができました。PMスキル定義を踏まえたフィードバックの結果、強みを伸ばしながら、弱みも潰していく。そんな育成体制を作れているからこそだと思います。
元来Rettyではデータ分析チームの育成が整っており、若手輩出組織となっています。今年、そのデータ分析チームでの2年の修行を経て、新卒3年目でPMになるメンバーが出ました。彼はデータ分析チーム時代終盤にはプランニングのタスクをいくつか持ち、PMスキル評価でのフィードバックを受けていました。当初は、分析出身が故に課題発見が強く推進力に課題がありましたが、しっかりと弱みも克服して活躍してくれています。
彼の登壇記事です
プランナーの成長！大きな体験リニューアルを自走
これまでのRettyのPMは
①担当領域のロードマップ作成
②今後に向けたリサーチ
③大きめのユーザーストーリーのデリバリーを主導
を全部一手に担っていました。しかし、PMスキルのフィードバックを受け、プランナーメンバーがメキメキ成長してくれており、③大きめのユーザーストーリーのデリバリーをプランナーメンバーが担えるようになりました。グイっと進めてくれており、本当に頼もしいです。
先日大きなリリースを担ってくれたプランナーメンバーの記事
メンバーの成長により、コア価値の開発に着手できるように
PMが増えたことで、これまで人がいないが故に取り組めていなかった開発やリサーチにも手が回るようになりました。具体的にはRettyのコア価値に関するプロダクト開発に本腰を入れることができるように。その一端を今年リリースしましたが、来年はさらに良き体験を提供できるようになるはずなので、ぜひご期待ください。
②アウトカム
アウトカムは2020年のRettyでは開発シーンでたま〜に登場する程度でしたが、今年しっかり定着させることができました。PMだけでなく、エンジニアやデザイナーからも、スプリントレビューやリファインメントの場でも当たり前のように出てきます。
毎週の全社会議で先週生まれたアウトカムを共有する、毎週のスプリントゴールでアウトカムを明示する。このような仕組み化が功を奏しました。
今後の課題としては、言語化が難しい複雑な開発のアウトカムをいかにシンプルに表現するかです。例えばto B飲食店や社内請求業務における開発のアウトカムなど、担当者以外がアウトカムを直感的に理解しにくいシーン。このようなケースでもシンプルに想定ターゲットと得られるアウトカムが言語化されていることで、Whyが伝わり、全社の開発連動性を高めることができます。ここは組織全体で改善していきたいですね。
③ロードマップ
2020年後半より始めたプロダクトロードマップが運用に乗ってきました。ボトムアップでやりたい開発物とリリース期限を収集して一覧し、リソース調整をするというスタイルのロードマップをかつて作っていたことがあったのですが、案の定完全にプロジェクト進捗管理ガントチャートと化したので、それは捨て去りました。
今はこんなイメージでロードマップを作っています。
まず事業計画・プロダクトビジョン・プロダクト戦略から通期で実現したいゴールを決めます。ここはできるだけシンプルにフォーカスしたいこと、実現したい価値・高さを定義します。
通期のゴールを達成するために、四半期のゴールを定めます。四半期は目の前と次のQのゴールくらいまでしか解像度は上げません。例えば1Qであれば、1Qと2Qの解像度は高い状態としますが、3Q・4Qはかっちりは固めないようにしています。理由としては、1Q・2Qで実施した施策や検証の結果次第では3Q・4Qの動きが全く変わってくる可能性があるためです。変更される度にいちいち作り直すタスクよりも、もっとユーザーさんに価値あるタスクはたくさんあるので、敢えて3Q・4Qは作り込みません。もちろん粗い解像度で「こんな登り方になるかもね」というのは話しますが、細かい先々のロードマップよりも最終的なゴールを意識するようにしています。
to B飲食店さんとto Cユーザーさんは分けて作るようにしています。これにはいくつか理由があります。1つ目は開発チームが異なるからです。大規模スクラム（LeSS）で開発しているため、基本的な開発優先度は全体で考えているものの、toB飲食店さん系の開発に強いチームは5チーム中2チームのみです。結局開発チームが異なるため、チームを分けるというのが理由の1つ目。2つ目の理由としては、Happyにしたいターゲットが異なること。飲食店さんとユーザーさんでは抱えている課題は当たり前ですが、全く異なります。BtoBtoCであるが故に両者は密接に関わるため、もちろん全体での整合性は見ますが、ロードマップとして表現する際はto Bとto Cは分離するようにしています。
色々書きましたが、Rettyのプロダクトロードマップはまだ改善点だらけです。他社の話をお伺いしていても、正直改善余地しかないことを痛感するので、さらにブラッシュアップしていきたいですね。
④事前検証
これまでのRettyでは中期的なプロダクトのWhyやWhatを考える時間があまり取れていませんでした。点の施策の短期スパンでの事前調査や事後効果検証が中心。プロダクトディスカバリーに時間を投資できているわけでなく、プロダクトマネージャーはプロダクトデリバリーに軸足を置いていました。
ここでプロダクトディスカバリーとデリバリーを定義しておきます。
プロダクトディスカバリー：顧客のためのソリューションを考え抜くこと
プロダクトデリバリー：堅牢でスケーラブルな実装を行い、安定しており安心できる価値を顧客に提供すること
開発プロセスが改善されたことにより、今まで以上にHowはエンジニアにお任せして、PMがよりWhyとWhatを研ぎ澄ますことができるようになりました。加えて前述のようにPMも増えたので、以前より中期的なスパンでのプロダクトディスカバリーにより時間を割けるようになりました。
プロダクトディスカバリーへの注力はまだ始まったばかりで、現状それに特化したチームを作っているわけでも、開発プロセスに明示的に組み込まれているわけでもありません。こちらの最適解はまだ模索していければなと。
プロダクトディスカバリーの中で定着したのは事前検証です。リリース前に行う検証として、ユーザーインタビューやアンケートでのプロトタイプ検証を習慣化するようになりました。従来なら試しにキャンペーンを行っていたものをメルマガで低コストで検証するようなことも行っています。A/Bテストやとりあえずリリースしてから検証するというフットワーク軽めスタイルでこれまでやっておりましたが、それでは無駄な工数を使うことが多く、結局目的の検証には遠回りに。事前検証による確からしさがバックログの中で優先度を判断する上で重要な観点として捉えられるようになり、不確実性を下げていく取り組みとして非常に効果的でした。
事前検証について書いたnoteです
⑤問いを立てる力
良い問いを設定できなければ、良い検証にならないし、良いソリューションも生まれない。
プロダクトディスカバリーに注力していく中で、これを組織として痛感しております。どれかでQueryを書く技術があっても、うまくユーザーインタビューができてもそもそもの問いの設定が誤っていれば元も子もないのです。
良い仮説検証のためには、問いを立てる力こそ重要なのではないかとPM陣で話し合い、これを「問いを立てる力」と定義し、今PMスキルの中に組み込もうとしています。
「問いを立てる力」
・背景を理解して、あるべき状態と現状を正しく理解できる
・あるべき状態に到達するために、知るべきことを定義できる
・意思決定するために、検証して、優先して知るべきことを決められる
これは現状、言葉ができただけのステータスなので、今後組織の習慣としていきたいですね。
⑥既知と未知
既知と未知はビルドトラップ本の輪読会後にRettyで浸透した考え方です。ユーザーのインサイトや課題、ソリューションについて、ファクトとして我々にとって既知の事実である。そんなことばかりであれば有難いですが、取り掛かることの大半が未知かつ不確実性の高いことです。ビルドトラップ本の内容に従って、Rettyのmiroで既知・未知の指差し確認に使っている図です。
仮説について議論していく中でも落とし穴が本当にたくさんあります。
・未知なはずのことを既知と勘違いして議論を進める→検証されてないことを前提としてしまっているので、不確実性が高い
・仮説はないが他社の解決策を知っている（＝未知×既知）が故に強引に施策を進める→仮説がないので仮説を立てた上で施策を行わないと施策の成功・失敗以外に学びがない
・仮説もなく解決策もわからない（未知×未知）のでブレストを行う→仮説がないので筋の良い施策にはなりにくい、直感的な未知×既知施策が出るのが関の山
このような落とし穴に引っかかるのを防ぐために、既知と未知で自分たちが知っていることを指差し確認しながら、議論を進めるようにしています。
⑦因果ループ
これも今年Rettyで流行ったものです。業務プロセス上の課題を整理する際に使っています。またロードマップ作りにおいても、実現したい価値や現状の課題の関係を整理し、ボトルネックやブレイクスルーポイントを探し当てるのに活用しています。大きな開発物に関しては、工数もかかり他の開発物の体験・価値への影響も大きいので、因果ループでの指差し確認の重要性を実感しています。
エンジニアシニアマネージャーの常松がこちらの導入を推し進めてくれました。これは、分析チームの業務プロセスのボトルネックを整理して、プロセス改善に繋げた事例についての登壇スライドです。
MeetyとRetty Advent Calendarの宣伝
今回はプロダクトマネジメント観点でのこの1年でのRettyで変化した言葉と習慣について書きました。少しでもプロダクト開発の参考になれば幸いです。
そして1年を通じて、pmconfやプロダクト筋トレ、pmjp Slackなどのプロダクトマネジメントコミュニティや幾多の勉強会・カンファレンスでの出会いや気づきが私やRettyの成長の肥やしになっている、そんな実感がすごくあります。改めて感謝すると共に、私自身来年もコミュニティに貢献していくべくアウトプットと盛り上げに励んでいきたい所存です。
RettyではMeetyをやっております。もう少し話を聞きたいという方はぜひこちらで「話したい」を押してみてください！
Retty社では今年は2種類のAdvent Calendarが動いてます。そちらも見てみてくださいね。
最後に個人的にポッドキャストをやっています。スタートアップのグロースがテーマなのでこちらも聴いてみてください！
いいなと思ったら応援しよう！
