学んだこと

「成功を生き延びる」ために「傭兵よりも伝道師のチームをつくる」
プロダクトマネジャーは「製品開発文化」をつくる
- 強いイノベーション文化をつくる
  - 実験の文化
    - 指標・ミッション・リーンサイクルの手法のカタ
  - 開かれた心の文化
    - あなたのどんな経験もアイデアの源泉になる
    - 世界を変えるアイデアも最初はぼんやりしている
  - 権限委譲の文化
    - 正しいことをするのに許可いらない
  - テクノロジーの文化
    - イノベーションはいつも顧客の悩みから始まり新しい技術とデータによって実現する
  - ビジネスと顧客に精通したチームの文化
    - ビジネスニーズと制約への理解
    - 顧客への深い理解と顧客にすぐ連絡をとれる方法がある
  - 多様なスキルセットとスタッフの文化
    - 多様性がイノベーションに貢献するという確信を持っている
  - 製品発見テクニックの文化
    - アイデア・構築・検証・学習のサイクルが滞りなく繰り返せるようになっている

1. 一流IT企業から学んだこと

必死になってつくったものがあった
　まったく売れなかった
　　「顧客やユーザーが必要なものだとわからないかぎり、二度とあんなに必死になって働かない」と誓った

真に人々の心を揺り動かす製品
　顧客に愛され熱狂させる製品をつくる

優れた製品の背後
　チームがいる

ほとんどの企業
　ウォーターフォール
　　アイデア優先
　　要求事項
　　　ユーザーストーリーや仕様書
　　いつ準備が整うか知りたい
　　　次の四半期や一年ロードマップをつくる　
　　デザインが揃えば開発
　　アジャイルなのか？
　　　細かく分割したウォーターフォール

10の問題
　1. アイデアのトップダウンではダメ。開発チームが傭兵となるだけ
　2. コストも利益も現時点では不確か。何を知り得ないか理解する
　3. アイデアの半分はうまくいかない。不都合な真実への対応
　4. プロダクトマネジメントは要求事項の文書化ではない
　5. ガラクタに口紅を塗っても仕方ない。UXデザインは根幹からおこなう
　6. エンジニアを製品開発パーティに誘う
　7. アジャイル手法を最大限活用する
　8. 製品は成果物ではない。そこがスタートである
　9. ウォーターフォールの最大の欠点はリスクが最後に来ること。顧客実証が遅すぎる。
　10. リーン手法だと信じてウォーターフォールをやっている

みなリーンやアジャイルだと思ってウォーターフォールで開発している

優れた開発チームの3つの原則
　1. リスクに最初から取り組む
　　顧客が購入するかのリスク
　　使いやすいかどうかのリスク
　　開発できるかのリスク
　　事業として成り立つかのリスク
　2. 製品定義とデザインは協調し同時に実行される
　　要件定義、デザイン、実装は同時
　　小さなウォーターフォールではない
　3. 一番重要なのは機能実装ではなく課題解決
　　それを実装すればいくら遅延コストがなくなるか
　　ビジネスの成果が大切

製品の全体像
　機能
　機能を実現する技術
　機能を提示するUXデザイン
　マネタイズ方法
　獲得方法
　　SEMやSEO
　オフライン体験
　購入から返品などの体験
　顧客が体験する全てが製品

つくる必要のある製品を発見すること
　遅延コストで計算する
高品質な製品を市場に投入すること

製品発見とは
　ユーザーはそれを買うか、使うか？
　ユーザーはそれの使い方がわかるか
　私たちはそれを作れるか
　ステークホルダーたちの支持が得られるか

MVPについて
　Pはプロダクトではない
　　プロトタイプと考える

2. 成功するための組織と人　　　　　

職能横断型チーム
製品開発チーム
　専門技能と責任をもつ
　本当に自分たちの製品だと思っている人たち
　　使命感を持っている

プロダクトマネジャー1人
デザイナー1人
2〜12人くらいのエンジニア

上下関係はない
　プロダクトマネジャーは誰の上司でもない
　　階層型組織ではない

古いプロジェクト指向のモデル
　何かをプロセスに突っ込んで押し出すだけ

プロダクトマネジャーに必要なもの
　高度な知識やビジネス手腕
　　市場と業界への深い知識
　主要幹部との信頼関係
　　ステークホルダーへの理解
　顧客に対する深い知識
　　顧客に対する専門家
　　　定量と
　　　定性
　製品に対する情熱
　　製品に対する専門家
　製品開発チームへの敬意

