#book #r2022  # なぜこの本を読んだか 最近、本業で新規にサービスを開発をしていたので改めてプロダクトマネジメント周りの知識をアップデートしたかったから。 # 何が書かれている本か 顧客への価値 (アウトカム) ではなく、リリース数や機能数などアウトプットに着目してしまった結果ユーザーが欲しいものが継続的に作られないプロダクト、チーム、組織になっているような状態 (ビルドトラップ) を避けるにはという本 > ビルドトラップとは、組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況のことです。 これが全てって感じの本 > プロジェクトは、プロダクト開発の欠かせない一部ではありますが、プロジェクトだけ考えるという発想は悪影響を及ぼします。 > プロダクトは育てていく必要があるもので、成熟に向けて成長していきます。これには時間がかかります。プロダクトを強化する機能をリリースすることは、この全体的な成功への貢献を意味します。機能の強化自体はプロジェクトですが、それが終わってもあなたの仕事は終わりません。全体的なアウトカムを実現し成功に至るまで、新しいプロジェクトを決めて、繰り返しやっていく必要があるのです。 [https://tomoima525.hatenablog.com/entry/2021/12/20/074026](https://tomoima525.hatenablog.com/entry/2021/12/20/074026) にも通じるところがある # メモ ## 企業のありかた ### セールス主導 - プロダクトロードマップと方向性は、顧客への約束によって決まる - e.g. 営業が強い会社とか ### ビジョナリー主導 - ある特定のワンマンがプロダクトロードマップと方向性を決める - e.g. スティーブジョブスがいた Apple とか ### テクノロジー主導 - 最新のクールなテクノロジーを軸に進む - e.g. VR, ARとか ### プロダクト主導 - ビジネスアウトカムを軸に最適化し、プロダクト戦略を自分たちの目標に合わせて調整する - プロダクトの持続的な成長の原動力になるような一番効果的なプロジェクトに優先して取り組みます ## プロダクトマネジメントとは > プロダクト開発は不確実性に満ちています。事実と、学習する必要があることを分離するのが重要です。  つまり「既知に既知」から初めて「未知の未知」を減らしていくということが重要 悪い プロダクトマネージャーの典型 - ミニCEO - プロダクトに対してリードする責任と権限はあるが、ビジョナリーになる (思い通りにする) ことが仕事ではない - ウエイター - 全てを聞くだけで意思決定を行わない - プロダクトの死のサイクルに陥る危険がある -  ### プロダクトマネージャーの仕事領域 - 戦術的な仕事 - 機能を作って世に出すという短期的な行動 - 戦略的な仕事 - マーケットで勝利して目標を達成するためのプロダクトや会社のポジションを考える - 運営 - 戦略と戦術を結びつけるためにロードマップを作成したりなどの登り方を考える ### 戦略とは？ - > 戦略とは実行可能な意思決定のフレームワークであり、現在のコンテキストとの整合性を保ちながら、現在の能力の制約のもとで望ましいアウトカムを達成するための行動を可能にするためのものである。 - > The Art of Actiion - 例えば、自分以外のメンバーが意思決定を下す際の根拠になるようなもの - 命令を上から下に流していくのではなく、それぞれの階層でなぜそれが必要なのかの認識をそろえて、どうやってそれを実現するのかは下の階層に任せて報告してもらうようにすべき - 最上位のリーダーたちが足並みが揃っていなければ、問題はチームにまで普及します ## プロダクトのカタ  以下の質問を意識していく 1. 目標は何か？ 2. 目標を踏まえて、自分たちは今どこにいるのか？ 3. 目標に到達する上で立ちはだかる最大の問題や障害は何か？ 4. どうやってその問題を解決するか？ 5. 何が起こると予想されるか？ (仮説) 6. 実際には何が起こったか、そこから何を学んだか？ ## プロダクトの指標 ### AARRR - Aquision - Activation - Retension - Referral - Revenue ## HEART - Happiness - Engagement - Adaption - Retension - Task Completion ## 問題の探索 - 検証的調査 - ユーザーが簡単にソリューションを使えるかどうか (仮説も問題もわかっていてソリューションの検証に使う) - 生成的調査 - 解決したい問題を見つける ## 学習のための実験 何かを作るときには２つのモードがある - 学習のために何かを作る - 作ったものは最終的に廃棄して、うまくいったのであれば、持続的でスケール可能なやり方を見つけなければいけない - 収益のために何かを作る MVPの誤解 - MVPは「リーン・スタートアップ」の本の中で「学習のために何かを作る」に分類されているにもかかわらず理想的な状態を目指そうとする。 - どちらかとえいば、ソリューションを検証、実験可能な最小の形という意味 - 筆者は、「学習のための最小の労力」と定義している ### 実験の方法 - コンシェルジュ - 実際に手動でユーザーと蜜なコミュニケーションを取って対応する - オズの魔法使い - コンシェルジュに近いが、手動でやっていることを悟られないようなインターフェースにする - つまり - [https://www.youtube.com/watch?v=sfmwAvZuNvs](https://www.youtube.com/watch?v=sfmwAvZuNvs) - コンセプトテスト - コンセプト動画などを見せることで反応を見る こういう実験が必要ない場合もある。こういった実験はあくまでも不確実性が高くて大きな開発リソースなどが無駄になってしまうようなリスクを避けるためにある。実装のコストが小さく、ABテストなどで実際に実装してしまえばいいような場合には実験は不要となる。 (ABも実験の一種ではあるが) `学習は「未知の未知」を減らし、リスクを軽減する` ## プロダクトが大きくなってきたら 「プロダクトオペレーション」という全てのプロダクトマネージャーが共通でするような仕事や共通の指標、言葉で会話ができるように社内横断で合理化するような業務を導入すると良い # 感想 - プロダクト作りをしている人全員に理解して欲しい1冊という感じだった - 架空の会社をベースにビルドトラップに陥った企業を改善していくというのが理解しやすかった - プロダクトマネージャーでこういうことを理解していなかったら、この本を送りつけることにした