Appearance
INSPIRED 読書メモ
プロダクトマネジメントのベストプラクティスを俯瞰し、チームが解決すべき問題に集中するための考え方とテクニックを整理したメモ。
プロダクト開発の基本姿勢
- UX は製品そのものだけでなく、導入・サポートを含む体験全体を指すと捉える。
- 「リーンに進めている」つもりでも、利益やコストの見積もりが不正確なままウォーターフォール型に陥りがち。最もコストがかかるのはアイデア検証であることを自覚する。
- リスクは後回しにせず最初に潰し、職能を縦割りにせず協調して進める。目標は機能開発ではなく問題解決。
- MVP は製品ではなく仮説検証用のプロトタイプと捉え、最小限の工数で学びを得ることを目的にする。
- プロダクトマネージャーは顧客生涯価値 (LTV)、ARPU、顧客獲得費用 (CAC)、売上原価、貢献差益などのマーケティング指標を理解して意思決定する。
- ホリスティックなユーザー体験を重視し、アイデアが固まったタイミングだけでなく毎週ユーザーテストを回す。
開発チームとロードマップ
- 機能を羅列したロードマップには、以下の課題がある。
- 価値・ユーザビリティ・技術的実現可能性・ビジネス実現性の欠如を見逃しやすい。
- 失敗した際にステークホルダーへ責任転嫁し、問題の根本に向き合えない。
- アウトカムベースのロードマップに切り替え、解決すべきビジネス課題と期待する成果で優先順位を語る。チームは機能デリバリーではなく成果創出までを担う。
- ハイインテグリティーコミットメント：早期の確約を避け、まずディスカバリーで実現性を確かめたうえで約束する。確度の高い期日策定にはデリバリーマネージャーの関与が欠かせない。
製品ビジョン (Chapter 24)
- 製品ビジョンは 2〜5 年先の未来像を描き、ステークホルダーが参加したくなる物語である。ミッションステートメントが語らない「どう実現するか」を提示し、人の心を動かすことが目的。
効果的な製品ビジョンの 10 原則
- WHY から始め、チームの存在意義と目的を明確にする。
- 解決策ではなく顧客の問題に恋をする。
- 臆せず大きな視野で構想し、野心的なゴールを描く。
- 変化を恐れず、チームを意図的に揺さぶって現状維持バイアスを打破する。
- 心を揺さぶるストーリーで語り、メンバーを伝道師にする。
- 意味のあるトレンドを見極め、顧客価値に結び付く形で取り入れる。
- 変化の速度と不変要素を見極め、未来に向かって滑る姿勢を持つ (Skate to where the puck is going)。
- ビジョンには頑固に、詳細には柔軟に。進路調整を恐れず実行する。
- ビジョンは大胆な賭けだと捉え、情熱を共有できる人材を集める。
- 伝えすぎることはない。粘り強く説得し続け、恐れや不安を払拭する。
OKR (Chapter 28)
- Objectives は定性的に方向性を示し、Key Results は定量的な成功指標で測る。双方を揃えて初めて「成果に集中する仕組み」になる。
プロダクトディスカバリー (Chapter 33 以降)
- プロダクトディスカバリーは「必要とされるカスタマーソリューションを細部まで発見し、リスクに対処するプロセス」。
- 4 つのリスクを同時に扱う。
- 価値リスク：顧客が買う／使うか。
- ユーザビリティリスク：顧客が使いこなせるか。
- 技術的実現可能性リスク：開発できるか。
- ビジネス実現性リスク：事業として成立するか。
- 原則
- 顧客に解決策を尋ねない。ニーズは顕在化しておらず、既存製品は多数ある可能性の一つに過ぎない。
- 最も説得力のある価値命題を見つけることに時間を注ぐ。
- 機能・デザイン・技術が密接に絡み合うため、職能の壁を越えて物理的に近くで協働する。
- アイデアの妥当性は顧客で検証し、問題に恋する姿勢を保つ。
- Amazon の Working Backwards では、プロダクトマネージャーが発売時のプレスリリース (または顧客の手紙) を起草し、顧客価値と成果へのフォーカスを徹底する。
- リファレンスカスタマーを最低 6 社確保できなければ、プロダクト・マーケット・フィットは達成できていないと判断する。
検証テクニック集
ストーリーマップ (Chapter 38)
- ユーザーストーリーの羅列では全体像が見えにくい課題に対し、主要ユーザーアクティビティを横軸に、詳細ストーリーを縦軸に配置して流れを把握する。ジェフ・パットン著『ユーザーストーリーマッピング』が出典。
コンシェルジュテスト (Chapter 42)
- 自動化前に手動でサービス提供し、顧客価値を検証する。顧客の不適切な使い方も洞察として捉える (Chapter 43)。
オズの魔法使いプロトタイプ (Chapter 49)
- 顧客には完成品のように見せながら、裏側で人が手動処理するプロトタイプ。実装コストを抑えつつ体験を検証できる。
需要テスト (Chapter 52)
- フェイクドア (偽扉) でクリックした顧客から興味を測る、ランディングページで需要を測るなど、実際の行動データで関心を計測する。
デザインスプリント (Chapter 58)
- Google Ventures が提唱する 5 ステップ。
- 問題空間をマップし、挑むべき問題を決める。
- ソリューションの幅を広げる。
- 有望な案に絞り込み、具体化する。
- 高忠実度のプロトタイプを作る。
- ユーザーテストで学びを得る。
- 『SPRINT 最速仕事術』はプロダクトマネージャー必読の参考書。
組織をロードマップから切り離す (Chapter 60)
- ステークホルダーがロードマップに執着する理由は、(1) チームの取り組みを可視化したい、(2) ビジネスプラン作成のため重要イベントの時期を知りたい、の二点。
- 代替として、リーダーシップが優先付けたビジネス目標にチームが取り組み、期日が必要な場合はハイインテグリティーコミットメントで責任を負う。
- 組織がアウトカム思考に移行すると、ロードマップは成果を語る手段となり、開発チームは「何を作るか」より「なぜ作るか」に集中できる。