プロダクトマネジャーになるには
　まずユーザーや顧客の専門家になる
　　質も量
　　共有する
　ステークホルダーやパートナーへの理解
　　見えない制約を理解している
　製品や業界についての専門家となる
　　共有する
　チームと強固な信頼関係をもち育成する
　　信頼
　　教育

プロダクトマネジャーはCEOに近い
　だが部下はいない

プロダクトマネジャーがプロダクトオーナーを兼務する

カスタマージャーニー
　最初にどうやって製品を知るか
　どうやって使っていくか
　いつどんな方法でユーザーと連絡を取るか
　ユーザーの関心を惹くために他にできることはなにか

毎週のユーザーテスト
　思い込みを防ぐ

プロダクトマネジャーとデザイナーは真のパートナー

一番いいソリューションを考え出したい
　エンジニアにできる限り裁量権を与える
　　エンジニアの士気はプロダクトマネジャーの責任
　　　使命感で働く
　　　　顧客の悩みやビジネス問題を共有する
　　　　　問題や悩みをオープンにする

プロダクトマネジャーと
　プロダクトマーケティングマネジャーの連携

ユーザーリサーチャー
　定性的
　　創造的
　　評価的
　定量的
　いなければプロダクトデザイナーがやる

データアナリスト
　いなければプロダクトマネジャーがやる

GoogleのAdWords
　600億ドルの収益
　あえなく廃止となるところだった
　　販売チームとカニバる可能性
　　検索の邪魔になる
　一人一人と話し合う
　「検索結果の横に表示する」
　製品をつくらせないための
　もっともらしい理由はたくさんある

主席プロダクトマネジャー
　開発チームを定期的に調査
　競合を特定する

製品開発のトップ
　4つの行動特性の実証
　　チーム開発
　　　PMとデザイナーからなる強力なチーム
　　　　求人
　　　　トレーニング
　　　　コーチング
　　製品ビジョン
　　　CEOを補完する必要がある
　　実行力
　　製品文化
　4つの専門家
　　モダンなプロダクトプランニング
　　顧客発見
　　製品発見
　　製品開発プロセス
　　ステークホルダーの管理
　　組織内のエバンジェリズム

製品開発チームの構成
　戦略的なポートフォリオとして持つ
　依存関係を最小化する
　オーナーシップと自律性
　　使命感で働くエバンジェリストチーム
　レバレッジを最大化する
　　業務の集約
　　依存関係とのバランス
　製品ビジョンと製品戦略
　開発チームの規模
　　1PdM、1デザイナー、2エンジニアが最小
　アーキテクチャとの連携
　ユーザーや顧客との連携
　ビジネスとの連携
　組織構成は動く標的
　　完璧な方法はない

現実の開発チーム
　経営陣はそれほど信頼していない
　　大きな自由を与えることに抵抗
　リーダーが基盤と考えているものを
　開発チームが変えたがっている
　　Githubは基盤
　　　自律性と基盤のトレードオフ
　　　　自律的な開発チームと
　　　　レバレッジの効く基盤への投資
　　　　　企業文化から導き出される

自律性とレバレッジのバランス
　Aスキルチームには大問題
　　トレードオフについてチームと一緒に考える
　　ビジネスの全体像を共有する
　　　総合的な製品ビジョン
　　　チームごとの具体的な指標とミッション

小さな企業に最も必要なもの
　製品重視の強力なCEOやPdM
　開発チーム

Adobeのリーヒックマン
　サブスクモデルに移行
　リーダーやステークホルダーとひっきりなしに
　コミュニケーションする
　　マラソンを走るようなキャンペーン

3. 成長するための製品

製品開発ロードマップの問題点
　製品アイデアの半分はうまくいかない
　　そもそも買わない
　　使い勝手が悪い
　　開発コストが高すぎる
　　法律・ビジネスなどの外部制約
　　改善の繰り返しが必要
　うまくいかなかったら？
　　ステークホルダーのせいにする
　　さらに分解したり再設計したりする
　　別の機能を作る

なぜロードマップが使われてきたか
　今どこにいるか経営陣がわかる
　　事業価値の高い項目に真っ先に取り組んでもらいたい
　経営陣が期日を設定したいから

IT企業のビジネス
　製品のビジョンと戦略
　指標とミッション

伝道師と傭兵の問題

アウトカムベースのロードマップ
　何を解決するか書いてある

「期日」は難しい
　どうしてもウォーターフォールになる
　　アイデアは大体成功しない
　　最初はうまくいかない
　　イテレーションが必須
　それが簡単でも人的リソースが足りないこともある
　　デリバリーマネジャーが整理する
　　　期日と依存関係

