プロダクトマネジメントの名著の1つである「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」今さらながら読んだので、その学びをまとめようと思います。
プロダクトマネージャーは必読の1冊だと思いますので、まだ読んでいない方はぜひ読んでみていただきたいです。
本書では架空の会社の中ではじめは全然うまくいってなかったプロダクトマネジメントがうまく機能するまでの過程が物語風に書かれているため、自分（自社）の状況と照らし合わせたり、自分がその立場にいるような感じで読み進めることができます。とても読みやすかったです。
上のリンクからAmazonのページに飛べます。
ビルドトラップとは
本書のタイトルにも入っている「ビルドトラップ」とは組織がアウトカムではなくアウトプットで成功を計測しようとして行き詰まっている状況と定義されていました。
アウトプットとアウトカムについては以下の記事でとてもわかりやすく解説されていたので、よくわからないなという方は合わせて読んでいただくと良いかなと思います。
アウトプットは「自分が」出力したもの。アウトカムは「顧客に」起きた変化です。
「今さら聞けない「アウトプット」と「アウトカム」の違い」より引用
僕は以下のように捉えています。
- アウトプット：作ったもの（例：プロダクトそのもの、機能そのもの）
- アウトカム：それにより得られた成果（例：顧客にもたらす価値・利益、自社が得られる価値・利益）
開発シーンでは機能の詳細ばかりを考えてしまい、機能が生み出すアウトカム（成果）を見失ってしまうことがよくあると書かれていました。（どんな機能を作れるか？いつリリースするのか？など）
確かに途中で手段が目的にすり替わってしまう現象はあるあるだよなーと思いました。（自戒です）
本書では、なぜビルドトラップがダメなのか、ビルドトラップに陥られないようにするためには何が必要なのかなどについて詳しく解説されていました。
なぜビルドトラップがダメなのか
それは、プロダクトの価値は誰かの課題を解決したり、要望（ニーズ）を叶えることだからです。
プロダクトそのもの自体には本質的な価値はありません。
機能がたくさんあってもそれらの機能がユーザーの課題を解決できないのであればその機能には価値がないということになります。
なので開発を進める中である一定期間の中で1つもしくは複数の機能をリリースしていきますが、その振り返りは
- どれくらいの数の機能をリリースできたのか
- 期限に間に合ったのか
などではなく
- どれくらいのユーザーの課題を解決できたのか
- ユーザーの課題をどれくらい深く解決できたのか
- 自社の売上はどれくらい上がったのか
で評価すべきです。
機能そのもの（＝アウトプット）を計測・評価してもプロダクトは成功には近づかないため、ビルドトラップに陥ることを避けるべきです。
ビルドトラップを避けるためには
ビルドトラップを避けるためにはチーム全体が顧客の課題の理解とアウトカムに向き合うことが大切です。
僕は「顧客第一でプロダクトマネジメントを進めていく」ことだと認識しました。（かなり抽象的ですし、プロダクトマネジメントってそもそもそういうものでしょという感じですが…）
まずは、現状を知るためにデータを収集し、プロダクトの問題（改善したい数値）を見つけます。
問題を見つけたら、その問題が発生している原因を探るために顧客と話し、声を聞きます。（アンケート、インタビューなど）
そのときに顧客の声を鵜呑みにするのではなく、そのバックグラウンドにはる本当の課題（ペイン）を探ります。
問題の原因に仮説を立てたらその仮説を検証していきます。（仮説の検証方法として「コンシェルジュ」「オズの魔法使い」「コンセプトテスト」が紹介されていました。詳細は本書を読んでください）
僕は現職で「コンシェルジュ」「オズの魔法使い」は経験があります。
検証して「いける！」と判断したらようやく開発に移ります。機能をリリースする前には「どうなれば成功か？」を計測するための指標を設定することが重要です。（定量的なものがベスト）
リリースしたら別の課題に取り掛かるのではなく、現在取り組んでいる課題の数値が改善するかをモニタリングし、改善してなかったら再度その原因分析に戻り、改善を試みるべきだと書かれていました。
この”指標”について、既存プロダクトでユーザーのデータを集計・分析できる場合はその数値改善だとイメージしやすいですが、新規プロダクトの場合はどうなるんだろう？BtoCの場合はユーザー数、BtoBの場合は契約数とかになるんだろうか？と個人的な疑問があります。BtoBのプロダクトの場合、MVP時点では定量的な指標ではなく、自分達が持っている定性的な仮説の検証が出来たかどうかを指標としても良いのではないかと思っています。
プロダクトマネージャーの役割や仕事に関する記載
本書では至るところにプロダクトマネージャー（以下、PdM）の役割や仕事に関する記載があったので箇条書きでまとめておきます。
- 開発チームとビジネスを結びつけて、要求を集めて実際に使う機能に翻訳する
- 顧客の具体的な問題を解決する視点を持ちつつ、ビジネス目標を達成するためのプロダクト開発を最適化する
- ミニCEOではない（人に対する権限がない）
- PdMの仕事は「価値を生み出すこと」であり、「自分のアイディアを形にすること」ではない
- 「なぜ」に責任を持つ（プロジェクトマネージャーは「いつ」に責任を持つ）
- なぜこれを作るのか？
- どうやって顧客に価値を届けるか？
- ビジネス目標を達成するうえでどのように役立つか？
- 「なぜ今その仕事に取り組んでいるのか？」には必ず答えられないとダメ！
- 課題を見つけたらその解決に適切なソリューション（機能）を考えるのではなく、なぜその課題が起こっているのかを理解することが重要
- 多くのPdMが顧客と話す量が不足している
- 大きなアイディアを生み出すことではなく、悪いアイディアを終わらす（捨てる）ことが大切
- 謙虚でいるべし、信頼されるべし、好かれるべし
いずれも大切だなーと思いますし、自分にはまだまだ足りていないところがたくさんあるなーと思いました。
エンジニア→PdMというキャリアなので、開発サイドのスキル（エンジニアリング、UXデザイン）はまだマシですがビジネスサイドのスキル、経験が悲しいレベルなので今後の課題ですね。（個人的にはマーケに染み出したい）
作業の優先順位のつけ方
本書では、作業の優先度付けはPdMの最大の課題であると書かれています。
僕も日々悩んでいます。
本書では以下の作業の優先度を決めるためのフレームワークとして以下の3つが紹介されていました。
- ベネフィットマッピング
- 狩野モデル
- 遅延コスト（これがおすすめされている）
遅延コストは緊急性と価値の組み合わせを可視化することでプロダクトに対するインパクトがわかるようになり、優先順位をつけることに役立ちます。
弊社では優先順位付けにはRICEスコアを使っていて、他のフレームワーク（方法）のことはそこまで知らなかったので、単純に色々な方法があるんだなと思いました。
PdMをやっていくなら「作業の優先順位付け」1つとっても色々な引き出しを持ったうえでどのようなフレームワークを使うのか、現状の最善を選択できるようになりたいです。
遅延コストについての記事もあったので一応貼っておきます。
狩野モデルについて良く聞きますが、別の記事に説明は委ねようと思います。
※ベネフィットマッピングはググってみたものの、目ぼしい情報がヒットしませんでした…
企業が”プロダクト主導組織”になることも大切
本書では組織の特徴として以下の4つを挙げており、プロダクト主導以外の組織はビルドトラップに陥りやすいと説明されています。
- セールス主導組織：プロダクト戦略が契約によって決まる。顧客の要望を優先してしまい「言いなり」になってしまう。
- ビジョナリー主導組織：創業者だけがプロダクト戦略を考えて、他のメンバーはそれについていく（スティーブ・ジョブズ時代のApple）。上手くいけば良いが、トップが変わったときに成長を継続できない可能性が高い。
- テクノロジー主導組織：革新的な・新しい技術を使うことを優先してプロダクト開発を作ってしまう。マーケットを踏まえてどのようなプロダクトに価値があるのかの考慮が欠如する。
- プロダクト主導組織：ビジネスに対するアウトカムを軸にし、自分達の目標（ビジョン）とベースにプロダクト戦略を調整する
ビルドトラップに陥らないようにするために企業がプロダクト主導組織になるためにどのようなマインドセットだったり社風、制度等が必要なのかは本書で詳しく説明されていました。
本記事では”企業がプロダクト主導になっているかどうかを確認するための6つの質問”が書かれていたので、紹介させてください。
最後に作った機能やプロダクトのアイディアを思いついたのは誰か？
チームの誰に聞いても「チームで考えた」と答える組織が最高です。アイディアが上から降ってきたからそれに対応しているだけ（ビジョナリー主導ですね）だったり、なぜ今それを作っているのか答えられない場合は危険信号です。
最後に廃止を決めたプロダクトは何か？
達成したい目標に役立たないプロダクトやアイディアを捨てることも重要です。それができていないのであれば危険です。本書でPdMは「大きなアイディアを生み出すことではなく、悪いアイディアを終わらす（捨てる）ことが大切」と書かれているのがリンクしますね。
顧客と最後に話したのはいつか？
これは言わずもがなですね。自分自身、「あれ、最後に話したのいつだっけ…？」とならないようにしたいです。中には週に1回は必ずユーザーインタビューしている会社があるみたいなので見習いたいです。
目標は何か？
PdMの目標は「顧客の価値を創造すること」「ビジネス価値を生むこと」です。もし目標がないのであれば、アウトプット重視（＝ビルドトラップ）になっているかもしれません。
現在何に取り組んでいるのか？
この質問に対して「xxの機能を実装しています」ではなく「顧客のxxという課題の解決に取り組んでいます」と答えられるのがベストです。僕はこういう質問をされることがないのですが、前者の方で答えてしまう可能性もあるなーと思ったので、常に顧客視点を持って社内外でコミュニケーションしたいです。
PdMはどんな人か？
これはPdM以外の開発チーム（エンジニア、UXデザイナーなど）への質問で、PdMが信頼されているか、好かれているかによってプロダクト主導組織になっているかを確認できます。
最後に
本書では架空の会社がプロダクトマネジメントを機能させていく過程をかなり具体的な内容・数値を用いて書かれているのでかなり実務に結びつけやすいなと思い、読んでよかったです。
プロダクトマネジメントの名著の1つである「プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで」もとても良い書籍だと思いますが、割と概念だったり表面的な内容が多いので、本書の方がより実務に結びつけやすいなという感想です。（どちらも必読だと思います）
また本書の内容が結構具体的なので、PdM2年目の今読んで結果的にはよかったのではないかと思います。とても共感できることがあったし、うわ…自分もできていないや…と思うこともあったしかなり学びになりました。逆にPdMなりたての時に読んでもいまいちイメージ湧かなかったかもしれません。
（PdMになりたてのときは「プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで」の方がよりおすすめだと思います）
最後に、なんでKindle版ないんや…
コメント