マーティ・ケーガンのレビュー一覧
-
Posted by ブクログ
ちゃんとした利益を得るにはなんとなく10年先は見ておかないと厳しいような気がしてきた。あと、物事には正解がないし、運ゲーだし、自分が良かれと思ったアイデアは、どんなに賢い人でも少なくとも3/4は望んだような結果が出ないらしい。
競争力のあるIT製品を生み出すためには、テクノロジーや製品開発組織の枠を超えた、劇的で意味のある改革が必要だ。
売れるプロダクトを作るには顧客第一、デザイナー必須、プロダクトビジョンを明確に…等
【メモ】
リスクは最初に取り組む
価値のリスク（顧客が購入するかどうか）
ユーザビリティのリスク（ユーザーが使い方をわかるかどうか）
実現可能性のリスク（エンジニアが、持っている時間とスキルとテクノロジーで必要なものが作れるか）
事業実現性のリスク（ソリューションが、販売、マーケティング、財務、法律など、ビジネスのさまざまな分野でもないかどうか）
機能を実装することではなく、問題を解決すること
ホリスティック（全体論的）な製品
機能、つまり特徴が含まれる。
機能を実現する技術が含まれる
機能を提示するユーザーエクスペリエンスデザインが含まれる
機能を金銭に変える方法が含まれる
ユーザーや顧客を惹きつけて獲得する方法
その価値を伝えるのに欠かせないオフライン体験
製品発見
ユーザーはそれを買ってくれるか？
ユーザーはその使い方をわかるか？
私たちのエンジニアはそれを作れるか？
ステークホルダーたちの支持が得られるか？
「プロトタイプ」
製品やサービス、システム開発の初期段階で作られる「試作品」や「原型」のこと
報酬目当ての開発チームは、作れと言われたものを作る。使命感を持った開発チームはビジョンを信じ、顧客のために問題の解決に全力を傾ける。
プロダクトマネージャ
「会社の中で最も才能のある人材の1人であるべき」
プロダクトマネージャにあるといいもの
技術に関する高度な知識やビジネスの腕前
主要な幹部との信頼関係
顧客に関するふかい知識
製品に対する情熱
製品開発チームへの敬意がある
四つの重要な責任
顧客に関する深い知識（問題、悩み、欲望、考え方、仕事のやり方や購入の意思決定方法）
データに関する深い知識（A／Bテストなど）
自分のビジネスについての深い知識（ステークホルダー：統括管理、販売、マーケティング、財務、法務、事業開発、カスタマーサービス）
市場と業界についての深い知識（ライバル企業、キーとなる技術の動向、顧客の行動と期待、関連する産業のアナリストのフォロー、市場の顧客に影響を与えるソーシャルメディアの役割）
頭がいいとは
知的好奇心にあふれる
新しい技術をすぐに習得できる
顧客の問題を解決できる
新しい顧客の心を掴める
新しいビジネスモデルを作る
粘り強いとは
説得力のある根拠を持つ
常にコミュニケーションを取る
頑強な反対に直面しても組織の間の橋渡しをする
企業を動かしてコンフォートゾーン（心理的な安全領域）から押し出す力がある
プロダクトマネージャの準備
ユーザーや顧客の専門家になる（質的、量的）
学んだことは開発チームで共有する
チームや企業で頼られる人になる
目に見えない制約を理解
制約の下で実行できると考える解決策を提案
製品や業界に関して誰もが認める専門家になる（広い心で積極的に）
強固な協力関係と育てるために懸命に努力
顧客との接点
メール
マーケティングキャンペーン
販売プロセス
カスタマーサポート
最初にどうやって製品を知るか？
どうやって初めてのユーザーが製品に馴染み、どんな方法で連絡を取るか
一日のうちどんな時間帯に、どんな方法で連絡をとるか
ユーザーの関心を低くために、他にできることはないか
顧客歴1ヶ月の人と顧客歴一年のひとではどこが違っているか
ユーザーに製品に対するもっと高い関心を持ってもらうためにはどうすればいいか
どうやって満足の瞬間を作り出すか
ユーザーは、どうやって自分の体験を他人と共有するするのか
顧客は、どのようにオフラインサービスを受けるのか
体感的な製品の応答性はどのようなものか
ユーザーリサーチャー
定性的な学習（解決すべき問題を理解しようとする創造的研究と、ソリューションがどれだけ上手く問題を解決するかを評価しようとする評価的研究）
適切なユーザーを見つける
適切なテストを作る
ここのユーザーや顧客とのコミュニケーションから最大限のことを学ぶ手助けをする
データアナリスト
適切な分析データを集めるのをサポート
データのプライバシーに関する制限
データ分析
ライブデータテストの計画を立て、その結果を解釈し説明
ビジネス観点
製品のビジョン
戦略
機能
ビジネスルール
ビジネスロジック
チーム開発
能力のない人を選んで昇進させ、リーダーの地位に就けることが1番いけない。
地位的には人材を育成する能力において確かな実績のある人物を雇う必要がある。その人物は、潜在的な才能を見つけて採用し、一緒に積極的に仕事を就ける中で弱点を克服させ、長所を引き出してきた経験を持っていなければならない。
どんな組織についてか
アーキテクチャ
エンジニアリング
品質
サイト運営
サイトのセキュリティ
リリース管理
市場投入のマネジメントに責任を持つ組織
CTO責任
組織（全ての従業員の育成計画、定着率、製品開発・技術組織全体のそのマネジャーに対する他部門からの評価）
リーダーシップ（企業の進路、M&A活動、作る/買う/連携するに関する決定を助ける）
市場投入（高品質な製品を、迅速に、確実に、繰り返し、市場に送り出す）
アーキテクチャ（機能性、拡張性、信頼性、セキュリティ、性能）
製品発見（イノベーションの頻度）
エバンジェリズム（広報担当者の役割、開発者、定型企業、顧客たのコミュニティ）
ビジネスに関する目標
顧客獲得コストを下げる
1日のアクティブユーザー数を増やす
新規顧客を獲得するまでの時間を短くする
「エバンジェリズム」
本来はキリスト教の「福音伝道（よい知らせを伝えること）」を意味し、現代のビジネスシーンでは、革新的な製品・サービスの技術や魅力を熱意を持って広く伝え、熱狂的なファンや市場を創造する活動やプロセス
プロダクトマネージャの夢を売るためのアドバイス
プロトタイプを使う。
悩みを共有する。
ビジョンを共有する（製品びか、製品戦略、製品理念）
学習したことを惜しみなく共有する（上手く行ったことや問題）
成果を惜しみなく共有する。
優れたデモを行う方法を学ぶ。
常に学習に励む。（競争相手や関連するトレンド）
心からワクワクする。
熱意の見せ方を学ぶ。（熱意は伝染する）
チームと一緒に時間を過ごす。
「BBC」
英国放送協会
新しいテクニックを取り入れる方法
何を作るべきか教えてくれるように顧客に頼むことはできない。
最も重要なことは、説得力のある価値を確立すること。
優れたユーザーエクスペリエンスを考え出すのはそれ以上に困難である事が多く、さらに製品の成功には欠かせない。
機能、デザイン、技術は、本質的に絡み合っている。
アイデアの多くはうまくいかないものだし、うまくいくものも何回かのイテレーションが必要になると予測する。
アイデアの妥当性は実際のユーザーや顧客にで立証しなければならない。
製品発見の目標は、できる限り迅速に、コストをかけずにアイデアの妥当性を立証する事である。
製品の発見の間に、アイデアの実現可能性を立証する必要があると。後ではダメだ。
製品発見の間に、アイデアの事業実現性を立証する必要がある。後ではダメだ。
共同学習が大切である。
リスク
財務上（資金的な裏付けがあるか）
事業開発（パートナーに貢献するか）
マーケティング（企業ブランドに合ってるか）
販売（売る体制が整っているか）
法的（法務やコンプライアンスの観点）
倫理的（倫理的に開発していいか）
製品発見の仕事の質問
この仕事はどんなビジネスの目標を達成しようとしているのか？
何を持って成功とするのか？
この仕事は顧客のどんな問題を解決するするのか？
どんな種類の顧客をターゲットにするか？
顧客発見プログラム
ビジネス向けの製品を開発する
プラットフォーム製品（パブリックAPIなど）を開発する
自社の従業員が使う顧客対応ツールを開発する
コンシューマー向けの製品を開発する
重要なひらめき
顧客はあなたが考えてたような人たちか？
本当にあなたが考えているような問題を持っているか？
現在、その問題をどうやって解決しているか？
自社製品に乗り換えさせるためには何が必要か？
「エンドユーザー」
商品やサービスを最終的に使用・消費する「末端の利用者」のこと
実現可能性のリスク
アルゴリズム
性能
拡張性
フォールトトレランス
それまで使ったことのないテクノロジーの使用
サードパーティ製の部品やサービスの使用
レガシーシステムの使用
他の開発チームによる新たな変更や、関連する変更への依存
ライブデータプロトタイプ
フルセットのユースケース
自動化テスト
完全な分析計装
国際化とローカリゼーション
性能と拡張
SEO作業
製品発見
ユーザーや顧客はこれを使ったり買ったりすることを選んでくれるか？（価値）
ユーザーはこれの使い方がわかるか？（ユーザビリティ）
私たちはこれをビルドできるか？（実現可能性）
このソリューションはビジネスに貢献するか？（事業実現性）
定性的価値テスト
インタビュー
ユーザビリティテスト
特殊な価値テスト
価値を実証するのにお金を使う
批判を使う
時間を使う
アクセス情報を使う
定量的価値テスト
A\Bテスト
招待制テスト
顧客発見プログラム
ユーザーや顧客の行動を理解する
製品開発の進行を測る
製品のアイデアがうまくいくかどうかを証明する
製品開発に関わる判断を情報で裏付ける
製品開発の仕事にひらめきを与える
IT製品にとって欠かせない分析
ユーザーの行動分析（クリックパス、エンゲージメント）
ビジネス分析（アクティブユーザー、コンバージョン率、生涯価値、リテンション）
財務分析「ASP、ビリング、タイム・トゥ・クローズ」
性能（ロード時間、稼働時間）
運用コスト（ストレージ、ホスティング）
市場開拓コスト（顧客獲得コスト、販売コスト、プログラム）
センチメント（NPS、顧客満足度、調査）
分析はしばしば、KPI（重要業績評価指標）と呼ばれる
イノベーション起こし方
顧客中心の文化
魅力的な製品ビジョン
的を絞った製品戦略
強力なプロダクトマネージャ
安定した製品開発チーム
製品発見へのエンジニアの参加
企業の勇気
権限を与えられた製品開発チーム
製品開発のマインドセット
イノベーションを起こすための時間
スピードが失われる理由
技術的負債
強力なプロダクトマネージャの不在
デリバリーマネジメントの欠如
リリースサイクルの長期化
製品ビジョンと戦略の欠如
同じ場所にいて、長続きする開発チームの不在
製品開発に早い時期からエンジニアを参加させない。
製品発見にプロダクトデザイナーを使わず、エンジニアがビルドしている間にプロダクトデザインの仕事をさせようとする。
優先順位を変える
コンセンサス文化 -
Posted by ブクログ
ネタバレ噂に聞く素晴らしい本。PdMのバイブルと言われるのも納得。
ネタバレですが、メモです。
-------------
- チームメンバーを伝道師にする。傭兵のチームでは無い
- 使命感を持った開発チームはビジョンを信じ、顧客のために問題の解決に全力を傾ける
- チームが一緒に学習する。チームは顧客の悩みを一緒に受け止め、あいであが失敗するのを経験して何が重要で何をすべきかの文脈を全員が理解する
- プロダクトマネージャ
- 何を顧客に届けるのかを判断する(製品発見)のが主な仕事
- 多くの顧客に有効な１つのソリューションを考え出す（顧客の数だけ考えるのでは無い）
- 製品発見の鍵は、顧客と対話すること
- できるだけ迅速に、コストをかけずにアイデアの妥当性を見つけ出す
-
- 下記知識を持つ
- 顧客に関する深い知識
- データに関する深い知識
- 自分のビジネスについての深い知識
- 市場と業界についての深い知識
- 効率的な
- エンジニアがPMFするための製品探し（製品発見と呼んでいる）も行うべき
- 有能なチームは即座にリスクに取り組み、有効なソリューションに対しイテレーション(PoC検証)を何度も繰り返し実行する
- アイデアのプロトタイプをｔくり、ユーザー、顧客、エンジニア、ビジネスホルダーに対しテストする
- 1週間に１０～２０イテレーションを行う
- エンジニアは機能を提供するのがゴールではなく、本質的な問題を解決する必要性がある
- エンジニアのパフォーマンスは結果で測定
- ビジネスの根本的な問題を解決できなければ何も解決したことにならない
- 製品開発チームは企業がどこへ向かっているかを確実に把握し、大きな目標に対して自分のチームがどのように貢献するのが望ましいか理解する必要性がある
- どうやるかを指示してはいけない。何をすべきかを指示すればよい。そうすればエンジニアは創意工夫するだろう
- プロダクトマネージャによる製品に関するエバンジェリズム
- プロトタイプを見せる
- 顧客の悩みを開発チームと共有する
- 我々の仕事がそのビジョンにどれだけ貢献し、どれだけ理念に忠実であるかを見せる
- ユーザテストや顧客訪問の後は必ず学習したことを共有する。チームみんなで考える
- 開発チームが製品はプロダクトマネージャのものでは無く、自分たちのものだと思えるようにする
- 失敗した場合はPdMがすべての失敗の責任を引き受け、失敗からも学べることをチームに示す
- あなたが心からワクワクしていると周りの人に伝わるようにする
- デザイナーやエンジニアと顔を合わせて十分な時間を使う
- メンバーはあなたの目に宿る熱意を見ることができる
- 相手のモチベーションのレベルが変わる
- カスタマーレター テクニック ★★
- 架空のプレスリリースを書く（ワーキングバックワードプロセス）
- それはどのように顧客の生活を向上させるのか？
- 顧客の利益は何か？
- 開発チームがこのプレスリリースを見て胸を躍らせないなら、それは実行する価値が無い
- 開発チームをアウトプットでは無く、アウトカム（結果）に集中させる
- 開発チームが機能の一覧表にすぐ取り掛かるのは良くない
- さらなる進化系
- 仮想的なカスタマーレター
- その製品によって顧客の生活がどんなふうに代わり向上したかが書かれている
- カスタマーレターの方が顧客の現在の共感を生む効果が高い
- 自分たちの仕事がどのように顧客の生活に役に立ちうるかを開発チームにより明確に印象づけられる
- スタートアップキャンバス
- 製品の全体像を的確に把握できる
- ビジネスのどういう分野に影響を与えるかを理解することが容易になる
- リスクに光を当ててくれる
- 最大のリスクにこそ真っ先に取り組まなければならない
- 顧客発見
- 6つのリファレンスカスタマーを見つける
- プロダクトマーケットフィット
- もしその製品が使えなくなったらどう感じるか？
- 「非常に残念」と答えたユーザーが４０％以上ならばPMFしている可能性高い
- 良いチーム
- 人を魅了する製品ビジョンを持っていて、伝道師のような情熱で追及する
- エンジニアが毎日プロトタイプを試す時間を確保し、製品をよりよくする方法について、自分たちの考えを提案できるようにする
- 毎週エンドユーザーと関わって、顧客をよりよく理解し、自分たちの最新のアイデアに対する顧客の反応を見る
- 望んだアウトカムを生み出すためには何回かの繰り返しが必要になると考えている
- 良い開発チームはスピードが必要であり、イテレーション（繰り返し）が適切なテクニックからくると知っている
- 自分たちの製品がどんなふうに使われているかを知るために製品にデータ取りを実装し、データに基づいて調整する
- 良い開発チームは業績に大きく貢献した時に祝う（悪いチームはリリース時に祝う）
- スピードが失われる理由
- PdMが開発チームに動機や使命感を与えられてこなかった
- 仕事の全体像と目の前の仕事がどのように全体に貢献するかについて開発チームがビジョンを持つことが重要
- 強い製品開発文化
- 実験の文化。テストの多くは失敗することを知っている。失敗が受け入れられることを知っている
- 優れたアイデアは最初は必ずしもその良さがわからないことを知ってる -
-
-
-
Posted by ブクログ
ネタバレプロダクトマネジメントについて学ぶべく読書。
ハイテク領域に焦点を当てたプロダクトマネジメントの本。
メモ
•初版からの学び。プロダクトマネジャーに焦点を当てる必要性。成功するための製品開発文化、製品発見と市場投入のためノアテクニック、直面課題に適したツール
•優れた製品の背後には技術と設計を組み合わせ、顧客の真の課題を解決する人間が存在する
•スタートアップ期は資金が尽きる前にPMFを達成するレース。そのため必然的に製品開発に注力
•何が知り得ないことなのかを知る。顧客検証が遅すぎないか
•リスクには最後でなく最初に取り組む
定義づけとデザインは協調させつつ同時実行
機能実装より問題解決が重要
•製品発見の問い
それを買ってくれるか
使い方がわかるか
エンジニアは作れるか
ステークホルダーの支持得られるか
•製品開発チーム 傭兵ではなく、伝道師のチーム
•開発チームは物理的に拠点同じく近距離であることが重要
•プロダクトマネジメントは他の仕事と決定的に違う
ceoと同様ビジネスのあらゆる側面を深く理解している必要性
どの例も成功ソリューションはユーザーや顧客や販売からもたらされたものはない
真のリーダーシップは偉大な製品開発者とただの良い製品開発者を分ける大きな要素
•行動特性
製品開発リーダーにふさわしい行動特性
チーム開発、製品ビジョン、実行力、製品文化
•製品開発チームの構成原則
投資戦略の連携、依存関係を最小化する、オーナーシップと自律性、レバレッジを最大化する、製品ビジョンと製品戦略、開発チームの規模、アーキテクチャーとの連携、ユーザや顧客との連携、ビジネスとの連携、構成は動く標的である。
•市場の優先順位を決める
第一の要素は、市場の規模
第二の要素は、流通。第3の要素は、どれだけ時間がかかるかの推定
•製品ビジョンの原則
whyから始める
解決策ではなく、問題に恋をする
臆病にならずに、大きな視野でビジョンを考える
チームを混乱させることを恐れない
製品ビジョンは人の心を揺さぶらなければならない
関連性があり、意味のトレンドを見つけ出し取り入れる
パクがある場所ではなく、パックが向かっているところに滑っていく
ビジョンには頑固でディーテイルには柔軟でいる
どんな製品ビジョンも信じて賭けることだと考える
絶え間なく粘り強く説得して回る
•製品発見の目的は次のリスクに対処すること
顧客はこれを買ったり使うことを選んでくれるだろうか
ユーザはこれの使い方がわかるだろうか
私たち、これを作れるだろうか
このソリューション、私たちのビジネスに貢献するだろうか
•市場機会評価
ビジネスの目標
何を持って成功とするか
顧客課題は何か？
どんな種類の顧客がターゲットとなるのか
•強いイノベーション文化を持つとは
実験の文化、開かれた心の文化、権限移譲の文化、テクノロジーの文化、多様なスキルセットとスタッフの文化、製品開発テクニックの文化 -
-
Posted by ブクログ
EMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダシップ
マーティ・ケーガン クリス・ジョーンズ 著
2021年 6月の本
EMPOWERED：エンパワーされた、という意味。『「力を与えられた」という状態。力を与えられるのは誰か。それは人と組織だ。つまりは、プロダクト関係者が活力を得た状態を目指すことが理想の状態ということだ』と、まえがき に記載されている。
こちらの本は会社での『輪読会』というイベントがあり、良本をみんなで読み解釈を共有し合うことでメンバー全員の知の探索を進化させるという営みが面白そう！として参加した際の教材でした。 すごく重厚で内容も具体的で具体的で、確かに一人で読んでいたら挫折してしまったかもしれない、というぐらい濃い本でした。 みんなで読み終わった後に、改めましてもう一度速読で読み返して、さらに内容への理解が深まりました。 Think clearlyに記載のあった 「二度読んだ時の読書効果は、一度しか読まないときの倍どころではない。もっとずっと高くなる。私の経験から言えば、ほぼ10倍にふくれあがる。」の件は本当にそうだと改めて思いました。
輪読会には、こちらのEMPOWERED の「まえがき」も執筆されました及川卓也さんもご参加いただいており、非常に有益なアドバイスもいただきながらの会となりまして、勉強になりました。 私個人としてはプロダクトマネージャー（PdM）というキャリアでは直接はなくて、いわゆる法人営業のソリューション業界を歩んで来たものですが、輪読会においては、プロダクトマネジメントを進めるプロダクトマネージャーやその関連の皆さんの素晴らしいディスカッションも聞くことが出来、勉強になりました。 私が勤務しているNTTコミュニケーションズ は 「人と世界の可能性をひらくコミュニケーションを創造する」という言葉を企業理念にかかげている会社であって、プロダクトマネジメントは非常に重要なことだと考えているので、こうした勉強会が社内で勝手に立ち上がって多くのメンバーが学んでいることは素晴らしいことだと自社の事ながらすごく感動しています。 また、そうした社内勉強会に、日本でのプロダクトマネジメントをまさにけん引されている及川卓也さんという方が参加いただけて共に学ぶことが出来る、という環境を与えてくれている自社にはほんとすごい会社だと思っています。
輪読会の際の自分の担当の範囲は「ビジネスコラボレーション」という章でして、PdMを目指される皆さんとは少し距離をおいたビジネス側にいる立場的にこの章を選び、発表しました。 発表の際に 「リーダーは適切な質問が表に出るような環境を作り上げることが期待されます」 という表現があったので、以前読んだ 『教えないスキル』も紹介しました。
ほとんど読書レビュにはなっていなくて、輪読会感想文になってしまっておりますが、以下ではいくつか引用です。
（だいぶ減らしたつもりなんですが随分と多くなってしまった）
＝＝＝＝＝＝＝＝＝＝＝
P55 優れたコーチングとは何よりも、従業員が自らのポテンシャルを引き出せるように支援するという目的を持った、継続的な対話なのだ。
P57 あなたがマネジャーであれば、最も多くの時間とエネルギーをチームのコーチングに割くべきである。 つまり、チームの評価、コーチングプランの作成、チームメンバーの向上と成長の積極的な支援といった仕事に、心血を注がなければならない。
P89 キャリアのゴールにかかわらず、テックリードの真のポテンシャルは、技術への理解と、顧客が苦しんでいる問題への認識を組み合わせられる能力から生まれる。（中略） 最後に私の発見を一言で伝えよう。 テックリードに顧客またはビジネスの文脈についてコーチングする時間は、1分残さず最も価値ある時間の使い方の1つだ。
P117 エンパワーされたプロダクトチームをつくり上げるには、解決すべき問題のオーナーシップをプロダクトチームに渡し、チームが最適と考える方法で問題を解決できるようにする必要があることをおわかりだろう。
P124 プロダクトマネジャーにとって最優先となる貢献事項と職責は、エンジニアが構築を依頼されているサービスが、本当に構築するだけの価値があるかどうか、必要な結果を生むかどうかを確認することである。
つまり、デザイナーやエンジニアと協力して、価値、ユーザビリティー、実現可能性、事業実現性を備えたソリューションを編み出すことだ。それがプロダクトディスカバリーであり、毎日4時間専念すべき仕事である。
P145 私が最初に主張したいのは、「顧客」という言葉について具体的に定義し、その定義を守るということだ。
P146 私は、「顧客」という言葉を神聖な存在に近い扱いとすることを好んでいる。この考え方によって、プロダクト担当者が、会社の行動や判断に顧客が必然的に果たす役割を理解できるようになると信じている。
P147 有能なプロダクト担当者の仕事は、顧客に代わってイノベーションを起こすことであって、顧客へのアンケートやインタビューを鵜呑みにすることではない。
P151 エンパワーされたプロダクトチームでは、約束したタイミングで出荷するだけでは十分ではない。出荷したものは機能しなければならない。―顧客やビジネスの問題を解決しなければならないのだ。 これははるかに難しい。
P223 忘れないでほしい。私たちが賢いプロダクト担当者を採用しているのは、作業を指示するためではない。顧客に愛されビジネスがうまくいく形で、難しい問題を解決してもらうためだ。
P244 プロダクトビジョンは、会社がつくろうとしている未来を語る。どのような形で、顧客の生活を向上させようとしているのだろうか。 その目標にどのように達するかは説明しない。
P303 悪い戦略は、良い戦略を練り上げるためのハードワークを自ら避けた結果なのである。なぜ避けるのかと言えば、考えるのは大変で、選ぶのは難しいからだ。しかし相反する要求や両立しえない価値観の中から選択をすることこそリーダーの仕事であり、それを放棄するとなれば、悪い戦略しか生まれない。
P314 （良い戦略は）「戦略マネジメント」ツールだとか、マトリクスやチャートといったものも無用だ。必要なのは目の前の状況に潜む1つか2つの決定的な要素―すなわち、こちらの打つ手の効果が一気に高まるようなポイントを見極め、そこに狙いを絞り、手持ちのリソースと行動を集中すること、これに尽きる。
P342 最も優れたチーム目標は、リーダーとチーム間の議論の行き来から生まれる。
P372 私は、自分でデザインするのをやめて、優れたデザインが生まれる場所をデザインしなければならないことに気づきました。自らをマネジメントできるようなチームをデザインする必要があったのです。（中略）
私は、そのとき以来ずっと、「個人の集団」を「チーム」に変えられるように心がけています。チームは、どんな個人も奇跡を起こせないようなときに、奇跡を起こせるのです。
P411 フォーカスとインサイトに基づく真のプロダクト戦略の重要性。 プロダクト戦略は、各プロダクトチームにどの問題を解決してもらうかを示す。リーダーたちは、インパクトの大きい少数のインサイトに基づいて戦略を組み立ててから、ほとんどの組織に対して問題を解決するように依頼した。
P426 エンパワーされたプロダクトチームにおけるチームの役割は、顧客に愛され、かつビジネスになるプロダクトを開発して顧客に奉仕することである。
P437 リーダーは、あらゆる質問に答えることは期待されませんが、適切な質問ができること、そしてもっと重要な点として、適切な質問が表に出るような環境をつくりあげることが期待されます。
P455 会社がプロダクトチームの水準を上げたければ、会社がプロダクトに対する考え方を変えねばいけません。
プロダクト組織を、単なるテクノジー組織の一部（あるいは、もっと悪い場合はIT部門の一部）と見なすかわりに、組織そのものとして見る必要があるのです。
P464 本書を読んだ次世代のリーダーが、部下と会社が求めるリーダーになるためにやるべき仕事を理解してくれることを大いに期待している。（中略） 最後に、皆さんがご自身の才能とエネルギーを永遠に発揮し続けることを願っている。
＝＝＝＝＝＝＝＝＝＝＝
以上 -
-
-
-
-
Posted by ブクログ
新しいプロダクトを作るときにプロダクトを作る人に参考になる本
以下メモ
リーンなプロダクト開発の中心テーマ
1. リスクには最初に取り組む、価格、ユーザビリティ、実現可能性
2. 製品の定義とデザインは協調させながら、持ちつ持たれつ進める
3. 機能の実装ではなく問題解決が目的
製品開発チームが全て
プロダクトマネージャーとは
・失敗の責任を持つ人
・顧客に関する深い知識
・プロダクトに関するデータ分析
・ビジネス、市場や業界に対する深い知見
製品開発ロードマップの問題点
・経営陣の事業運営上計画を立てる必要性、いつ機能が使えるのか知りたいといったことから求められる
・半分以上のアイデアはうまくいかないことが考慮されていない
・ロードマップに書いた途端、約束事項として理解してしまう
・解決すべきビジネス上の問題によって記述するアウトカムベースのロードマップがよい
製品ビジョン
・2〜5年の間に実現しようとする未来、みんなを勇気づけ人を集めるビジョン
1. Whyから始める、目的をはっきりさせる
2. 解決策ではなく問題に恋する
3. 臆病にならず大きな視野で
4. チームを混乱させることを恐れない
5. 人の心を揺さぶらないといけない
6. 重要なトレンドを見つけ出し取り入れる
7. 時間軸で変化するところと変化しないところを見極める
8. ビジョンには頑固で、細部には柔軟でいる
9. どんなビジョンも信じて賭けること、見極めるのに数年はかかる
10. 絶え間なく、粘り強く説得して回る
製品戦略
1. 1度のリリースにつき１つのターゲット市場やペルソナに集中する
2. ライバルではなく顧客のことだけ考える
3. どうやるかは指示しない、何をやるかを指示する
製品の発見
・多くの顧客に有効な一つのソリューションを考え出す必要がありながら、100%信頼がない製品をリリースしてあとは祈るというやり方が許されないこと
原則
1. 何を作るべきか顧客は教えてくれない
2. 説得力のある価値を確立する
3. 優れたユーザーエクスペリエンスは困難だが欠かせない
4. アイデアの多くはうまくいかない、どのアイデアが、役に立たないかを前もって知れない、様々な方法を試す
5. アイデアの妥当性は実際のユーザーで立証しないといけない、製品に対する顧客の反応を予測できると思うのは間違え
6. できる限り迅速にコストをかけずにアイデアの妥当性を立正する
市場発見
1. ビジネスの目的objective 何を達成するのか
2. 何をもって達成するのかkey results
3. どんな顧客のどんな問題を解決するのかcustomer problems
4. どんな種類の顧客かtarget market
・顧客が書いた仮想的なカスタマーレターを書くことで需要の評価をすることも良い
・スタートアップキャンバスは新製品投入において特にリスクの発見に役立つ
発見のためのプランニング
①ストーリーマップ
・バックログのような羅列されたリストではなく、主要なユーザーのアクティビティを時間軸、実行の順に沿って左から右に並べる。縦軸は詳細さ、主要なタスクほど上
②顧客発見プログラム(リファレンスカスタマー、ロイヤルカスタマーの発見)新製品や新しいビジネスを生み出す際に役立つ(マイナーチェンジには向かない)
・ターゲット市場における6〜8のリファレンスカスタマーを目指す
・候補企業を集める、本当に悩みを抱えていて開発しようとしているソリューションが欲しくてたまらない企業。顧客と会いたいと言う人たちは後で良い、リード扱い
・6つのプロダクトを作るのではなく、全てに役立つ1つのソリューションを見つけだす。
・リファレンスカスタマー探しに苦労しているようだと重要ではない問題を追いかけている可能性が高い
顧客インタビュー
心がけるべきこと
1. 顧客は考えていたような人たちか？
2. 本当に考えている問題を持っているか？
3. 現在どうやって解決しているか？
4. 自社製品に乗り換えさせるために何が必要か？
・インタビューの間に何かを証明しようとしない、理解と学習に努める
・コンシェルジュテスト：顧客に変わり手作業で顧客の仕事をすること、
・プロダクトアウト、マーケットイン以外に顧客が予期せぬ使い方をするところから可能性を広げる方法もある
需要テスト
・リリースしてから価値がなかった、は最も避けるべきでかつ容易に避けられる。
・フェイクドアテスト: 適切な箇所に新機能のボタンを追加し、特殊なページに遷移させる。そこがテストの協力フォームになる。需要に関する適切な証拠と新しい機能を使いたいユーザーリストが手に入る -
-
-
Posted by ブクログ
これはプロダクトチームのメンバーとなる人の必読書。
勉強になった。
最善を尽くしたにもかかわらず、あるチームメンバーについて、成功への道筋がイメージできなくなることがある。この段階に達したら、決然と行動するのが重要である。
多くのマネジャーにとっては、この原則が最も実践しづらい。コーチングとは人を育てることなので、必然的に問題点を成長の機会として見ることになる。それ以上に、部下に仕事ができていないと伝えるのは、精神的に最もきつい会話の1つだ。いっそのこと、目を背けてサボったほうが気が楽だろう。
しかしそうすると、マネジャーも、チームも、本人も傷つく。まず、マネジャーは他の人を犠牲にして、この人に必要以上の時間を割いている可能性が高い。次に、他のチームメンバーにはハードワークを求めながら、その人には凡庸であることを許すというシグナルを出してしまっている。それは信頼を損ない、モチベーションを失わせるための確実な道のりだ。最後に、パフォーマンスに問題のある本人が、もっと成功できる可能性のある他の職場に移るチャンスを与えられていない。
■プロダクト担当者らしい行動
傾聴し、協力し、共同学習し、啓蒙し、鼓舞し、手柄を渡し、責めを引き受け、責任を取り、知りえないことを知り、知らないことを認め、謙虚さを示し、会社全体にわたってさまざまな関係を築き、個人レベルで顧客を知り、リーダーシップを発揮することをいう。
■マネジャーのアンチパターン
・マネジャーが無関心
・マネジャーがマイクロマネジメントに回帰する
・マネジャーが話してばかりで相手の話を聞かない
・マネジャーが厳しいフィードバックをしない
・マネジャーが不安定か、あるいは能力不足である
・マネジャーが損切りをしない
つまり、デザイナーやエンジニアと協力して、価値、ユーザビリティー、実現可能性、事業実現性を備えたソリューションを編み出すことだ。それがプロダクトディスカバリーであり、毎日４時間専念すべき仕事である。
■プロダクトチームの４大リスク
１．顧客はこのプロダクトを買うか、あるいは選ぶか？（価値のリスク）
２．ユーザーはこのプロダクトの使い方がわかるか？（ユーザビリティーのリスク）
３．私たちはこのプロダクトを製造・構築できるか？（実現可能性のリスク）
４．ステークホルダーはソリューションを支持するか？（事業実現性のリスク）
５．私たちはこのプロダクトを製造・構築するべきか？（倫理的リスク）
■私が気に入っている面接の質問
１．実行力―どのくらいうまくものごとをやり遂げ、言われなくても正しいことを実行し、複数の目標を同時に追求できるか。
２．創造力―その場にいる人の中で、あなたが一番多くのアイデア、または最も優れたアイデアを提案できたケースはどの程度頻繁にあるか。
３．戦略―現在取り組んでいる内容を俯瞰的に、より広いマーケットやビジョンのコンテキストでとらえ、それを他の人たちに対して明確に提示することが、どのくらいうまくできるか。
４．成長―プロセスの賢い使い方やチームマネジメントなどを通じて取り組みの成果を倍増させる能力に、どのくらい優れているか。
しかし、多くの企業にとっては、問い自体が変化している。
いまや、私に寄せられる問いは、「プロダクトチームが分散し、一部または全体がリモートワークに従事しているという前提で、自分たちが継続的なイノベーションを起こす可能性を最大限に高めるために、ベストプラクティス（最良の方法）をどのように活用するか」に変質している。
■トポロジーとデザイン
ほとんどの企業は、職能横断型プロダクトチーム、少なくともエクスペリエンスチームには、専任のプロダクトデザイナーが必要であることを理解しているこれは、優れたプロダクトをつくるために、プロダクトデザインがどれほど決定的に重要かという認識を示している。
ただし、デザイン部門のリーダーが、「社内エージェンシーモデル」という別の形を好む場合もある。…
…
社内デザインエージェンシーモデルでは、重要な意思決定が行われるときに、デザイナーは通常その場にいない。したがって、デザイナーは―そして最終的にはユーザーが―そのツケを払うことになるのだ。
デザインは社内サービスとして運営するには、あまりに重要だ。デザインマネジャーは、プロダクトマネジャーやテックリードと同様に、プロダクトチームの中でも特に優秀なメンバーが務めなければならない。
スタートアップ企業の創業者やCEOの多くは、有能なエンジニアリング組織と協力して仕事をしたことがありません。そのため、テクノロジーの役割や、エンジニアがプロダクトマネジャーやプロダクトデザイナーのパートナーとして果たすべき貢献について、根本的に誤解していることが珍しくありません。
■チームに答えを導かせるほうが優れている理由
・最も適切なソリューションを判断するのに適した人々は、問題に最も近く、必要なスキルを備えた人々―つまり、プロダクトチームである。
・会社としては、求められるアウトカムを達成するために、チームに責任を持ってもらいたい。
・構築すべき機能を会社からチームに指示してしまったら、その機能が必要な結果をもたらさなかった場合に、チームの説明責任を問えない。
・解決すべき問題と、その問題を最適と思える形で解決するための余地をプロダクトチームに与えれば、チームは問題に対し、はるかに高いオーナーシップを感じるようになる。
・チームが考えついた初めてのソリューションによって求められるアウトカムが生まれなかった場合、チームは、そのソリューションを引き続き繰り返すか、別のアプローチを試すかして、求められるアウトカムを生み出すソリューションを見つけなければならない。
■実在の急成長企業の事例からの最重要ポイント
１．トポロジー、プロダクト戦略、チームの戦略から、四半期中に発生する問題や障害の臨機応変なマネジメントまで、プロダクトリーダーが果たすべき重要な役割。
２．フォーカスとインサイトに基づく真のプロダクト戦略の重要性。
３．チームの目標を積極的にマネジメントする重要性。
４．エンパワーされたチームと伝道師のチームの価値。
５．知ることができる情報とできない情報に関する制約。
６．一部しか功を奏さないとわかっていても複数の方法に賭ける、というリスクマネジメント要素。
７．インサイトを行動に変える際にチームトポロジーが与えるインパクト。
８．リーダーとプロダクトチームに必要なギブアンドテイク。
９．すべてのプロダクトチーム間のおける広範囲の戦略コンテキストの共有の重要性。
10．不確かなことは面倒で、うまくいく保証はない。しかし賢いリーダーはたいてい、うまくやる方法を見つける。それは、チームを信頼し、不確かさを受け入れ、リスクを適切に管理するからである。
■エバンジェリズム10のテクニック
１．プロトタイプを見せよう。
２．ペイン（痛み、悩み）を共有しよう。
３．ビジョンを共有しよう。
４．学びを共有しよう。
５．貢献してくれる人々の名前を気前よく共有しよう。
６．素晴らしいデモをする方法を学ぼう。
７．自己学習をしよう。
８．心の底からときめきを感じよう。
９．熱意を表に出すやり方を学ぼう。
10．プロダクトチームと時間を過ごそう。 -
-
-
-