製品ビジョン
　今後2〜5年の未来を描く
　ミッションステートメントとは違う
　　「世界をもっとオープンにつなげる」など
　ミッションステートメントの実現方法
　人材募集ツールになる
　モチベーションになる
　心を奮い立たせるもの

製品戦略
　製品ビジョンへの到達方法
　焦点の定まったもの
　何をしないか

製品ビジョンの原則
　1. WHYから始める
　2. 解決策でなく問題に恋をする
　3. 臆病にならず大きな視野でビジョンを考える
　4. チームを混乱させることを恐れない。あなたがしなくても誰かがそうする。
　5. 製品ビジョンは人の心を揺さぶらなければならない
　6. 関連性があり意味のあるトレンドを見つけ出し、取り入れる
　7. 時間軸で変化するものとしないものを見極める
　8. ビジョンには頑固でディテールには柔軟でいる
　　ジェフベゾズ
　9. どんな製品ビジョンも信じて賭けることだと考える
　　検証できたらビジョンではない
　　見極めるのに数年かかる
　　　数年間喜んで仕事をしてくれる人を探す
　10. 絶え間なく、粘り強く説得して回る

製品戦略の原則
　1. 1度につき1つのターゲット市場やペルソナに集中する
　2. 製品戦略はビジネス戦略と整合させる
　3. 製品戦略は販売戦略と連携させる
　4. ライバルでなく顧客のことだけを考える
　　ライバル企業が原因で顧客が離れることはめったにない。顧客が離れるのは顧客のことを考えなくなったから
　5. 組織全体で戦略についてコミュニケーションをとる

MBO（management by objectives ）システム
　支配による管理とまったく反対のもの
OKRシステム
　目標（objective ）は定性的なもの

プロダクトマネジャーの一番大きな責任
　製品を発見すること
　　顧客はこれを買ったり使ったりするか？
　　ユーザーはこれの使い方がわかるか？
　　私たちはこれを作れるか？
　　これはビジネスになるか？

製品発見の原則
　アイデアはほとんどうまくいかないと理解する
　実際の顧客でアイデアの妥当性を検証する
　チームが一緒に学習すること

傭兵でなく伝道師のチームをつくる

問題よりもソリューションについて皆話したがる
　ソリューションよりも問題に恋をする必要がある

開発チームが4つの答えを理解していること
　力を生む
　　プロダクトマネジャーの責任

Amazon
　製品開発を架空のプレスリリースから始める
　　想像のプレスリリース
仮想のカスタマーレター
　製品に感動した顧客からの手紙
　　顧客の生活がどんなふうに変わったか
　
ユーザーストーリーマッピング

PdMの役割
　ビジネスを維持できる製品を作ること
　　強力な製品を前提としている

リファレンスカスタマー
　エバンジェリストユーザー
　　ハッピーなリファレンスカスタマー
　　　最高の営業ツール
　　　PdMの責任
　先行事例
　　6つ
　　　1つのターゲット市場
　　　橋頭堡
　　　　業種、地理、使い方
　マーケティングや販売組織のスイッチを入れる
　　市場の証明
　開拓はPdMの仕事

PMF
　マストハブ質問
　　非常に残念が40%
　　　toC向け
　1つの市場で6つのエバンジェリストユーザー
　　その市場でPMF達成
　　　ボウリングピン

顧客インタビュー
　最も基本的なもの
　　実際はそれほど実行されていない
　心がけ
　　顧客は想定通りか？
　　顧客はその問題を本当に持っているか？
　　顧客は現在その問題をどうやって解決している？
　　自社製品に乗り換えさせるためには何が必要？
　　最後に新しいアイデアを試すのもいい

どんな使い方をしているか？
　ebayの「その他」カテゴリ
　　世界最大の中古車市場
　顧客のしたがっていることの観察
　　どんなふうに解決したがっているのか
　　　十分にやるとパターンが見える
　APIを公開する
　　使い方を制限しない

プロトタイプ
　製品よりもはるかに小さいコストで何かを学ぶ
　議論より深く考えられる

発見
　使ってくれるのか？
　　価値
　使えるのか？
　　ユーザビリティ
　作れるのか？
　　実現可能性
　ビジネスになるのか？
　　事業可能性

ユーザビリティテスト
　スターバックステスト

開発チームとユーザビリティテストをする
　主体性が高まる

需要テスト
　フェイクドア需要テスト
　　ボタンをつけて工事中
　　　機能開発の協力者を募る
　　集められる
　　　需要
　　　協力ユーザー

エンタープライズでのテスト
　1%以下へのABテスト
　招待制テスト

テストでうまくいかなかったら？
　買わない製品や機能を作るコストを節約できた
　　機会費用を失わずに済んだ

