プロダクトマネジメントを学ぶための良書の1つが『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』です。自分も現役PdMとして業務をするにあたってハッとさせられる部分が多く非常に参考になりました。（当時、私が担当していたプロダクト組織もビルドトラップの罠にハマっていました^^;）

プロダクトマネージャーをしていると往々にして以下のようにアウトカム（成果、KPIなど）よりもアウトプット（機能数、リリース数など）を重視する状況に陥ってしまいますが、それを本書ではビルドトラップと呼んでおり、その原因と防ぐ方法について詳しく解説してくれています。

• とにかく仕様書作成や直近の施策の企画・ディレクションに追われてしまう
• 開発することに必死で一歩引いて前提や目的を考えたり、分析する時間をあまり作れていない
• 機能はリリースしたけど結局どれぐらい効果があったのかよくわからない

本記事では本書の書評・要約をするとともに、自分が学んだプロダクトマネジメントについてまとめます。プロダクトをもっとグロースさせたい、より価値あるプロダクト開発がしたい、などの課題がある方はぜひ参考にしてください^^

▼プロダクトマネジメントのおすすめ本
現役PdMが厳選！プロダクトマネジメントのおすすめ本

書籍『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』とは？

本書は『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』という書籍名で、2020年10月発売と比較的新しい本です。（そもそも日本でプロダクトマネジメントの認知が上がって書籍が増えてきたのが最近ですね）

タイトルのとおりプロダクトマネジメントについて学ぶことができる良書で、特に「ビルドトラップ」という、アウトカムではなくアウトプットで良し悪しを測定して行き詰まっている状態や、生み出した価値ではなく機能開発とリリースに集中している状態について、その兆候や対策について解説されています。

このビルドトラップという考え方は目からウロコで、どうしても目に見えるアウトプットで一喜一憂しがちなので、いかにアウトカム重視のチームにするか？など大変参考になります。

▼書籍概要

書籍名	プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
発売日	2020/10/26
著者	Melissa Perri、吉羽 龍太郎(翻訳)
本の概要	顧客に価値を届けるプロダクトを作り出すプロダクトマネジメントについて学ぶ本です。アウトプットを重視する企業が陥りがちなビルドトラップについて、その原因と防ぐ方法について詳しく解説があります。
どんな人におすすめか	リリースすることを目標・ゴールに置くことに違和感を感じているプロダクトマネージャー(PdM)。成果物ではなく成果を出すためにどうすればよいのか？
おすすめポイント	「作るもの」ではなく「解決する課題」にフォーカスするプロダクトマネジメントがなぜ必要なのか？どうすればビルドトラップから抜け出せるのか？具体的な戦略・方針の作成方法がわかります。
中身（目次）	第I部 ビルドトラップ 1章　価値交換システム 2章　価値交換システムの制約 3章　プロジェクト / プロダクト / サービス 4章　プロダクト主導組織 5章　私たちが知っていること、知らないこと 第II部 プロダクトマネージャーの役割 6章　悪いプロダクトマネージャーの典型 7章　優れたプロダクトマネージャー 8章　プロダクトマネージャーのキャリアパス 9章　チームを構成する 第III部 戦略 10章　戦略とは何か？ 11章　戦略のギャップ 12章　良い戦略フレームワークを作る 13章　企業レベルでのビジョンと戦略的意図 14章　プロダクトビジョンとポートフォリオ 第IV部 プロダクトマネジメントプロセス 15章　プロダクトのカタ 16章　方向性の理解と成功指標の設定 17章　問題の探索 18章　ソリューションの探索 19章　ソリューションの構築と最適化 第V部 プロダクト主導組織 20章　アウトカムに着目したコミュニケーション 21章　報酬とインセンティブ 22章　安全と学習 23章　予算編成 24章　顧客中心主義 25章　マーケットリー：プロダクト主導企業 おわりに：ビルドトラップから抜け出してプロダクト主導になる 付録A　企業がプロダクト主導かどうかを判断する6つの質問
読んだ人のクチコミ	・PdMだけではなく、CxO、エンジニアリングマネージャー、UXD、プロジェクトマネージャーなどプロダクト開発に関わる人みんなに読んでほしい一冊！ ・ビルドトラップという陥りがちな落とし穴がよくわかります ・具体的にどのように目標をたて、方針を作るのかがよくわかります。実務で使える本です。

書評・要約｜プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

まずは『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』で特に重要なポイントを要約し、まとめてご紹介します。

著者の吉羽氏による解説スライドも非常にわかりやすいのでおすすめです♪（本記事でも適宜スライドを引用させていただきます）

ビルドトラップとは？

本書の最大のポイントはタイトルにも含まれている「ビルドトラップ」です。ビルドトラップとは以下のような状態を指しており、ビルドトラップに陥ったプロダクト組織は健全な状態とは到底言い難いものです。

• 組織がアウトカムではなく、アウトプットで成功を測定しようとして、行き詰まっている状態
• 生み出した価値（顧客の問題を解決したか）ではなく、機能開発とリリースに集中している状態

