INSPIRED の商品レビュー

マーティ・ケーガン(著者),神月謙一(訳者),関満徳(監訳),佐藤真治(監訳)

2025/01/05

新しいプロダクトを作るときにプロダクトを作る人に参考になる本

以下メモ

リーンなプロダクト開発の中心テーマ
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. 自社製品に乗り換えさせるために何が必要か？
・インタビューの間に何かを証明しようとしない、理解と学習に努める
・コンシェルジュテスト：顧客に変わり手作業で顧客の仕事をすること、
・プロダクトアウト、マーケットイン以外に顧客が予期せぬ使い方をするところから可能性を広げる方法もある

需要テスト
・リリースしてから価値がなかった、は最も避けるべきでかつ容易に避けられる。
・フェイクドアテスト: 適切な箇所に新機能のボタンを追加し、特殊なページに遷移させる。そこがテストの協力フォームになる。需要に関する適切な証拠と新しい機能を使いたいユーザーリストが手に入る

2024/04/04

・参考図書指定科目：「プロダクトマネジメント」

＜OPAC＞
https://opac.jp.net/Opac/NZ07RHV2FVFkRq0-73eaBwfieml/YqCkqKGJ0kbMDZqmAdfgVZ9IG_k/description.html

2022/08/21

プロダクトマネジメントの必要なものを話す本
ちょっと広すぎるというか、色々書いてて良いんだけどまとめてくれたらなあと。

製品発見・プロトタイプ・市場投入・マーケットフィット
開発チーム、構成・使命・権限委譲・説明責任・規模・上下関係・協力・場所・業務範囲・継続期間・自律性
プロダクトマネージャー、責任、顧客・データ・ビジネス・市場と業界知識、頭がよく粘り強い、

2022/04/27

製品開発は、
　プロダクトマネージャー
　プロダクトデザイナー
　エンジニア
が主たるメンバーとなるチームを組んで取り組むものである。
日本の製造業においては、
プロダクトに対するCEOである
プロダクトマネージャーは、いない。
また、プロダクトデザインを担当する人もいない。

製品開発は、
　アウトプットでなくアウトカムを基準に
　バタンリレーでなくチームプレイで
　できることからでなく、重要なことから
取り組むことが大事である。

これまでは、リリースすること、
つまり、とにかく機能をつくりきることを
目標にしてきた。
リリースすることが目標なのではなく、
製品によって、顧客の課題が解決され
結果、自社ビジネスが成長することが目標。
ここに、組織の力を集中させるために、
OKRが活用できる。
Objectives and key results

ウォーターフォールで、工程ごとに主担当がわかれてきた。
このため、前工程への理解が足りずに
結果手戻りをしてきた。
関係が前工程から検討にはいり、
短いスパンで何度も検討する。
これがアジャイルであり、リーン。

やりやすいことは、機能の開発。
そのまえに、
　顧客は買ってくれるのか
　使ってくれるのか
　作れるのか
　ビジネスとして成り立つのか
に答えなければならない。

2022/04/07

PdMの役割を知るには良い教科書。どのような人がPdMに向いているか、どのようか役回りをするポジションなのか、どのようなマインドセットを持っているべきかというのが理解できました。

2022/03/27

プロダクトマネジャーではなく、その役割に近いところのビジネスサイドで仕事をするにあたり、役割の理解が深まった。アジャイル風の、アイデアベースのウォーターフォール開発では失敗する。エンジニアをはじめとしたプロダクトチームが真に顧客や事業の課題や背景を理解し、積極的に参加してサイクルを回すことこそ、真のアジャイル事業経営につながる。

2021/10/03

プロダクトマネージャーとはどんな仕事か？が分かる本
良い開発文化やチームについても理解を深められる（ここら辺は「ユニコーン企業の秘密」と共通している）
プロダクトマネージャーの仕事はCEOの前段階と言われるほど大変

「製品開発チームが全てだ」「傭兵ではなく伝道師のチーム」
これらの言葉が印象に残った

2021/09/10

最初の方はいい本かなーと感じていましたが、中盤からは抽象的な議論になってきた印象。大事なことは書かれているのですがどこから手をつけたらいいのかわからないくらいやらなければならないことが多い感じ。

2021/04/25

書いてあることはもっともだけど話の全体感が掴みにくく、今ひとつ読みづらかった。プロダクトマネジメント(ビルドトラップ本)の方が簡潔にまとまっていて良いかも

2021/01/11

プロダクトマネジメントの全体像を概観するのに良い。ただ噂に聞いていた通り訳がなかなかに気持ち悪く、原書を読んでみたいなと思いました…