噂に聞く素晴らしい本。PdMのバイブルと言われるのも納得。
ネタバレですが、メモです。
-------------
- チームメンバーを伝道師にする。傭兵のチームでは無い
- 使命感を持った開発チームはビジョンを信じ、顧客のために問題の解決に全力を傾ける
- チームが一緒に学習する。チームは顧客の悩みを一緒に受け止め、あいであが失敗するのを経験して何が重要で何をすべきかの文脈を全員が理解する
- プロダクトマネージャ
- 何を顧客に届けるのかを判断する(製品発見)のが主な仕事
- 多くの顧客に有効な１つのソリューションを考え出す（顧客の数だけ考えるのでは無い）
- 製品発見の鍵は、顧客と対話すること
- できるだけ迅速に、コストをかけずにアイデアの妥当性を見つけ出す
-
- 下記知識を持つ
- 顧客に関する深い知識
- データに関する深い知識
- 自分のビジネスについての深い知識
- 市場と業界についての深い知識
- 効率的な
- エンジニアがPMFするための製品探し（製品発見と呼んでいる）も行うべき
- 有能なチームは即座にリスクに取り組み、有効なソリューションに対しイテレーション(PoC検証)を何度も繰り返し実行する
- アイデアのプロトタイプをｔくり、ユーザー、顧客、エンジニア、ビジネスホルダーに対しテストする
- 1週間に１０～２０イテレーションを行う
- エンジニアは機能を提供するのがゴールではなく、本質的な問題を解決する必要性がある
- エンジニアのパフォーマンスは結果で測定
- ビジネスの根本的な問題を解決できなければ何も解決したことにならない
- 製品開発チームは企業がどこへ向かっているかを確実に把握し、大きな目標に対して自分のチームがどのように貢献するのが望ましいか理解する必要性がある
- どうやるかを指示してはいけない。何をすべきかを指示すればよい。そうすればエンジニアは創意工夫するだろう
- プロダクトマネージャによる製品に関するエバンジェリズム
- プロトタイプを見せる
- 顧客の悩みを開発チームと共有する
- 我々の仕事がそのビジョンにどれだけ貢献し、どれだけ理念に忠実であるかを見せる
- ユーザテストや顧客訪問の後は必ず学習したことを共有する。チームみんなで考える
- 開発チームが製品はプロダクトマネージャのものでは無く、自分たちのものだと思えるようにする
- 失敗した場合はPdMがすべての失敗の責任を引き受け、失敗からも学べることをチームに示す
- あなたが心からワクワクしていると周りの人に伝わるようにする
- デザイナーやエンジニアと顔を合わせて十分な時間を使う
- メンバーはあなたの目に宿る熱意を見ることができる
- 相手のモチベーションのレベルが変わる
- カスタマーレター テクニック ★★
- 架空のプレスリリースを書く（ワーキングバックワードプロセス）
- それはどのように顧客の生活を向上させるのか？
- 顧客の利益は何か？
- 開発チームがこのプレスリリースを見て胸を躍らせないなら、それは実行する価値が無い
- 開発チームをアウトプットでは無く、アウトカム（結果）に集中させる
- 開発チームが機能の一覧表にすぐ取り掛かるのは良くない
- さらなる進化系
- 仮想的なカスタマーレター
- その製品によって顧客の生活がどんなふうに代わり向上したかが書かれている
- カスタマーレターの方が顧客の現在の共感を生む効果が高い
- 自分たちの仕事がどのように顧客の生活に役に立ちうるかを開発チームにより明確に印象づけられる
- スタートアップキャンバス
- 製品の全体像を的確に把握できる
- ビジネスのどういう分野に影響を与えるかを理解することが容易になる
- リスクに光を当ててくれる
- 最大のリスクにこそ真っ先に取り組まなければならない
- 顧客発見
- 6つのリファレンスカスタマーを見つける
- プロダクトマーケットフィット
- もしその製品が使えなくなったらどう感じるか？
- 「非常に残念」と答えたユーザーが４０％以上ならばPMFしている可能性高い
- 良いチーム
- 人を魅了する製品ビジョンを持っていて、伝道師のような情熱で追及する
- エンジニアが毎日プロトタイプを試す時間を確保し、製品をよりよくする方法について、自分たちの考えを提案できるようにする
- 毎週エンドユーザーと関わって、顧客をよりよく理解し、自分たちの最新のアイデアに対する顧客の反応を見る
- 望んだアウトカムを生み出すためには何回かの繰り返しが必要になると考えている
- 良い開発チームはスピードが必要であり、イテレーション（繰り返し）が適切なテクニックからくると知っている
- 自分たちの製品がどんなふうに使われているかを知るために製品にデータ取りを実装し、データに基づいて調整する
- 良い開発チームは業績に大きく貢献した時に祝う（悪いチームはリリース時に祝う）
- スピードが失われる理由
- PdMが開発チームに動機や使命感を与えられてこなかった
- 仕事の全体像と目の前の仕事がどのように全体に貢献するかについて開発チームがビジョンを持つことが重要
- 強い製品開発文化
- 実験の文化。テストの多くは失敗することを知っている。失敗が受け入れられることを知っている
- 優れたアイデアは最初は必ずしもその良さがわからないことを知ってる
