投稿元：
レビューを見る
原著は Melissa Perri さんが書かれた Escaping the Build Trap: How Effective Product Management Creates Real Value です。翻訳は 吉羽 龍太郎 さん。
プロダクトマネジメントを扱った書籍はいろいろありますが、この本は「ビルドトラップ」というワード（プロダクト開発において、価値を生み出すことより機能開発とリリースすることに重きを置いてしまう現象）が全体的なテーマになっています。このビルドトラップから抜け出すには、あるいは嵌らないようにするにはどうすればいいか。マーケットリーという架空の自社サービス会社を舞台に、カオスな状態からアウトカム主体の企業になっていく過程が物語調で進んでいきます。ノウハウが列挙されているような書籍と比較して読みやすく、現場でよくありがちな場面も多く出てくるため、実際にアクションに移していく際のイメージも湧きやすいと思います。
投稿元：
レビューを見る
https://daisuki.nichiyoubi.land/entry/2020/10/28/135852
投稿元：
レビューを見る
アウトプットではなくアウトカム。頭では理解しているはずなのに、またぞろアウトプット志向のものづくりをしている。これ、誰が何のために使うのだったかしらー。そんな経験があるのであれば、職位がマネージャーであろうと経営者であろうとエンジニアであろうとデザイナーであろうと、一読の価値がある一冊だ。
アウトプット志向に陥る構造的な欠陥（ビルドトラップ）は身につまされる。
年度末に予算を使い切るための忙しさが発生する、アウトプットで評価されるからとにかく物量をこなすー。それで得られたものはいくばくかの日銭以外に、なにかあっただろうか。それさえも結局、未来からの前借り金だ。
アウトカム志向を貫こうとする中で、我々は自然とUX、リーンスタートアップ、アジャイルと出会うことになる。本書がオライリージャパンからの出版であることも頷ける。
投稿元：
レビューを見る
陥りがちなビルドトラップに陥らないためにどうすれば良いかの指南書。
学んだこと
・戦略をタームで考えること
開発チームは2~4週間のストーリーが得意
リーダー、マネージャーは四半期〜年単位のストーリーが得意
CxOは5年単位のストーリーが得意
・良いアイデアを形にすることより悪いアイデアを捨てることが大事
・問題を解決するのは顧客の仕事ではない、適切な質問をするのが自分の仕事
「なぜそのボタンがここに必要なのですか？」
・MVP=学習のための最小の労力（解像度をあげる営みと認識）
・予算はVC風につける（学習した組織に次のラウンドの資金調達がごとくつける）
投稿元：
レビューを見る
副題から主旨が想像つくが、そう安易な内容ではない。あまり具体的な進め方まで解説しないので、プロダクトマネージャになったばかりの人やこれから目指す人にはかなりハードルが高いだろう。
すぐに実践できなくても将来に目指すべき方向づけとしては有益かもしれない。
この分野の書籍は少ないので、しっかりした指針を持った本はありがたい。
投稿元：
レビューを見る
顧客中心主義のプロダクトマネジメントについて書かれた一冊です。
マーケットリーという架空の企業の物語を交えつつ、顧客中心主義でない場合のよくある失敗や、顧客中心主義で進める場合のプロダクトマネージャーの役割、戦略やフレームワーク、プロセス、組織のあり方についてなどが書かれています。
ややくどかったりポジショントークのような部分もありますが、全体的に顧客中心主義で進めるためのプロダクトマネジメントについてよくまとまっていると思います。
実際にプロダクト開発をしている人が読めば、なにかしら改善したい点が見つかるのではないでしょうか。
一方、言うは易し行うは難しな内容かなとも思いました。
本の中の物語ではスムーズに改善が進みますが、実際にこの本の内容を適用してみるのはそこまで簡単ではないと思います。
また、カタカナ英語で当たり前に出てくる用語が日本人的な感覚だとちょっと意味をとりづらい文が多かった印象です。
イニシアティブとか普通はそんなに馴染みがないのではと思いました。
投稿元：
レビューを見る
PMでなくても読んでおいて損はない本
以下の2点が学びだった
- アウトカム思考
- 顧客が課題に感じてることに向き合う
投稿元：
レビューを見る
ビルドトラップという共通用語が組織に根付いただけでこの本を購入する価値があった。短くまとまっており非常におすすめ
投稿元：
レビューを見る
プロダクトマネジメント界隈では話題になりがちな点が架空の企業を登場させながらとてもわかりやすくまとまっている。
自分が業務で感じていることや難しさもうまく言語化されており、頭ではわかっているつもりになっていた部分への理解も深まった気がする。
・ビルドトラップとはアウトカムではなくアウトプットで成功を計測しようとしている状態、実際に生み出される価値ではなく、機能の開発とリリースに集中してしまっている状態
・ビルドトラップから抜け出し真に顧客価値を届け続けるためには、組織レベルでプロダクト主導に変えていかないといけない
投稿元：
レビューを見る
超読みやすいプロマネの概要書。特にII部のプロマネの役割、IV部のプロマネプロセスが白眉。逆に戦略論や組織論はやや独特の概念で実践しづらい印象があった。
INSPIREDと並行してプロマネのあるべきを振り返る指標になりそうな良書。
投稿元：
レビューを見る
【感想】
恥ずかしいことにPdmという概念をそもそも分かっていなかった。
現在の自分の立場がそれに近いので、1章から共感と共に自分にグサグサささる内容で最後まで自分事として読むことが出来た。
全体の構成として、”ビルドトラップ”をキーワードに、そもそもの定義や大事な考え方といった大きなところからはじまり、戦略作りや組織作りまで具体の枝葉まで落ちていく。
【私的ポイント】
その①：1部で出てきた、ビルドトラップという概念やアウトカムでやるべきを考える思考が大事。KGI/KPIマネジメントと連動させる。
その②：OKRとアウトカムの連動は、成功事例としてネットフリックス、Spotifyなどが参考になる。フレームとしてのDIBB,やOODAループを参考。
その③：プロダクトビジョンは一つに各商品の横断的な役割を整理して、つぎはぎにせず一つに集中できるようにプロダクトビジョンとプロダクトイニシアチブを明確にする必要がある
その④：データ分析よりもまずは定性ヒアリングの調査、アウトカムを形作るためにはデータからはじき出す傾向だけは全体が見えない
その⑤：イノベーションを加速させるために邪魔を排除しつつも、完全独立してサイロ化してしまっては、全体戦略に混ぜられないため意味がない
➡既存組織・事業との連動を意識しながらも、エンドユーザーの声を元にアウトカムを定義し、KGI/KPIへとブレイクダウンしていく必要がある。
投稿元：
レビューを見る
p.10
顧客が価値を認めるのは、自分たちの問題が解決したりニーズが満たされたりしたときだけ。
ビジネスの価値はお金やデータなど。
顧客に価値を提供して、ビジネスの価値をいただく=価値交換システム
p.21 既知の既知、既知の未知、未知の既知などある。プロダクトマネージャーは未知を減らす。
p23プロダクトマネージャーの役割
- ビジネスと顧客の両方を深く理解する
- なぜそのプロダクトを作っているのか、どんなアウトカム（顧客への価値）を生み出すのかを忘れないようにする
p31
- 課題を解決するアイデアを考えることも、課題を考えることすらも顧客の役割ではない。プロダクトマネージャーの役割だ
- 顧客がなぜそれを欲しがっているのかを考える
P36
プロダクトマネージャーは既知の未知を特定し、明らかにしていく。
まずは顧客のどんな課題を解決したらいいかわからない、ところから始まる
### 得られることの仮説
- 機能を開発すること（アウトプット）ではなく、顧客に価値を届ける（アウトカム）が大事
- なぜその機能を作るのか、を明確にする役割
- 顧客に価値を届けることが大事だが、それを実現するためにどうしたらいいのか？
- プロダクトマネジメントの役割は何か？
投稿元：
レビューを見る
アウトプットではなくアウトカムに注力すること。この意味が分からない人は、迷わずこの本を手にとることをおすすめする。内容はプロダクトマネージャ向けであるが、プロダクトマネジメントの方法論に収まらず、セールス、マーケティング、エンジニアなど、幅広い職種の人に多くの示唆を与えてくれる。
勤務先の企業のビジョンを聞かれてすぐに回答できる人がどのくらいいるのだろうか。プロダクトマネージャでなくとも、本書の内容を心に留めて仕事にとりくむことで、読者の行動の質が向上するだろう。
投稿元：
レビューを見る
プロダクトマネジメントのお勉強。
■ビルドトラップ：組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰っている状況。
■プロダクトオーナーとは、スクラムチームのなかの役割。プロダクトマネージャーはキャリア。
■AARRR
・Acquisiton：ユーザーがあなたを見つける
・Activation：ユーザーが初めてあなたのプロダクトを体験する
・Retention：ユーザーが戻ってくる割合
・Refferal：ユーザーがあなたのことをほかの人に話してくれる
・Revenue：得られる利益
■問題を理解する
ユーザー調査、観察、アンケート、顧客フィードバックはどれも、ユーザーの視点から問題を深く調査するために使えるツールです。ユーザー調査と、プロトタイプやウェブサイトを見せてユーザーに操作してもらうようなユーザビリティテストを混同しないようにしてください。ユーザビリティテストはソリューションが実際に問題を解決するかどうかではなく、ユーザーが簡単にソリューションを使えるかどうかを確認するものです。こういった調査を検証的調査と呼びます。
問題ベースのユーザー調査は生成的調査であり、その目的は解決したい問題を見つけることです。これには、顧客の問題の原因を特定し、その状況を理解することが含まれます。
■MVP
最初のリリースで作るものは全部MVPである。複数の顧客にそう言われました。
■オズの魔法使い
顧客は、裏側で全部手作業でやっていることを知りません。オズの魔法使いのおうに誰かが裏で糸を引いているのです。
■企業がプロダクト主導かどうかを判断する６つの質問
１．最後に作った機能やプロダクトのアイデアを思いついたのは誰ですか
→「思いついたというのはどういう意味でしょう？もちろん私たちのチームですが。そうですよね？いつもそうやっています」こういう反応は健全なプロダクトマネジメント組織の表れ。
２．最後に廃止を決めたプロダクトは何ですか？
→不健全なプロダクトマネジメントの文化を示すもう1つのサインは、目標の達成の役に立たないプロダクトやアイデアを企業が捨てないこと。
３．顧客と最後に話をしたのはいつですか？
→怖いのは、「ああ、マネジメントは、顧客と話すのを本当に許してくれません。私たちが顧客を煩わせてしまうのを心配しているんです」という答え。
４．目標は何ですか？
→プロダクトマネージャーが明確な目標を示せないのであれば、組織レベルでのプロダクトマネジメントが不十分である
５．現在何に取り組んでいますか？
→本当の意味で成功を収めているプロダクトマネージャーは、プロダクト開発チームがリリースするソリューションよりも、解決しようとしている問題を熱心に語るもの。私にとって、これは成功を示す最大の兆候の1つであり、目標についての問いと密接な関係がある。
６．プロダクトマネージャーはどんな人ですか？
→プロダクトマネジメントが尊重されていない組織の2つの理由。1つはプロダクトマネージャーが強すぎると思われ���ていること、もう1つは逆に弱すぎると思われていること。
投稿元：
レビューを見る
プロダクトマネジメントのお勉強。
■ビルドトラップ：組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰っている状況。
■プロダクトオーナーとは、スクラムチームのなかの役割。プロダクトマネージャーはキャリア。
■優れたプロダクトマネージャー
組織におけるプロダクトマネージャーの本当の役割は、チームと協力して、ビジネスニーズとユーザーの問題解決を同時に満たす適切なプロダクトを作ることです。そのためには、さまざまな帽子をかぶる必要があります。プロダクトマネージャーとして仕事を効果的に進めたいなら、会社のさまざまな側面を理解しなければいけません。マーケットとビジネスの仕組みを理解する必要もあれば、会社のビジョンと目標を本当の意味で理解する必要もあります。また、プロダクトのユーザーを理解するには、ユーザーに対する深い共感も必要です。
「プロダクトマネージャー」という名前そのものが誤解を招きます。プロダクトマネージャーはマネージャーではありません。このポジションはあまりありません。チームリーダーとして効果を発揮するには、プロダクトマネージャーはチームメンバーの長所を認識し、共通の目標の達成に向けて一緒になって働く必要があります。プロダクトマネージャーは、自分たちが作っているものが正しいことをチームにも会社全体にも納得させなければいけません。人に影響を与えるというスキルはプロダクトマネージャーに不可欠です。
プロダクトマネージャーがプロダクト全体の持ち主であり、全員に何を作るべきか伝えることができるというのは、プロダクトマネージャーの役割に対する最大の誤解の1つです。そのような行動をすれば、チームのほかのメンバーから避けられるだけです。実際には、プロダクトマネージャーが持つのは「なぜ」それを作るのかという理由の部分です。目の前の目標を知っていて、会社の戦略に応じてチームがどの方向に向かうかを理解しているのがプロダクトマネージャーです。プロダクトマネージャーはチームメンバーに方向性を伝えるのです。
プロダクトマネージャーはチームと一緒に仕事を進めます。アイデアを出し、それを検証し、作っているプロダクトが顧客やユーザー、ビジネスの目標を確実に達成できるようにします。 プロダクトマネージャーは、プロダクトビジョンを固め、それを形にして周りに伝え、そのビジョンを守ります。しかし結局のところ、プロダクト「なに」に値する部分)の実際の持ち主はチームなのです。
何を作るか決めるには、戦略的で実験的なアプローチが必要です。プロダクトマネージャーは実験の指揮を執りつつ、既知の未知を特定して明らかにしなければいけません。プロダクト開発の初期では、既知の未知は問題の探索や顧客のふるまいから明らかになります。つまり、「顧客のためにどんな問題を解決すればよいかわからない」ところから始まります。 未知のことがはっきりするにつれて、不確実だったもの が顧客の問題を解決するものに変わっていきます。
プロダクトマネージャーは点と点を結びます。顧客調査や専門的な情報マーケット調査、事業の方向性、実験結果、データの分析結果などをインプットにします。そして、その情報をふるいにかけて分析し、企業の発展と顧客のニーズの解決に役立つプロダクトビジョンを作るのです。
そのためには、プロダクトマネージャーは謙虚な姿勢で、自分たちがすべてを知っているわけではないことを踏まえて学習しなければいけません。自分たちが取り組むべき仮説があることを理解し、それを評価してリスクを減らすために、科学的な考え方で取り組んでいきます。結局、プロダクトマネージャーの目標は、学習に重点を置いてリスクを減らすことなのです。重要なのは、自分たちのアイデアだけが良いアイデアなわけではないことを理解することです。
■技術の専門家とマーケットの専門家
優れたプロダクトマネージャーでありたいなら、ビジネス部門やテクノロジー展門、デザイン部門と連携して、それぞれの知識を総合的に活用できなければいけません。最悪なプロダクトマネージャーの特徴の1つは匹狼のマインドセットです。つまり自分だけがプロダクトの成功に責任があるという考え方です。結果として傲慢になって、チームのアイデアを見下すようになります。優れたプロダクトマネージャーは、チームのスキルや専門知識を活用して、さらに成長できることを理解しています。
プロダクトマネージャーが何もないところからソリューションを考え出すことなどできません。たとえば、UXデザイナーと協力してユーザーの主要なワークフローを理解します。ユーザー体験がユーザーの目標達成に役立つからです。開発者と協力して、プロダクトや機能をすばやくマーケットに投入する方法を検討することもあります。
「UXデザインとプロダクトマネジメントはどう違うのか?」という質問をよく受けます。この2つの分野は重複するところが多いですが、UXは素晴らしいプロダクトを作る上での一部分にすぎません。デザインはプロダクトの成功に不可欠ですが、1つの要素にすぎないのです。プロダクトマネジメントはシステム全体を見ます。要件、機能コンポーネント、価値提案(バリュープロポジション)、UX、ビジネスモデル、価格モデル、全体の統合などです。そして、どうやってプロダクトで企業に収益をもたらすかを見つけるのです。組織の全体像を理解し、体験だけでなくプロダクトそのものを組織にあわせる方法を見つけるのがプロダクトマネジメントです。
企業がプロダクトマネージャーを雇うときの最大の間違いは、技術の専門家マーケットの専門家を見つけようとすることです。 プロダクトマネージャーは、こういったドメインの専門家ではありません。 プロダクトマネージャーは、プロダクトマネジメンドの専門家です。技術やマーケットのことを知らなくてよいという意味ではありません。開発者やビジネス側の人と話して意思決定できるくらいの知識は必要です。
プロダクトマネージャーに技術の素養は必要ですが、精通している必要はありません。つまり、開発者と会話したりトレードオフの決定を下したりできるくらいに技術を理解していれば構いません。機能や改善の複雑性を理解して開発者に正しい質問ができればよいのです。プロダクトマネージャーは、プロダクトが高度に技術的で意思決定に技術の理解が欠かせない場合を除いて、コードを書ける必要はありません。
マーケットにも同じことが当てはまります。プロダクトマネージャーがマーケットをよく知っていることは価値がありますが、これは学習できます。チームのなかでスキルのバランスを取ればよい話です。チームに高度なスキルを持ったマーケットアナリストがいるなら、プロダクトマネージャーはその人との会話の仕方、そこから学習する方法、その人のスキルを活用する方法を知っていればよいのです。
■AARRR
・Acquisiton：ユーザーがあなたを見つける
・Activation：ユーザーが初めてあなたのプロダクトを体験する
・Retention：ユーザーが戻ってくる割合
・Refferal：ユーザーがあなたのことをほかの人に話してくれる
・Revenue：得られる利益
■問題を理解する
ユーザー調査、観察、アンケート、顧客フィードバックはどれも、ユーザーの視点から問題を深く調査するために使えるツールです。ユーザー調査と、プロトタイプやウェブサイトを見せてユーザーに操作してもらうようなユーザビリティテストを混同しないようにしてください。ユーザビリティテストはソリューションが実際に問題を解決するかどうかではなく、ユーザーが簡単にソリューションを使えるかどうかを確認するものです。こういった調査を検証的調査と呼びます。
問題ベースのユーザー調査は生成的調査であり、その目的は解決したい問題を見つけることです。これには、顧客の問題の原因を特定し、その状況を理解することが含まれます。
■MVP
最初のリリースで作るものは全部MVPである。複数の顧客にそう言われました。
■オズの魔法使い
顧客は、裏側で全部手作業でやっていることを知りません。オズの魔法使いのおうに誰かが裏で糸を引いているのです。
■企業がプロダクト主導かどうかを判断する６つの質問
１．最後に作った機能やプロダクトのアイデアを思いついたのは誰ですか
→「思いついたというのはどういう意味でしょう？もちろん私たちのチームですが。そうですよね？いつもそうやっています」こういう反応は健全なプロダクトマネジメント組織の表れ。
２．最後に廃止を決めたプロダクトは何ですか？
→不健全なプロダクトマネジメントの文化を示すもう1つのサインは、目標の達成の役に立たないプロダクトやアイデアを企業が捨てないこと。
３．顧客と最後に話をしたのはいつですか？
→怖いのは、「ああ、マネジメントは、顧客と話すのを本当に許してくれません。私たちが顧客を煩わせてしまうのを心配しているんです」という答え。
４．目標は何ですか？
→プロダクトマネージャーが明確な目標を示せないのであれば、組織レベルでのプロダクトマネジメントが不十分である
５．現在何に取り組んでいますか？
→本当の意味で成功を収めているプロダクトマネージャーは、プロダクト開発チームがリリースするソリューションよりも、解決しようとしている問題を熱心に語るもの。私にとって、これは成功を示す最大の兆候の1つであり、目標についての問いと密接な関係がある。
６．プロダクトマネージャーはどんな人ですか���
→プロダクトマネジメントが尊重されていない組織の2つの理由。1つはプロダクトマネージャーが強すぎると思われるていること、もう1つは逆に弱すぎると思われていること。
