PdMをもっと深く知る_#12_Product-led Organizationの神髄

2022年3月7日 08:37

前回はやらないことを決めることについて見ていきました。

今回でプロダクト・レッド・オーガニゼーションは最後です。
やること／やらないことを決めるために必要なロードマップの作成方法について見ていきいます。

そしてプロダクト主導型組織に必要不可欠なプロダクトOpsについても学んでいきます。

文字数：約6,400

参考図書

第3部プロダクトデリバリーの新たな方法

・プロダクトデリバリーとは、開発したソフトウェアのデプロイを通じて、プロダクトを市場や顧客のもとに届けること
・顧客が本当に求める機能やプロダクトを特定し、デザインし、デプロイする方法をどのように見極めるかについて見ていく
・PdMがプロダクトロードマップ作りのダイナミックな手法についても掘り下げる
・プロダクトデリバリー戦略には顧客、チーム、チーム内でのコラボレーションが必要
・プロダクト主導型組織は、デザインとデリバリーに対する新しいアプローチを見直す方法を学ばなければならない
・デジタルの時代において、企業は聞き上手になる必要があり、そのために新しいスキルセットが必要
・それはプロダクトを利用している顧客の声に耳を傾け、顧客をより良い成果に導く
・顧客のエンゲージメントに効くポイントを理解し、全面的に定着してもらうことが不可欠

・ビジネスモデル、エンジニアリング手法、テクノロジーの急速な進歩によりPdMは進化を余儀なくされている
・どのようにチームを編成し、顧客とコミュニケーションし、フィードバックを管理するかという課題を突きつけられている
・実際に顧客から得た情報を基に、うまく行っていることに労力を注ぐことができる
・利用状況の改善と自社リソースにも良い判断ができるようになる

プロダクト・レッド・オーガニゼーション
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P23、24、194

15．ダイナミックなロードマップ

■ロードマップの意義

・PdMの主な仕事の一つは、膨大な数の投資候補から顧客とビジネスに最大の効果をもたらすものを絞り込むこと
・プロダクトロードマップは単なるドキュメントでなく、計画し、コミュニケーションをとり、組織に整合する強力なツールとなる
・プロダクトロードマップは、現在の優先順位に基づき、将来的に何が起こるかについてプロダクトチームの計画を表す
・ロードマップには拘束力がなく、常に変更させる可能性がある
・ロードマップを作成する大きな理由は「社内外のステークホルダにプロダクトの目的を伝え、フィードバックを集めるのに効果的な方法」となるから
・プロダクトのビジョンに賛同してもらい、企業がどこに向かっているかを理解してもらう
・ロードマップは顧客と優先順位について議論する場合にも有効に使える
・PdMは、主張の強い顧客、経営層、販売者など誰もが次になにを作るべきかついて意見を持っているので、これらを分類し優先順位をつける事
・データドリブンなPdMはロードマップやバックログリストの優先順位付けにKPIや戦略的目標を組み込んでいる

プロダクト・レッド・オーガニゼーション
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P237～P

■ロードマップの作り方

＜STEP1：ビジョンと戦略から始める＞
・解決しようとしている市場の課題はなにか？
　対象となる顧客、業界、ペルソナは誰か？
　市場機会は何か？
　どこに成長の最大の機会があるか？
　これの答えは、機能レベルの議論を行う前に解決しなければならない
・最終的にプロダクトロードマップとつながる戦略を策定する際には、Whyを明確にすることが重要
・プロダクトチームはロードマップの計画を始める前に、時間をかけてプロダクトミッションを決定し、理解できるようなシンプルな文章にまとめる
・PdMはプロダクトビジョンから、プロダクトの目標を導き出すことで、ロードマップ上の取組みに影響を与える
・プロダクトの目標を考えることは、PdMがプロダクト戦略を実行可能な計画に変換するためのステップ
・プロダクトの目標は計測可能であり、メトリクスやKPIに結び付け、長期的目標として年毎などで見直す

＜STEP2：適切な優先順位付け＞
・データドリブンでプロダクト主導型組織は、戦略上の目標との整合性はもちろん、優先順位を決定するための行動と情報の両方を考慮すべき
・新プロダクトや新機能の場合、過去の顧客の行動だけに頼って優先順位を決めることは難しいので、ビジョンや戦略との整合性をより重視する
・機能やプロダクトが構築された後に、その決定を評価できるようにデータを活用する

＜STEP3：ロードマップの各項目にメトリクスを割り当てる＞
・優先順位をつけた各機能に、ビジネス目標、定着・利用状況の目標の両方を割り当てる
・顧客志向のメトリクスや利用状況などのメトリクスはユーザーの行動や感情を具体的に示す指標で先行指標となる