チームのアイデアと対話する
　アイデアを定性テストする
　　PdM
　　デザイナー
　　エンジニア

ビジネス目標を測定可能な目標とともに
開発チームに渡す

PdMの分析スキル
　ユーザー行動分析
　　クリックパス、エンゲージメント
　ビジネス分析
　　アクティブユーザー、コンバージョン率、LTV、リテンション
　財務分析
　性能
　運用コスト
　市場開拓コスト
　センチメント
　　NPS、顧客満足度、調査

ユーザーテスト
　定性的テスト
製品デモ
　販売
ウォークスルー
　ステークホルダーに隠さない懸念点洗い出し

Netflix
　最初は倒産の危機
　　5000万ドルでblockbusterに売る提案拒否される
　　今は400億ドルの企業価値
　ただのレンタル屋
　　ネットでレンタル
　サブスク
　　30日のお試し期間で開発
　　高いものと安いものをどう混ぜるか
　　　キュー、評価、レコメンド
　7年後ストリーミングに変更
　
アジャイルコーチ
　エンジニアリングとリリース
ディスカバリーコーチ
　製品発見もやる
リーンスタートアップコーチ
　マーケティングやビジネスモデル発見もやる

パイロットチームでやってみる

製品開発ロードマップを変える
　まずは指標とミッションを明確にする

ステークホルダーのしたいこと
　何に取り組んでいるか目に見える形で見たい
　最も重要な項目に取り組んでいるか確認したい
　重要なことが起きる時期を知っておきたい

企業が変化をさせないように身を守る方法
　エラーやリスク低減という名目で
　　定式化
　　標準化
　　プロセスを決める

ステークホルダーとは？
　拒否権があるかどうか
　　経営陣
　　ビジネスパートナー
　　財務部門
　　法務部門
　　コンプライアンス部門
　　事業開発部門
　考え方や制約を理解する
　PdMは全てのステークホルダーに問題を理解していると納得してもらう必要がある
　　役立つ解決策に全力を傾けていると確信してもらう
　誠実だと思われないと？
　　不信感を募らせる
　　コントロールしようとする
　PdMが深く理解しておくこと
　　顧客、分析、技術、業界、自社のビジネス
　　　理解を示すには学習したことを広く共有すること
　ステークホルダーと一対一の時間を過ごす
　　制約を知れば知るほど製品が良くなると伝える
　　　制約を知る前にビルドしない
　　　　製品発見の鍵の一つ
　　　すぐテストをしてデータを貯める
　　ステークホルダーの感情に敏感になる
　　　製品の意味を知ってもらう
　　　自分の役割にビクビクしている人もいる
　　1人30分
　　全員にプレゼンするのは悪手
　　　プロトタイプでは向かない
　　　汎用的なデザインにしかならない

「大企業のマネジャー」に文化を壊されないためには
　非常に強く、意図的な製品開発文化を持つこと
　　異質な開発文化を明確に持つ
　面接・新人研修で組織文化を明確に伝える
　　人間性と才能のための採用
　　以前の組織文化を捨て去ってもらう
　　　共通認識とする

全社会で開発部門が学習したことを共有する

5. 成功するための文化

良い開発チーム
　人を魅了するビジョンを持つ伝道師のチーム
　ビジョンや目標から顧客の課題解決アイデアを得る
　　デザイン思考
　ステークホルダーとビジネスの制約内で素晴らしいものをつくる
　リーンサイクルで開発する
　社内の優秀な人とブレストする
　担当者が並んで座っている
　自分たちのデザインに対するスキルセットに自信を持っている
　毎日プロトタイプを試してアイデアを出している
　毎週エンドユーザーと関わって反応を見る
　何度もトライエラーを繰り返す必要性を知っている
　重要なのはリーンサイクルのスピードだと知っている
　要望を適切に評価し実行するか決める
　どんなふうに使われているかデータを取り調整する
　小さなリリースを細かく繰り返す
　エバンジェリストユーザーにこだわる
　業績に大きく貢献したときに祝う

悪い開発チーム
　傭兵の集まり
　販売部門や顧客から要望を集める
　ステークホルダーから要望を集める
　優先順位をつけたロードマップで開発する
　チーム外の人と交流しない
　サイロに閉じこもって文書や会議を要求する
　デザイナーが何をする人か知らない
　プロトタイプは与えられるものでそこから推測するもの
　自分たちは顧客を完全に理解していると思っている
　ロードマップに従って期日と品質が守られればよいと考えている
　仕事が遅くなるのは同僚がサボっているからだとぐちをこぼす
　要望は受けないとつっぱねる
　分析と報告はあればいいがなくても構わない
　最後に手動テストをしてビッグバンリリースをする
　競争相手にこだわる
　最終的に何かをリリースしたときに祝う

