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