＜STEP4：インパクトを測る＞
・機能のインパクトを理解するには、ロードマップの各機能にベースラインとなるKPIを設定する
　　例1）利用状況：30日以内に○％のユーザーに利用してもらう
　　例2）CSAT（顧客満足度）：UI変更により問い合わせを○％減少させる
　　例3）特定の財務指標：20のアカウントを有料顧客に移行させる
・KPIを事前に設定しておくことで、計測をサポートするために必要な機能が開発が機能の一部として計画され、プロダクトチームの成功をどのように計測しているかを理解してもらえる

＜STEP5：優先順位の伝達＞
・バックログを通じて、開発チームは今後数回のスプリントやイテレーションで何を取り組むか把握できるが、バックログはロードマップではない
・ロードマップは組織のビジョンや戦略的な目標と結びついており、12か月以上先の期間を対象とする
・アジャイル組織においてロードマップはプロジェクト計画でなく組織のガイドとなる
・ロードマップの目的は、開発の優先順位を整理して示すこと
・ロードマップのドキュメントに目標とメトリクスを組み込むことで「Why」の説明に役立つ
・ロードマップをいきなり掲示するのではなく、関係者全員が協調し、集中できてはじめて効果的なものとなる

プロダクト・レッド・オーガニゼーション
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P241～P245

■ロードマップは完璧ではない

■プロダクトデリバリーの予測可能性を測る方法
・強力なプロダクトチームはユーザーがどのように行動するかを予測することができ、チームがどのようなパフォーマンスを発揮するかを予測することができる
・予測可能性のないロードマップは信頼できないものになる
・ロードマップはアート（経験に基づく見込み）とサイエンス（データが示す確からしさ）を融合し、現実的な未来像を描くことが不可欠
・プロダクトチームが完成したストーリーポイント数と最初にコミットしたストーリーポイントとの割合を取ることで、予測可能性を計測する
・この割合からロードマップの進捗度を測る

■ロードマップはダイナミックである
・ロードマップに完成はなく、要素は常に変化する
・定期的にロードマップを見直すことで、フィードバックを得る機会とする
・PdMは定期的にプロダクトがどこに向かっているかを伝えることで、全員が同じ認識を持つことができるようにする

■ロードマップの要点
・ロードマップの機能がリリースされたらロードマップから削除してよいと勘違いしている人が多い
・リリースされたあとに設定したKPIを達成し、期待通りの成果を得ることができたかを判断する必要がある
・ロードマップは完璧でなく、達成できないかもしれないし、失敗するかもしれないと思っておく、そのうえで変化に柔軟にする

プロダクト・レッド・オーガニゼーション
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P245～P249

16．モダンなプロダクトチームを作る

■PdMは影響力でチームをリードする

・PdMは権威でなく影響力でリードする
・モダンなプロダクトチームとは、自分たちをプロダクト主導型組織のオーケストレーターとして捉え、各部門がプロダクトを活用してより良い顧客体験を提供できるように支援する

・PdMは、給与・賞与など財布の紐は握らない
・PdMが直属の部下を持つことは稀で、PdMをフォローするように人々を鼓舞し、ベストだと思う決断をするように人々を導き、異なる視点を整合する能力が求められる
・PdMに求められるスキルは、効果が表れるまで時間がかかり、自分のやり方が正しいか知ることが難しい
・PdMは影響力で人をリードし、市場やプロダクトを理解するのと同様に、人を理解することが重要な仕事

プロダクト・レッド・オーガニゼーション
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P250～P252

■プロダクトOps

・プロダクトOpsは、プロダクト、エンジニアリング、カスタマーサクセスが交わるところに存在する
・目的は、
　「プロダクトのフィードバックループを強化し」、
　「プロダクト開発とローンチを体系化し」、
　「プロダクトに関する知識を全社的に拡大するために研究開発チームと市場開拓に関連するチームをサポートする」
・明確にプロダクトOpsを配置する場合、プロダクトマネジメントチームかプロダクト責任者をレポートラインとする隣接する部門に所属する

プロダクト・レッド・オーガニゼーション
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P252～P254

■プロダクトOpsが実現する機能

①最適化
・プロダクトOpsは理想的なプロダクト体験を実現するために必要に「微調整や設定」＝「最適化」に影響を与える
・最適化するために、顧客のフィードバックを収集し構造化し、伝える責任を負う
・プロダクトOpsは、新機能のヒット率を高めるために、利用状況やフィードバックデータを、営業やマーケティングにあるデータベースと融合することでローンチ関する、より賢明な判断を下せる手助けをする
・プロダクトOpsは、誰がアーリーアダプターになり得るかを見極めることもできる
・プロダクトOpsは、PdMが新機能をローンチする際に正しい判断をするのを支援し、同時に機能を廃止についても間違った判断をしないようにもする