ビルドトラップに陥ると、以下の図ような負のスパイラルに陥ってしまい、「プロダクトの死のサイクル」と呼ばれています。

本当にこれ現場で陥りがちですよね。プロダクトマネージャーとして数年間の経験をした人であれば誰もが一度は経験したことがあると思います。

ここ最近ユーザーインタビューがPdM界隈で市民権を得てきているので以前より起こりやすくなった印象・・・。「ユーザーがこう言ってたからこっちの方が正しそう！」など、すべてをユーザーに委ねる意思決定は一見すると良い手法に見えますが、少しずつ死に向かっていると意識したい。自戒を込めて。（定量も定性もどちらも大事。バランスが大事。）

ビルドトラップの具体的な兆候

具体的な兆候の例としては以下が挙げられます。これらのどれか1つでも当てはまる場合はプロダクト開発組織がビルドトラップに陥っている状態だと考えられます。

• 「機能が少なすぎる！もっとたくさんの機能をリリースするべきだ！」
• ロードマップ通りにリリースしないとボーナスがもらえない
• バックログは30も40も積まれているが、既存の機能を再評価せずに、どんどん機能を追加しようとしている（例：既存機能が2%しか使われていないことに気づけていない、気づいてるが対策していない）
• ユーザーストーリーや仕様書を書くことに毎週何十時間も使っている
• リリースの振り返りをしているが「スケジュール通りだった」「バグがなかった」などで評価しており、そのリリースがもたらした成果（例：顧客の問題を解決した、KPIが上がった etc）を評価していない

あなたの運営するプロダクトはいかがでしょうか？（私も以前似たような状況に陥ったことがあり、今思えばPdM個人として、プロダクト組織としても非常に未熟だったと思います・・・汗）

アウトプット、アウトカム、インパクトについて

なぜ上記のようにアウトプットにフォーカスした状態ではいけないのでしょうか？機能開発やリリースに集中してスピーディーにデリバリーすること自体は悪くないように思います。これについてはアウトプット、アウトカム、インパクト、を切り分けて考えると理解しやすいです。

上記の3つの中で特に重要なのは「アウトカム」や「インパクト」であり、「アウトプット」にフォーカスするのは良くない。なぜなら、最終的にプロダクトを運営する目的はプロダクトによってユーザーの課題を解決したり、その結果KPI等をグロースさせて自社の事業成長をしていくこと（もっと言えばプロダクトビジョンやミッションの実現）であるため。

書いたソースコードの長さ、リリースした回数、リリースした機能の数などは、最終目的を達成する上で重要ではあるものの、それ自体が目的になってはいけないということですね。

ビルドトラップを回避する方法

ビルドトラップの状況やなぜそれが良くないのかわかりましたが、ではどのようにビルドトラップを回避すればよいのでしょうか？本書では以下の7つが提唱されています。詳しい内容はぜひ書籍を実際に読んでみてください。

• 適切なプロダクトマネージャーを配置する
• 適切なチーム構成にする
• 適切な戦略を組織に行き渡らせる（また、計画と戦略を混合しないこと）
• 解決策を考えるまでに、イシューを理解する
• 解決策を探索する（実験をたくさんして学びを深める）
• 適切な指標を定めて活用する（計測する仕組みも用意）
• 組織をプロダクト主導にする

ポイントとしては、上記７つすべてをやりなさい！という話ではなく、自社の状況に合わせて効果が高いところから少しずつ取り組みましょう！ということです。これもプロダクト開発と同じように「小さくはじめて、徐々に拡大していく」ことが良いと思います。

以上が本書の書評・要約セクションでした。これからは学びになった部分をより詳細に紹介していきます！（主に読書メモとなります）

自分が本書を読んで最も参考になった箇所を書評記事では書いているのですが今回は全体的に参考になったので選ぶのが難しいです^^; 要約パートには載せていませんが、某プロダクト戦略立案フェーズから担当した際には戦略フレームワークのパートも非常に役に立ちました。

『プロダクトマネジメント 』の読書メモ

ここからは本書を読んで重要だと思ったポイント、心に留めておきたいと思ったことをテーマ毎に箇条書きで記載していきます！（要約パートでビルドトラップについて詳述したので、ビルドトラップ以外の内容のみ抜粋します）

プロダクトマネージャーの役割

まず、本書で書かれているプロダクトマネージャーの役割のパートはとてもしっくりきました。（以前、「プロダクトマネージャー(PdM)になる方法、役割、スキル、資格、おすすめ本などを紹介」でも紹介をしましたが、それよりもさらに具体的な内容ですね）

• ビジネスと顧客の両方を深く理解し、価値を生み出す適切な機会をみつける（つまり、ビジネス目標を達成できて、顧客の問題を解決できる機能や製品を特定する）
  • ユーザー分析、顧客フィードバック、マーケット調査、実験結果、データ分析結果、ステークホルダーの意見などを総合的に組み合わせて、チームがどこに進むべきか（プロダクトビジョン）を決める
  • なぜそのプロダクトを作っているのか？どんな成果を生み出すのか？を明文化し、チームに共有することも重要な役割
