ども、らーにゃです。今回は「プロダクト・マネジメント」について言及したいと思います。
商品開発部門で意識しなければいけないことは何か？
時代に合った開発手法の検討、ユーザーの声を取り入れた商品改定、営業の声もいれた機能改修、スピード感をもったリーンスタート、関連組織とのKPIマネジメント…など
とにかく色々なことを検討・調整しなければいけないことが商品開発部門の定めです。
営業経験が長い身からすると、商品開発部門に移り、なんとまぁ考慮すべき見えない変数が多いかという点に驚きます。
じゃぁ、何をやりゃいいのか？
これに対して商品開発部門でやるべきことが分からない人が大半というのが実態です。
この点、この書籍では商品開発部門の人が何をどういう順番で考えて実践すべきかのノウハウが詰まっておりかつ体系的にまとめられております。
そのため、商品部門として何をどの順番でどう考慮すればいいのか？と迷っている人には特におすすめしたい一冊です。
ビビっときたTipsや手帳術を発信します ٩( ᐛ )و
●資格：国家資格キャリアコンサルタント
●実績：手帳歴18年 | 自作歴10年| デジプラ歴1年
●属性：30代2児の父 | 7つの習慣の資格も保有
目次
今回オススメしたい書籍
「プロダクトマネジメント」の概要
プロダクト創りにおいて、何に留意して、どのようなプロセスを踏めばいいかを言及したプロダクトマネジメントに関する書籍です。
本書では、プロダクトマネージャーの役割の定義から始まり、優れた意思決定を促す戦略やプロセス、だけではなく文化や方針までも紹介します。
プロダクトチーム、マネージャー、プログラマ、アーキテクト、デザイナ、マーケター、など何等かプロダクト創りに関わる人は必読の一冊です。
「プロダクトマネジメント」の目次
本書は以下のような構成でまとめられています。
非常に細かく詳細に記載されており良い意味で教科書的な内容です。
■PART Ⅰ プロダクトの成功
Chapter 1 プロダクトの成功とは
1.1 プロダクトの成功を定義する3要素
1.2 プロダクトの成功はバランス
1.3 プロダクトステージごとの成功Chapter 2 プロダクトマネージャーの役割
2.1 プロダクトマネージャーの2種類の仕事
2.2 プロダクトとは
2.3 プロダクトをつくるチームChapter 3 プロダクトマネージャーの仕事とスキルの全体像
3.1 プロダクトを網羅的に検討するための4階層
3.2 プロダクトマネージャーに必要なスキル■PART Ⅱ プロダクトを育てる
Chapter 4 プロダクトの4階層
4.1 プロダクトのCore：ミッションとビジョン、事業戦略
4.2 プロダクトのWhy：「誰」を「どんな状態にしたいか」、なぜ自社がするのか
4.3 プロダクトのWhat：ユーザー体験、ビジネスモデル、ロードマップ
4.4 プロダクトのHow：ユーザーインターフェース、設計と実装、Go To Marketなど
4.5 プロダクトの4階層の中における仮説検証
4.6 プロダクトの方針を可視化する
4.7 プロダクトをつくる心構えChapter 5 プロダクトのCore
5.1 プロダクトが向かうミッションとビジョン
5.2 事業戦略
ケーススタディ：プロダクトのCoreの検討Chapter 6 プロダクトのWhy
6.1 ターゲットユーザーと価値の組合せを選ぶ
6.2 なぜ自社がするのか
6.3 ペインとゲインの仮説検証
6.4 プロダクトのCoreとのFit & Refine
ケーススタディ：プロダクトのWhyの検討Chapter 7 プロダクトのWhat
7.1 解決策を発想する
7.2 何をつくるのか―ユーザー体験
7.3 何をつくるのか―ビジネスモデル
7.4 どのような優先度で取り組むか
7.5 プロダクトのWhyとのFit & Refine
ケーススタディ：プロダクトのWhatの検討Chapter 8 プロダクトのHow
8.1 プロダクトバックログをつくる
8.2 ユーザーにプロダクトを提供する仕組みを整える（GTM）
8.3 リリースの前にすべきこと
8.4 プロダクトのWhatとのFit & Refine
8.5 リリースする
8.6 次の改善のために
ケーススタディ：プロダクトのHowの検討■PART Ⅲ ステークホルダーをまとめ、プロダクトチームを率いる
Chapter 9 プロダクトマネージャーを取り巻くチーム
9.1 代表的な他の役割との責任分担
9.2 プロダクトマネージャーの組織
9.3 「ステークホルダーをまとめ、プロダクトチームを率いる」とはChapter 10 チームとステークホルダーを率いる
10.1 多拠点がある場合の情報共有で注意すべきこと
10.2 プロダクトに関する情報の透明化
10.3 チームビルディングChapter 11 チームでプロダクトをつくるためのテクニック
11.1 ドキュメンテーション
11.2 コーチング
11.3 ファシリテーション
11.4 プレゼンテーション
11.5 ネゴシエーション■PART Ⅳ プロダクトの置かれた状況を理解する
Chapter 12 プロダクトステージによるふるまい方の違い
12.1 プロダクトのライフサイクルの捉え方
12.2 ステージごとの違いを理解するChapter 13 ビジネス形態によるふるまい方の違い
13.1 BtoCプロダクト
13.2 BtoBプロダクトChapter 14 未知のビジネスドメインに挑む
14.1 なぜビジネスドメイン知識が必要なのか
14.2 未知のビジネスドメインに挑むときのふるまい方―グローバル展開
14.3 未知のビジネスドメインを学ぶ方法
14.4 ドメイン知識をプロダクトチームで理解する
14.5 ビジネスドメインの法規制を理解するChapter 15 技術要素の違いによるふるまい方の違い
15.1 ハードウェアプロダクト
15.2 AIプロダクト■PART Ⅴ プロダクトマネージャーと組織の成長
Chapter 16 プロダクトマネジメントと組織
16.1 プロダクトマネジメントを組織に導入する方法
16.2 プロダクト志向組織への移行ステップ
16.3 ジョブディスクリプションにより責任範囲を明確にするChapter 17 プロダクトマネージャーのスキルの伸ばし方
17.1 プロダクトマネージャーになるための方法
17.2 プロダクトマネージャーとしてのスキルの育て方
17.3 プロダクトマネージャーに求められる知識の適度な深さとは
17.4 知識やスキルをアップデートする方法
17.5 W型モデルで自分のスキルをマッピングしてみようChapter 18 プロダクトマネージャーのキャリア
18.1 プロダクトマネージャーの肩書と役割
18.2 プロダクトマネージャーを務めたあとのキャリア■PART Ⅵ プロダクトマネージャーに必要な基礎知識
Chapter 19 ビジネスの基礎知識
19.1 収益、コスト、ビジネス環境の基礎知識
19.2 パートナーシップを構築する
19.3 指標を計測し、数字を読む
19.4 知的財産の扱いChapter 20 UXの基礎知識
20.1 UIデザイン、UXデザインの基礎知識
20.2 マーケティング施策
20.3 プライバシーポリシーと利用規約をつくるChapter 21 テクノロジーの基礎知識
21.1 プロダクトの品質を保つ
21.2 開発手法の基礎知識
21.3 ソフトウェアの基礎知識
21.4 セキュリティを強化するAppendix 1 プロダクトマネージャーのためのセルフチェックリスト
「プロダクトマネジメント」本書より
Appendix 2 プロダクトの4階層とフレームワークの対応表
Appendix 3 推薦図書と講座
目次を読み込むだけでも留意すべき観点が体系化されており学びになります
個人的ポイント
上記で示した通り、非常に網羅的に記載があるので、目次を読んでいるだけでも、何をどの順番で考えるべきかがわかり学びが多いです。
非常にボリューミーな内容ですが、この中でも特に個人的にこれは実践せねば！と思った内容を下記にまとめていきます。
- 全ての起点はユーザーのアウトカム
- プロダクトビジョンでビルドトラップを回避
- 良い戦略フレームワークを創る
順にふれていきます。
全ての起点はユーザーのアウトカム
本書で一貫して起点になるポイントは「アウトカム」という概念です。
これは、本書でも以下のように記載がされています。
アウトカムとは私たちが機能を届けて、顧客の問題を解決したという結果のことです。本当の価値はビジネスにとってもユーザーや顧客にとっても、これらのアウトカムの中で実現されます。
「プロダクトマネジメント」本書より
これは当たり前のように思うかもしれませんが、こんな内容もでてきます。
企業の多くはアウトプットモードにはまっていました。彼らの組織全体がアウトプットを増やすように最適化されています。プロセスは締め切りや、リストにある機能にできる限りたくさんチェックを入れることを中心においています。
チームはたくさん作ることで評価されています。方針は、チームにたくさんのコードを書かせたり、たくさんの機能をリリースしたりするように仕向けるために存在していて、顧客と話すといった労力はムダだと見なされます。
「プロダクトマネジメント」本書より
つまり、多くの場合、”アウトカム”ではなく”アウトプット”を追いかけがちという点を指摘しており、これはナンセンスだということを示しています。
アウトプットを追うのではなく、ユーザーのアウトカムに寄与しているかしていないか。
この思想がベースであり、むしろアウトカムだけを突き詰めていけば後は自ずと芋づる式に整理されるという考えです。
この考え方は、当たり前のように聞こえますが、実際に事業運営の商品開発の責任者をやったり、それを売る営業のリーダーをやったりする経験を振り返ると、全然できていない事実に愕然とします。
本書では大企業などではあるある過ぎて死にたくなるようなダメ事例・失敗事例も多く出てきます。
この点、イノベーションが生まれずに苦しむ日本の大企業などでよくありそうな事例が多く、悲しいことに第一章から悪い意味で共感しまくりでした。
分かっちゃいたけど、出来ていないという人は割と多いのではないでしょうか。
プロダクトビジョンでビルドトラップを回避
ではどうやったらアウトカム中心のプロダクトマネジメントができるのか？
それに対する一つの解は下記のように記載されています。
どの会社も同じ問題を抱えていました。すなわち、多すぎるプロダクトと一貫したビジョンの欠如です。ある会社は個々の顧客の要求を満たすために単発のプロダクトを開発していましたが、幅広い顧客には対応できませんでした。
（中略）
プロダクトビジョンは、なぜあなたが作っているのか、顧客に対する価値提案が何なのかを伝えます。アマゾンは、あらゆるプロダクトビジョンについてプレスリリースの文書を作ることで、これをとてもうまくやっています。
プロダクトビジョンはユーザーの問題解決に関する実験から生まれます。ソリューションが適切であることを検証できれば、それを拡張性と保守性に優れたプロダクトに成長させることが可能になります。
「プロダクトマネジメント」本書より
起点はユーザーのアウトカムであり、それを踏まえたプロダクトビジョン創りと、これを元に関連者を束ねていくというのがポイントです。
つまり、商品開発の責任者がプロダクトビジョンを定義し発信し、組織のイニシアチブを握っていくことが、最重要の項目です。
ただ、現状の企業に目を移すと、
商品サイド：
▷「これだけ使いやすくしてんだから早く売れ」
営業サイド：
▷「売れるためにもっとココを、こう改善しろ」
みたいな水掛け論になるケースがよくある話で、見ている視点がズレているというのもよくある話です。
確かにUI的な使いやすさと、売上としての金額とどちらも経営する上で大事な観点ですが、みている点がズレていれば協調して進めることはできません。
それによって起きる問題としてはは下記の記載があります
問題はアイディアやプロダクトが良くないことではなく、プロダクトが成功に向けて成長し続けられるような会社になっていないことです。
本当の価値を創出して維持するのに必要な役割も戦略もプロセスも方針も組織にはなかったのです。
「プロダクトマネジメント」本書より
本書ではこの状態によって組織内で論点がズレて水掛け論になることをビルドトラップと定義しています。
このビルドトラップという考え方は冒頭に具体例も含めて記載されているのですが、読めば読むほど、身の回りにありすぎて悲しくなってきます。
ただ、唯一これを解決できうる糸口になるのが先にあげたプロダクトビジョンです。
ユーザーのアウトカムを最大化するために、この商品はなぜあるのか？という点から関連各所と目線を揃えるのが、遠回りに見えて近道です。
確かに何事も目的やビジョンがないと目指す方向性がまとまらないよね
良い戦略フレームワークを創る
では、進め方はわかったにしても、どのように日々・改修改善を繰り返して断続的に進化をさせるべきか。
この点では、下記のような手法が紹介されています。
優れた企業戦略は2つの要素から構成されます。１つは運営フレームワークで、日々の企業活動を進めていくためのものです。もう1つが戦略フレームワークで、プロダクトやサービス開発を通じて、企業のビジョンをっ実現していくためのものです。
多くの企業がこの2つのフレームワークを混同して、1つのものとして扱っています。両方とも重要ですが、素晴らしいプロダクトやサービスを作るには適切な戦略フレームワークが必要不可欠です。
「プロダクトマネジメント」本書より
つまり、正しい独自のフレームワークを確立しておきましょうということです。
それでは、例えばどんなものがあるのか？
本書では多くの具体例がでていますが個人的になるほどとなったのが以下の事例です。
Spotifyのコンサルティングをしていたヘンリック・クニベルグによると, Spotifyでは「賭け」が思考の中心にあるそうです。SpotifyはData(データ), Insight(インサイト), Belief(信条), Bet(賭け)の頭文字をとったDIBBと呼ばれるものを使って運営しています。
最初の3つは「賭け」の部分の仕事に影響を与えます。イニシアティブを書けと考えることで、別の形の期待を設定するようになります。Spotifyでは必ずこれを作るべきだと上層部がきめることはありません。そうすることでイノベーションを維持しています。
マネージャーは、ハッカソンに参加したり、アイディアを実行したりする自由を従業員に与えています。新しいことを試して失敗できる安全な環境を作っているのです。上層部は顧客が求めているものに不確実性があることを喜んで受け入れていて、そうすることで、実験とイノベーションを加速し、必要であればすぐに軌道修正できるような環境を作ります。
「プロダクトマネジメント」本書より
とても便利なサービスだなと思っているSpotifyですが、プロダクト側の企画や運営においては実はこういった見えないスゴみがあるわけですね。
やはり成功を収めている企業やサービスは、勝つべくして勝っているのだなと改めて感じます。
特にポイントになってくるのは、独自のフレームワーク（上記の場合DIBB)が合言葉としての社内での共通言語になっており、上層部も例外なくそれを守っているという点ですね。
そして当然そのフレームワークのコアにあるのはユーザーのアウトカムです。
ユーザーの思考の変化があることを前提に色々と実験して確かめる風土・文化になっている点がすごいなと感じる点です。
自分の組織でもどのような共通言語が作れるか、これは所属組織によってマチマチかと思いますが、一考の価値があると思います。
共通言語って言われてみるとコレといったものはないかもしれないですね
まとめ
上記の通り、この本を読んで印象的であったのは以下の3点です。
- 全ての起点はユーザーのアウトカム
▷アウトプットとアウトカムの混同に注意する - プロダクトビジョンでビルドトラップ回避
▷顧客に対する価値提案を明文化して水掛け論を防ぐ - 良いフレームワークを創る
▷組織独自の共通言語を創りそこから独自の風土を創る
以上です。
プロダクトマネジメントは一見、商品開発の1部門に特化したような話に見えますが、実際には経営の意思決定まで関わってくる話です。
今後、プロダクトが小さく早く世の中に出てくる世の中を想定すると、商品開発は誰もが関わるような身近なものになると想定できます。
そのため、上記の考え方は今後だれであっても押さえておいて損がない内容だと思いますし、今の組織の違和感の根本に気づくこともできます。
そのため、今回言及したポイントを押さえ、商品の価値定義を行い、関係者と適切な連携をしてよりよい良い仕事をしていきましょう！！(‘ω’)ノ
ご精読頂きありがとうございました。
m(_ _)m
【参考】おすすめ名著×Audible活用
下記に誰であってもこれは抑えておくべき！と感じるビジネス書の名著をまとめています。
効率よく抑えるべき書籍を抑えたい！と感じるビジネスマンの方は合わせてご確認ください！٩( ᐛ )و
また「名著」×「Audibleでながら読書」は効率も良いので忙しい社会人にはオススメです！
特に、無料体験の間に興味がある本をタダ読みしきっちゃうのがオススメ！