②整合（アライメント）
・プロダクトOpsは、多くのビジネス部門の中間に位置するので、部署間の整合やコミュニケーションに大きな価値を与える
・プロダクトOpsは、利用状況、フィードバック、NPSなどのデータを営業、マーケティング、財務のデータを使って補強し、経営陣にタイムリーにこれまで未知だったインサイトを提供する
・プロダクトOpsは、エンジニアリングチームが自分たちの作っているものの背後にある「Why」を確実に理解することも助ける
・他部門とコミュニケーションを取る際に、各部署へデータ提供を行う
＜参考＞
　＋レベニューOps：広範な市場開拓チームの中心
　＋DevOps　　　：エンジニアリングと運用の中心

③フィードバックループ
・プロダクトOpsが存在するだけでPdMは現場でより多くの時間を過ごすことができる（PdMを助けることから始まる）
・プロダクトOpsは、頼まれたデータだけでなく、プロダクトの意思決定に必要なデータをリーダーに届けることができる必要がある
・しっかりしたフィードバックループは、「データ」「ストーリー」「ガイダンス」のことであり、PdMが正しいソリューションを構築でき、既存プロダクトの重要な改善点を優先していることを確かめるために必要
・顧客は新しいものでなく、今あるものがより良い機能になることを求めている
・新しい機能開発と既存機能改良のどちらを優先するかという信頼性の高い判断をできるようにすることが責務

④インフラとレポート
・データ管理にはインフラが必要であり、プロダクトOpsはプロダクトチームの技術スタックの選択・統合・維持・運用に責任を持つ
・プロダクトOpsリーダーは、インフラの所有者としてスタック内の各ツールのビジネス価値を示す責任も持つ
・分析ツールの乱立を防ぎ運用コストを下げることも重要な責務
・技術スタックの所有＝レポートの所有と密接に関係し、プロダクトOpsはビジネスレビューをまとめ、取締役会に報告する責務も負っている

プロダクト・レッド・オーガニゼーション
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P254～P260

17．行動への呼びかけ

■著者Todo Olsonからのメッセージ

・プロダクト主導型のムーブメントは「プロダクト」「エンジニアリング」「マーケティング」「営業」「カスタマーサクセス」の境界を曖昧にしている
・プロダクトの役割が、機能より顧客体験が重視されつつあるので、プロダクトリーダーは意味のあるユーザー体験をもたらすために、新たなスキルと習慣を身につける必要がある
・この変化にいち早く適応したものが報われる
・まずは少しずつ始めれば良い、まずはデータから始めて、計測していないものは改善できないことと肝に銘じる
・顧客はシンプルな体験を求めており、それを自分でコントロールしたいと思っている
・あらかじめ許可を取って行動することよりも、うまく行かなかったら許しを乞う精神が必要

プロダクト・レッド・オーガニゼーション
顧客と組織と成長をつなぐプロダクト主導型の構築
ISBN 978-4-8207-2955-6 C3055
P261～P263

＜#12_Product-led Organizationの神髄の所感＞

ロードマップを作る必要があることは、従来型（ウォータフォール）の開発でも、プロダクト主導型組織でも同じです。

ただ、プロダクト主導型は関係者を巻き込むことを必須にしています。
上の方でいつの間にか決まったロードマップは禁物です。
そしてロードマップを定期的に更新するプロセスについても言及してくれています。
このタイミングで「作ること」「売ること」「見せること」に集中し過ぎている、エンジニア、セールス、マーケティングの人たちに顧客課題解決のミッションを共有できる機会になるのは良いですね。

モダンなプロダクトチームではまたしても、「プロダクトOps」たる新ワードが出てきました。

結局PdMのやることが多すぎるので、「PdMを支える右腕を作るともっと効率良いよ」というメッセージとして受け取りました。
CxOが出てきて時と似ています。
CEOが出てきたと思ったら、COO、CTO、CIOが出てきて、結局CEOのやることが多すぎて、各分野でリーダークラスの人に対して権限移譲していく構図です。

結局組織は、「人」だなと思いました。
PdMが今後どんな役割の割り方を推奨されていくのかは継続的にウォッチしていきます。

なにはともあれ、今回の参考図書も最高に勉強になりました！
もう読んでいて全く飽きないです。

JMAMのPdM関連の本はこれで3冊目になりましたが、どれもちゃんとリンクして、それぞれに重要なことがしっかり記載されています。
すっかりJMAMファンになったので、今後も新しい本を見つけたら紹介していこうと思います。

参考①：PdMとは何か

参考②：ソフトウェアビジネスの組織づくり（チームトポロジー）