• PMは自分たちが作っているものが正しいことをチームにも会社にも納得させなければいけない（人に影響を与えるスキルが不可欠）
• 何をつくるか決めるために、戦略的で実験的なアプローチを取る必要がある。学習に重点を置いて、リスクを減らすこと。それを指揮するのもPMの仕事。
  • リスクを減らし、悪いアイデアを終わらせることが役割の１つ
• 常に問題に集中すること。「なぜ」から外れないようにすること。
  • 適切なソリューションを考える前に、なぜそれが起こっているのか理解すること
  • 問題の原因を突き止めれば、作るべきものが決められる
  • 逆に解くべき問題がわからない状態、なぜ作るのかわからない状態で、適切なプロダクトを作れるわけがない

よい戦略フレームワークとプロダクトのカタ

本書で紹介されている「戦略フレームワーク」と「プロダクトのカタ」についてです。自分の経験としては戦略フレームワークが過去にプロダクト戦略立案フェーズから携わったときに非常に参考になりました。ビジョン、戦略、課題、施策が紐づくので、チームメンバーに展開するときも説明がしやすいし、納得感が得やすかった印象です。

（参考）戦略についてさらに学びたい人におすすめの記事：「戦略」を学びたい人におすすめ本ランキング！良書・名著を厳選

• プロダクト組織では4つのレベルの戦略展開が必要になることが多い（これを戦略フレームワークと呼ぶ）

• 戦略フレームワークをつくって明文化することによる効果
  • 企業のビジョンや戦略と、チームのプロダクトの整合性が取れるようになる
  • 適切な方向づけがされて、ビルドトラップから抜け出せる
• 戦略展開の４つのレベル
  • ビジョン、戦略的意図、プロダクトイニシアティブ、オプション
• 戦略的意図とは？
  • ビジョン実現につながる現時点での重点分野のこと
  • 上位の重点分野であること
    • 例：新たなマーケットへの参入、新たな収益源の創出、特定分野の収益倍増など
  • 簡潔で、アウトカム重視であること（過程ではなく、結果・成果を重視する）

※戦略的意図の例

意図	目標
エンタープライズビジネスの拡大	３年以内に、年間収益を現在の500万ドルから6000万ドルにする
個人ユーザーからの収益の倍増	個人ユーザーの収益における年次成長率を現在の15%から30%に拡する

※戦略的意図とプロダクトイニシアチブの例

※プロダクトイニシアティブとオプションの例

• プロダクトイニシアティブに数字を入れたver：サイトで関心の多い領域のコンテンツを増やすことで、ユーザー獲得を２倍にし、既存ユーザーのリテンションを70%まで高めることができる。
• オプションに数字を入れたver：講師がより早く簡単に講座を作れるようにすることで、講座の公開率を50%に、２つめの講座の作成率を30%に高めることができる
• メモ
  • リテンション率は遅行指標なので、先行指標としてリテンションに効く指標を設定する必要がある
  • この成功指標にバージョン1で到達しなければ、そこに到達するまで継続的に計測して繰り返す必要がある

プロダクトのカタ：よいプロダクトを作るための科学的かつ体系的な方法

• ４の”問題の探索”フェーズにおいて、顧客が苦痛に感じる箇所とその原因を特定する必要がある

『プロダクトマネジメント 』から学んだPdMの心得

ここまで本書から学んだことをまとめて来ました。最後に自分が特に気づきが多かったこと、これからのアクションに活かしたいことをまとめて終わりとします。良いプロダクト開発組織を作る上で必須となる考え方ばかりです。

• アウトプット、アウトカム、インパクト、を切り分けて考える
  • アウトプット：開発した機能、リリースした回数、書いたソースコードの量
  • アウトカム：顧客の抱える問題の解決、顧客の行動変容など
  • インパクト：組織に与えた（金銭的・事業的な）影響
• アウトプットが最重要なわけではない
  • 多くリリースすれば良いわけではない
  • ビジネス的なインパクト（成果、効果）を出したかどうかが最重要
• アウトプット重視で「とにかくリリースするぞ」となるけど、それは危険かもしれない
  • 機能の開発とリリースに集中している状況はNG（ビルドトラップにハマっている）
  • 機能ばかり出しても、ユーザーは使いこなせない。使われなければどれだけたくさんの機能をつくっても意味がない。
  • たくさん作ることよりも、なぜ作るべきか（WHY）、効果はでるのか（Outcome）、にフォーカスするべき
• 実験をたくさんして学びを深めることに重きを置く
  • 施策の実施回数や、リリース回数を増やすことを目的にしてはいけない
  • 実施した施策やリリースによって何がわかったのか？何を学べたのか？という「学びの総量」が重要
  • 出したけどあまり使われてない機能は捨てることも必要。リリースした瞬間に負債は増える。
  • リリースしてもすぐに壊す可能性もあるという文化形成も必須。これができないと「せっかく作ったから残そう・・」などというユーザーにとっては全く価値の無い意思決定をしてしまう
  • 実験タスクもプロダクトバックログに突っ込んでチームで対応していくべき