書籍『Inspired 熱狂させる製品を生み出すプロダクトマネジメント』を要約しました。
PdMになりたい方、PdMを勉強中の方におすすめの本です。
ほとんどの一般的な企業のプロダクトマネジメントの方法は以下だが、うまくいかない。
アイデアを出す
アイデアについて議論する
アイデアが、どれくらいの価値や利益を生み出すのか
アイデアが、どれくらいの期間で完成できるのか
優先順位を決め、ロードマップを決める
要求仕様を決める
UI/UX仕様を決める
エンジニアに情報が届く
スプリントというプロセスで分割される
QAが行われ、リリース
ユーザーに届くまでに時間がかかる。実質的にウォーターフォール。
この手法の10の問題
ウォーターフォールプロセスは販売やステークホルダー主導の製品になる。開発チームへの権限委譲が行われない
どれだけ利益を生むか、開発コストはどの程度かは、この段階では分からない
ロードマップは、優先順位のリストでしかなくなる。2つの不都合な事実
半分もしくは3/4がうまくいかないアイデア
リリースまでには時間がかかる
エンジニアのために要求事項を集めて文書化することがプロセスにおいてのメイン業務になっているが、これはITプロダクトマネジメントと180度違う
デザインが豚に口紅状態（表面的にきれいにしても本質は変わらない）。UXデザイナーはやり方が間違っていると知っているが、無理して首尾一貫しているようみせている
エンジニアの出番が遅すぎる。プログラムを書かせるだけのためにエンジニアを使っているならエンジニアの価値の半分しか引き出せていない。エンジニアは議論のパーティに招かれていない。
アジャイル（スクラム）開発の利点を取り入れるのが遅すぎる。市場投入部分はアジャイル（俊敏）だが、それ以外が遅すぎる
プロセス全体がプロジェクト化している
ウォータフォールプロセスの最大の欠点は今も昔もリスクが最後にくる点。顧客実証が行われるのが遅すぎる。多くの開発チームはリーン原則を取り入れていると勘違いしている。あなた方は知りうる限り最も費用と時間のかかる方法でテストしている
プロセスの実行に時間と金を費やしているが、多くの機会損失を発生させている
最も優れた開発チームは上記の手法をとっているほとんどの開発チームより以下の点で進んでいる。
リスクには最後ではなく、最初に取り組む
価値のリスク（顧客が購入するか）
ユーザビリティーのリスク（顧客が使い方を理解できるか）
実現可能性のリスク（エンジニアが持っている時間とスキルとテクノロジーで実現可能か）
事業実現性のリスク（マーケティング、財務、法律）
製品の定義づけとデザインは順を追ってではなく強調させながら同時に作る
悪い例では、先行者の制約や決定に従って仕事している
持ちつ持たれつ、でやる
大切なのは機能を実装することではなく、問題を解決すること
重要なのはソリューションを実装するだけではなく、ビジネス上の成果が大切
優れたチームは2つを並行して行っている。
製品発見
PdM, エンジニア, デザインの協力によるもの
いいアイデアと悪いアイデアをすぐに判別することが製品発見。4つの重要な問い。
ユーザーはそれを買ってくれるか
ユーザーは使い方がわかるか
私たちのエンジニアはそれを作れるか
ステークホルダーたちの支持を得られるか
プロトタイプ
実際に導入する場合より時間が1桁違う場合にのみ作る
優秀なチームは毎週いくつものアイデアをテストする。週に10~20。あるいはそれ以上。
市場投入
売れてビジネスとして成り立つものを市場に投入することが目的
プロダクトマーケットフィットをMVPで達成する
ビルド、テスト、リリースが含まれる
2~10年後の製品ビジョンを掲げる
使命感を持っている
報酬目当ての傭兵ではなく、伝道師が必要 by ベンチャーキャピタリスト ジョンドーア
構成
PdM1人
デザイナー1人
エンジニア2人
上下関係はない
上司はエンジニアリングマネージャーなどであり、それぞれ上司がいる
席
機能ごとで別々ではなく、近くに座るべき。
期間
持続するものでなければならない
関係的な面
ノウハウ的な面
プロダクトへの愛的な面
自立性
依存関係を最小化する
完全独立は不可能だが、最小化する努力をする
❌判断をCEOに委ねる
❌全てのステークホルダーを会議室に召集し議論で決着をつける
⭕️プロダクトマネージャーが自分のやるべき仕事をする
主な責任
可能性を評価し、何を作って顧客に届けるか判断すること
条件
知識
顧客に関する深い知識
データに関する深い知識
自分のビジネスについての深い知識
市場と業界についての深い知識
頭がよく、創造的で粘り強いこと
知的好奇心がある。新しい技術など
とんでもない量の仕事量が求められる
プロダクトマネージャーの役割に最も近いのはCEO
ただしプロダクトマネージャーには部下がいない
プロダクトオーナーはプロダクトマネージャーが兼務すべき
プロダクトマネージャーの責任のごく一部にすぎない
責任範囲
製品の発見
ホリスティックなユーザーエクスペリエンスデザイン
メール、キャンペーン、カスタマーサポートも含む
UIだけではない
カスタマージャーニーに時間をかける
どう製品に出会うか
どう製品に馴染み、どう知っていくか
ユーザーとどんな連絡を取るか
ユーザーの関心を得るために他にできることはないか
どうやって満足の瞬間を作り出すか
ユーザーはどう体験を他人に共有するか
どうオフラインのサービスを受けるのか
体感的な製品の応答性はどうか
プロトタイプを作る
ユーザーテスト
毎週の習慣にしている
インタラクションデザインとビジュアルデザイン
悪い例
プロダクトマネージャーがデザインをする
プロダクトマネージャーが非常に高いレベルのユーザーストーリーを提供する
プロダクトマネージャーがワイヤーフレームを提供する
PdMの隣にデザイナーが座っていて貰わなければならない
隣にいてもらうために必要なことはなんでもする
デザイナーには全てのアイデアが生まれるところに立ち会ってもらう
デザイナーには顧客やユーザーとの交流にできるだけ多く参加してもらう
自分自身のデザインのアイデアを顧客に提供したいという誘惑と闘う
イテレーションを迅速かつ素早く動かすよう促す。そのためにデザインの詳細にとやかく言わない
特定のデザインアプローチを繰り返すのではなく、自由にほかの解決策を探るよう促す
エンジニアとの関係はPdMにおいて何より重要。両者が尊敬し合わなければならない。
PdMはエンジニアと協力を円滑にするためプログラミングを学ばなければならない。
顧客についての情報などを、エンジニアに対してオープンにする
議論のケースは2つ
アイデアを求める状況
エンジニアから詳細を確認する状況
多くのエンジニアは作りたいと思っているものを詳しく説明されることを嫌う
エンジニアに裁量権を与える。深夜に呼び出されて対応するのはエンジニアだ
問題や悩みはオープンに共有する
普通はフルタイムのメンバーではない
複数の製品開発チームを兼務する
ユーザーリサーチャー
データアナリスト
テスト自動化エンジニア
2つの不都合な真実。
アイデアはうまくいかない場合がある
価値の欠如（心が動かない）
ユーザビリティーの欠如（使いにくい）
実現性の欠如（思ったより難しい）
上記の問題を克服しても、経営陣が求める状態まで持っていくには時間がかかる
不具合が起きると、能力のないチームはその機能を要求したステークホルダーのせいにする
そしてイテレーションや設計のやり直しなどをロードマップに組み込むことを提案する
アイデアのプロトタイプを作ることができたら問題は起きにくい
2〜5年のもの。企業ビジョンとは異なる
製品ビジョンについて基本的な原則は、「全ての人を喜ばせようとすれば誰も喜ばない」ということ
WHYから始める
目的をはっきりさせる
解決策ではなく、問題に恋をする
臆病にならずに大きな視野でビジョンを考える
半年から1年で達成できるようなものはクソだ
チームを混乱させることを恐れない
製品ビジョンは人の心を揺さぶらなければならない
関連性があり意味のあるトレンドを見つけ出し、取り入れる
ボールがある場所ではなく、ボールが転がっていくところに走っていく
ビジョンには頑固で、ディティールには柔軟でいる
どんな製品ビジョンも信じて賭けることだと考える
絶え間なく粘り強く説得して回る
1度につき、1つのターゲット市場やペルソナに集中する
製品戦略はビジネス戦略と整合する必要がある
製品戦略は販売戦略やGoToMarket戦略と連携する必要がある
ライバルではなく顧客のことだけを考える
組織全体で戦略についてのコミュニケーションをとる
製品理念は、製品ビジョンと製品戦略を補完するもの。
ebayの例
収益のほとんどは売り手から得られるものだったので、売り手を喜ばせようとしていた。しかし、売り手が喜ぶのは買い手を提供してくれることと分かった。そこから次の製品理念が生まれた
「買い手と売り手のニーズがぶつかる場合は、買い手のニーズを優先する」
製品について布教するのはPdMの仕事
以下のリスクを下げること
顧客はこれを買ったり使うことを選んでくれるだろうか（価値のリスク）
ユーザはこれの使い方が分かるだろうか（ユーザビリティのリスク）
私たちはこれを作れるだろうか（実現可能性のリスク）
このソリューションは私たちのビジネスに貢献するだろうか（事業実現性のリスク）
原則
何を作るべきか顧客は教えてくれない
最も重要なことは説得力のある価値を確立すること
優れたユーザーエクスペリエンスを作り出すことは、エンジニアリングと同じように難しい
ウォーターフォールでは市場から機能が決まり、デザインが決まり、デザインによって実装が決まっていた。ただアジャイルは、機能・デザイン・技術は本質的に絡み合っている。デザイナー・エンジニア・PdMが物理的に隣同士に座るべき最大の理由がそれである。
アイデアの多くはうまくいかないものだし、うまくいくものも何回かのイテレーションが必要になる
アイデアの妥当性は実際のユーザーや顧客で立証しなければならない
製品発見の目標はできる限り迅速にコストをかけずにアイデアの妥当性を検証すること
製品発見の間にアイデアの実現可能性を立証する必要がある。後ではだめ。スプリントプランニングの際に開発者が初めてアイデアを知るようではすでに失敗。最終的に無駄な時間を減らせる。
共同学習が大切。傭兵ではなく伝道師のチームを作る上で1つの鍵となるのは、チームが一緒に学習することである。文脈を全員が理解すること
4つの問い
この仕事はどんなビジネス目標を達成しようとしているのか
乗り換えを防ぐ
新規獲得に時間がかかる
何をもって成功とするか
この仕事は顧客のどんな問題を解決するか
どんな種類の顧客をターゲットにするか
PdMはこの問いに2,3分ですぐに答えられるようになるが、チームが全員答えられる状況にしておかなければならない。
製品を作るよりも1桁時間が少ないこと
議論や書いたりする場合より、開発チームが深いレベルで考えられる
プロトタイプは開発チームが協力するためのツール。共通の理解を深める
プロトタイプには忠実度がある。高ければいいというわけではないので、場合によって使い分ける
仕様書としてのプロトタイプにもなる
様々な問題で実現可能性が不明な場合がある。
アルゴリズム
性能
フォールトトレランス
システムや機器の一部が故障・停止しても、予備の系統に切り替えるなどして機能を保ち、正常に稼働させ続ける仕組み
開発チームがそれまで使ったことがない技術
開発チームがそれまで使ったことがないサードパーティの部品やサービスの使用
1〜2日を使ってチェックする。機械学習などの場合にはもっとかかる場合が多い。
（やり方は専門書を参考）
ユーザーを集めるためには以下のやり方がある。
広告を出す
ユーザーのメールアドレスから募集
ユーザーの集まる場所に訪問する
カフェなどユーザーが訪れやすい場所でやる
ステークホルダーがロードマップを敷きたい理由は以下。
何に取り組んでいるかについて目に見えるものを求めている
ビジネスのプランを立てられる立場にいたい
組織が注目するポイントを特定の時期に特定のものをリリースすることから、ビジネス成果に移すことが重要。
2週間に1回ほどPdMがチームへ製品開発で学んだことを共有する
こまごまとしたことではなく、大きな意味での学習を共有する
何がうまくいき、何がうまくいかなかったのか。次開発チームは何に取り組むべきか等。