プロダクトマネージャー（PdM）になるために #5_良い製品を創り出す地図
IT業界で引く手あまたのPdMについて学習しています。
② 成功するための組織と人のパートでは以下のことを学習できました。
■#2_PdMの役割と多忙な理由
・そもそもPdMとは何か
・PdMに求められる要件とは何か
■#3_PdMが一緒に働く人たち
・PdMが顧客が熱狂する製品を作るために連携する人達
・連携する人たちとの責任および役割の分解
■ #4_PdMとスケールアップする人たち
・企業として成長していくに連れて
変化するPdMおよび一緒に仕事をする人たちの役割の変化
製品開発チームの構成
今回からはPart3になり、いよいよ製品を開発する取組み方法に入っていきます。
文字数：2,400
参考図書
③ 成功するための製品〜製品ロードマップ作成〜
・強力な製品開発チームが出来たら次は「何に取り組むべきか」を考える
・ここではアウトプット（プロダクト）ではなくアウトカム（顧客に与える変化）に焦点を当てる
・また製品開発ロードマップを「チームが取り組むように求められている機能やプロジェクトの優先順位リスト」と定義する
・経営陣が製品開発ロードマップを使いたがる理由
1、製品開発チームが最も価値のある仕事を優先していることを確認したい
2、マーケティングプログラムや販売担当者の雇用、パートナーとの依存関係の調整などできるように、いつになったら主要な機能が使えるようになるか知りたい
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P131〜132
◼️Chapter22 製品ロードマップの問題点
・多くの場合、製品開発ロードマップは残念な結果に終わる。そこには2つの不都合な真実がある
真実①アイデアの半分以上はうまく行かない
真実②アイデアに価値があっても事業期待を達成するためのTime to Moneyが必要
・有能な開発チームはこの不都合な真実を受け入れ、即座にリスクに取組み有効なソリューションに向けて迅速に*イテレーションを実行する
・問題はロードマップ上のアイデアリストではなく、リストを書いた途端、それぞれの事項を約束ごとと理解してしまうこと
・問題の核心はまさにここであり、「プロダクトが本質的な問題を解決しないにもかかわらず、作って市場投入する責任を製品開発チームが負わされてしまう」
*イテレーション（iteration）：反復すること、一連の工程を短期間で繰り返すアジャイル開発に必要な概念
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P133〜135
◼️Chapter23 ロードマップに代わるもの
・ロードマップは2つの目的に適っていた、ゆえに長く存在した
1、最も事業価値の高い項目に取り組んでいることを確認したい経営陣の要望に応える
2、事業を進めるために期日あるコミットメントが必要
・権限のある開発チームは割り当てられた特定のビジネス問題を解決する最善の方法を自ら見つけ出す能力を持つ
・この能力を実現するには「企業がどこに向かっているか」、「大きな目標に対してどのように貢献するのが望ましいか」を理解しなければならない
＜ビジネスの脈絡の2つの要素＞
1、製品のビジョンと戦略
2、ビジネスの目標
・重要なのはアウトプット（プロダクト）でなくアウトカム（顧客に与える変化）であり、解決すべきビジネス上の問題によってロードマップを作成すること
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P136〜139
◼️Chapter23_2 ハイインテグリティーコミットメント
・カスタムソフトウェア環境では、企業がそのソフトウェアに満足するまでイテレーションを続けることができるが製品企業ではそれはあり得ない
・優れた企業はコミットメントを最小化する
・コミットメントのあらゆる根本原因は「その時期にある」＝あまりに早すぎる
・持続的な製品発見と市場投入モデルは時間と資金を費やして製品品質のものを作る前に「提供するものが顧客の問題を解決できるか？」に答えることが重要
・約束の期日を決める場合には、デリバリーマネージャー（参考、#4_PdMとスケールアップする人たち_Chapter19）が重要な役割を果たす
・開発チームはコミットメントされる前に、製品を発見するのに時間が欲しいと頼み製品発見のあとに、期日や納品に関するコミットメントを進んで受け入れる
*インテグリティー（integrity）：誠実、完全な状態、システムの整合性
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P140〜142
＜③ 成功するための製品〜製品ロードマップ作成〜の所感＞
いよいよ製品開発に関するセクションが始まりました。
製品ロードマップ作ってしまっていたし、作るように指示していたな・・・と少し反省をしつつ、経営陣がロードマップとコミットメントを求める気持ちも分かります。
やはり期日を切らないとやってくれないケースがあるからだと思います。
また私がいま時点（22年1月）で経験しているのが、LTV（Life Time Value）製品でなく、OTV（One Time Value）製品であることも起因していると思います。
あくまで所感ですが、この本の前提になっているのは
① 対象がLTV製品
② 強烈なリーダーシップである程度PMFの道筋が見えている
③ 少数ながらユーザー数がある
だと感じました。
①については、これからのビジネスモデルを考慮すると頷けますし、だからこそ購入した本でした。
一方②と③が相当難しい気はしています。
ここはスタートアップ期に一気にやりきって、そこに組織として開発チームが必要になり作られていく、と考えておきます。
この記事が気に入ったらサポートをしてみませんか？