スケールアップによってイノベーション文化を失うとき
　顧客中心の文化を失っている
　　Amazon
　　　「顧客を喜ばせたいから新しいものを生み出す」
　魅力的な商品ビジョンを失っている
　　創業者が離れるとさらに深刻になる
　的を絞った製品戦略を失っている
　　同時に全ての人を喜ばせようとする
　　　ターゲットは誰か
　　　何をやらないのか
　強力なプロダクトマネージャーを失っている
　　規模が大きくなってCEOや創業者だけでは難しくなる
　安定した製品開発チームを失っている
　　業界知識、顧客の悩み、自社のビジネスへの理解
　　　地層のような実感の積み重ね
　　　　傭兵部隊ではそれがない
　製品発見へのエンジニアの参加が失われている
　　エンジニアが最初から参加する
　企業の勇気が失われている
　　リスクを避けるようになる
　権限を与えられた開発チームが失われている
　　ロードマップを渡すだけになっている
　製品開発のマインドセット
　　顧客の役に立つために開発する姿勢
　イノベーションを起こすための時間が失われている
　　業務をこなすだけで時間がとられる
　　　バグ修正
　　　技術的負債
　　　遅延コストを追求する時間

開発スピードが失われる最大の理由
　技術的負債
　強力なプロダクトマネージャーの不在
　　傭兵のチームになっている
　　　動機や使命感がない
　　　PdMに対して信頼感を失っている
　デリバリーマネジメントの欠如
　　誰かが積極的に障害を取り除かなければならない
　リリースサイクルの長期化
　　テスト自動化やリリースの自動化
　製品ビジョンと戦略の欠如
　　KGI、KPI、人事評価、ミッション、リーンサイクル
　　　開発から会社の成長まで全てが繋がっている実感が必要
　長続きする開発チームの不在
　　エンジニアリングの外注をしてしまう
　製品発見にエンジニアが参加していない
　　エンジニアは本質的に課題解決が好き
　　　実感として課題を体験する
　　　　自然に解決しようとする
　プロダクトデザイナーが製品発見に参加していない
　　課題感なしにデザインはできない
　優先順位を変える
　　ころころ変わると混乱してやる気が下がる
　コンセンサス文化
　　根回しや承認作業が多すぎる

真のテーマ
　「製品開発文化」をつくる
　　製品発見
　　　持続的なイノベーション
　　　顧客に役立つソリューション
　　実行力
　　　アイデアを実行するサイクル
　強いイノベーション文化とは？
　　実験の文化
　　　リーンサイクルの理解
　　開かれた心の文化
　　　どんな経験もアイデアになる
　　　最初は良いアイデアもぼんやりしている
　　権限委譲の文化
　　　個人もチームも誰の許可なく実験できる
　　テクノロジーの文化
　　　真のイノベーションとは
　　　　顧客の悩みがきっかけとなり
　　　　新しい技術とデータによって生まれる
　　ビジネスと顧客に精通したチームの文化
　　　ビジネスニーズと制約への理解
　　　顧客への深い理解とアクセス方法がある
　　多様なスキルセットとスタッフの文化
　　　多様性がイノベーションに貢献するという確信
　　製品発見テクニックの文化
　　　リーンサイクルの環境が整っている
　強い実行力の文化とは？
　　切迫感の文化
　　　迅速に動こうとする
　　ハイインテグリティーコミットメントの文化
　　権限委譲の文化
　　説明責任の文化
　　　使命感を持っている
　　協力の文化
　　　チームとして動く
　　成果の文化
　　　焦点はどの指標でミッションは何なのか
　　認知の文化
　　　チームは報われたものや受け入れられたものから行動のヒントを得る
　　　　成功体験
　　　どちらが報われるか？
　　　　素晴らしいアイデアを思いついたチーム
　　　　過酷な責務を果たしたチーム
　　　

イノベーションと実行力はある程度トレードオフになっている
　　　

プロダクトマネジメントの原則は不変
　テクニックにこだわりすぎない
　　常に変化していく
　　　デジタル世界は常に環境が変わっていく
　　　　極度の進化論的状況
共通言語をもつ
　本当の顧客と頻繁に話す
　　自分たちの思い込みを防ぐ
　　　主観や思い込みの隙間を埋める
　　決まりや仕組みをつくる
　　　KPIと実行方法
　　
うまくいくソリューションの奥に本当の問題がある
　問題を明らかにして根本解決をする
　　PdMの仕事