作品一覧

  • TRANSFORMED イノベーションを起こし真のDXへと導くプロダクトモデル

    TRANSFORMED イノベーションを起こし真のDXへと導くプロダクトモデル

    ビジネス・実用

    -
    1巻2,970円 (税込)
    【内容紹介】 累計25万部と世界中(19カ国で翻訳)で読まれた シリコンバレーのプロダクトマネジメントのバイブル 『INSPIRED』の著者が教えるトランスフォーメーションの実現方法! 日本が見失った目指すべきDXはここにある! レガシー企業がここまで変わる!DXの本質と実践! 【本書に掲載している事例】 - 旅行代理店→地域シェア70%獲得 - 鉄道会社→5億ポンドの買収から評価額20億ポンド(3800億円)でヨーロッパ最大規模のIPO、「鉄道業界のUber」と呼ばれる - フィットネス会社→4週間で10カ国に展開、数カ月でユーザー数をゼロから数十万人に - 金融向け印刷会社→リブランドして新事業を立ち上げ、既存事業比で収益30%UP - 健康保険組織→全米のどこからでも24時間365日ケアを受けられ、満足度96%を記録 シリコンバレーが世界を席巻する理由は、「プロダクトモデル」で運営されていることにある。 顧客に愛され、ビジネスにも有効なテクノロジーパワードなソリューションを継続的に生み出す方法だ。 その方法がDXの本質である。起こすべき変化は以下の3つだ。 1. 作り方を変える 2. 問題解決の方法を変える 3. 解くべき問題の決定方法を変える これらを支えるのが、プロダクトマネジャーに代表される「プロダクトモデル・コンピテンシー」と、プロダクトチームの指針となる第一級原則群の「プロダクトモデル・コンセプト」である。 肩書の変更や人材の寄せ集め、アウトソーシングでは決してたどり着けない、トランスフォーメーションを成功させる要因が凝縮されている。 さらに、著者の長年にわたる企業支援の実績に基づき、トランスフォーメーションを進める上での重要なトピックや、想定される反対意見への対処法まで詳しく解説している。 多くの企業は、DXの現状と理想の姿の間にギャップがある。 本書はそのギャップを埋めるため、プロダクト企業での経験がないリーダーのために どんな企業であれ、この時代に必要な本当の変革ができることを示してくれる一冊である。 【目次】 PART Ⅰ トランスフォーメーションはなぜ困難か PART Ⅱ トランスフォーメーションの定義 PART Ⅲ プロダクトモデル・コンピテンシー PART Ⅳ プロダクトモデル・コンセプト PART Ⅴ トランスフォーメーションのストーリー:Trainline社 PART Ⅵ プロダクトモデルの実践 PART Ⅶ トランスフォーメーションのストーリー:Datasite社 PART Ⅷ トランスフォーメーションのテクニック PART Ⅸ トランスフォーメーションのストーリー:Adobe社 PART Ⅹ 反対を乗り越える PART Ⅺ トランスフォーメーションに不可欠なこと
  • EMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダーシップ

    EMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダーシップ

    ビジネス・実用

    4.0
    1巻3,080円 (税込)
    なぜアマゾン、アップル、グーグル、ネットフリックス、テスラなどの企業は、イノベーションを起こし続けられるのか。 ほとんどの人は、優秀な才能を採用することができるからだと考えている。しかし、これらの企業が持つ本当の強さは、採用する人ではなく、従業員が協力して困難な問題を解決し、並外れた製品を生み出すようにする方法にある。 本書では、こうしたイノベーションを生み出す環境のためのプロダクトリーダーシップを紹介する。トップテクノロジー企業の最高のリーダーから学んだ何十年にもわたる教訓をガイドとして提供し、チームと会社にとって必要なリーダーになる方法をあなたに示す。 【目次】 PART I:一流テクノロジー企業から学んだこと PART II:コーチング PART III:人事 PART IV:製品ビジョンと原則 PART V:チーム・トポロジー PART VI:製品戦略 PART VII:チームの目標 PART VIII:ケーススタディ PART IX:ビジネスコラボレーション PART X: インスパイアされ、エンパワードされ、トランスフォームする
  • INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

    INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

    ビジネス・実用

    3.8
    1巻2,860円 (税込)
    大幅な書き直しをした2ND EDITION 日本に足りないのはプロダクトマネジャーだ! Amazon, Apple, Google, Facebook, Netflix, Teslaなど、最新技術で市場をリードする企業の勢いが止まらない。はたして、かれらはどのようにして世界中の顧客が欲しがる製品を企画、開発、そして提供しているのか。 本書はシリコンバレーで行われている「プロダクトマネジメント」の手法を紹介する。著者のマーティ・ケーガンは、成功する製品を開発するために ・どのように組織を構成し ・新しい製品を発見し ・適切な顧客に届けるのか を、具体的な例を交えながら詳細に説明する。 Adobe、Apple、BBC、Google、Microsoft、Netflixの、今日最も成功を収めているプロダクトマネジャーと そのテクノロジーを活用した製品企業のプロファイルも紹介。スタートアップ企業から、成長企業、世界的な大企業まで、多くの読者に対応し、学習した情報をいますぐ自分の組織内で活用して、製品と製品開発組織を劇的に改善できる! プロダクトマネジャー、エンジニアはもとより経営者、スタートアップ、新規事業開発担当も必読!

ユーザーレビュー

  • INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

    Posted by ブクログ

    ちゃんとした利益を得るにはなんとなく10年先は見ておかないと厳しいような気がしてきた。あと、物事には正解がないし、運ゲーだし、自分が良かれと思ったアイデアは、どんなに賢い人でも少なくとも3/4は望んだような結果が出ないらしい。

    競争力のあるIT製品を生み出すためには、テクノロジーや製品開発組織の枠を超えた、劇的で意味のある改革が必要だ。

    売れるプロダクトを作るには顧客第一、デザイナー必須、プロダクトビジョンを明確に…等

    【メモ】
    リスクは最初に取り組む
    価値のリスク(顧客が購入するかどうか)
    ユーザビリティのリスク(ユーザーが使い方をわかるかどうか)
    実現可能性のリスク(エンジニアが、持っている時間とスキルとテクノロジーで必要なものが作れるか)
    事業実現性のリスク(ソリューションが、販売、マーケティング、財務、法律など、ビジネスのさまざまな分野でもないかどうか)

    機能を実装することではなく、問題を解決すること

    ホリスティック(全体論的)な製品
    機能、つまり特徴が含まれる。
    機能を実現する技術が含まれる
    機能を提示するユーザーエクスペリエンスデザインが含まれる
    機能を金銭に変える方法が含まれる
    ユーザーや顧客を惹きつけて獲得する方法
    その価値を伝えるのに欠かせないオフライン体験

    製品発見
    ユーザーはそれを買ってくれるか?
    ユーザーはその使い方をわかるか?
    私たちのエンジニアはそれを作れるか?
    ステークホルダーたちの支持が得られるか?

    「プロトタイプ」
    製品やサービス、システム開発の初期段階で作られる「試作品」や「原型」のこと

    報酬目当ての開発チームは、作れと言われたものを作る。使命感を持った開発チームはビジョンを信じ、顧客のために問題の解決に全力を傾ける。

    プロダクトマネージャ
    「会社の中で最も才能のある人材の1人であるべき」

    プロダクトマネージャにあるといいもの
    技術に関する高度な知識やビジネスの腕前
    主要な幹部との信頼関係
    顧客に関するふかい知識
    製品に対する情熱
    製品開発チームへの敬意がある

    四つの重要な責任
    顧客に関する深い知識(問題、悩み、欲望、考え方、仕事のやり方や購入の意思決定方法)
    データに関する深い知識(A/Bテストなど)
    自分のビジネスについての深い知識(ステークホルダー:統括管理、販売、マーケティング、財務、法務、事業開発、カスタマーサービス)
    市場と業界についての深い知識(ライバル企業、キーとなる技術の動向、顧客の行動と期待、関連する産業のアナリストのフォロー、市場の顧客に影響を与えるソーシャルメディアの役割) 

    頭がいいとは
    知的好奇心にあふれる
    新しい技術をすぐに習得できる
    顧客の問題を解決できる
    新しい顧客の心を掴める
    新しいビジネスモデルを作る

    粘り強いとは
    説得力のある根拠を持つ
    常にコミュニケーションを取る
    頑強な反対に直面しても組織の間の橋渡しをする
    企業を動かしてコンフォートゾーン(心理的な安全領域)から押し出す力がある

    プロダクトマネージャの準備
    ユーザーや顧客の専門家になる(質的、量的)
    学んだことは開発チームで共有する
    チームや企業で頼られる人になる
    目に見えない制約を理解
    制約の下で実行できると考える解決策を提案
    製品や業界に関して誰もが認める専門家になる(広い心で積極的に)
    強固な協力関係と育てるために懸命に努力

    顧客との接点
    メール
    マーケティングキャンペーン
    販売プロセス
    カスタマーサポート
    最初にどうやって製品を知るか?
    どうやって初めてのユーザーが製品に馴染み、どんな方法で連絡を取るか
    一日のうちどんな時間帯に、どんな方法で連絡をとるか
    ユーザーの関心を低くために、他にできることはないか
    顧客歴1ヶ月の人と顧客歴一年のひとではどこが違っているか
    ユーザーに製品に対するもっと高い関心を持ってもらうためにはどうすればいいか
    どうやって満足の瞬間を作り出すか
    ユーザーは、どうやって自分の体験を他人と共有するするのか
    顧客は、どのようにオフラインサービスを受けるのか
    体感的な製品の応答性はどのようなものか

    ユーザーリサーチャー
    定性的な学習(解決すべき問題を理解しようとする創造的研究と、ソリューションがどれだけ上手く問題を解決するかを評価しようとする評価的研究)
    適切なユーザーを見つける
    適切なテストを作る
    ここのユーザーや顧客とのコミュニケーションから最大限のことを学ぶ手助けをする

    データアナリスト
    適切な分析データを集めるのをサポート
    データのプライバシーに関する制限
    データ分析
    ライブデータテストの計画を立て、その結果を解釈し説明

    ビジネス観点
    製品のビジョン
    戦略
    機能
    ビジネスルール
    ビジネスロジック

    チーム開発
    能力のない人を選んで昇進させ、リーダーの地位に就けることが1番いけない。
    地位的には人材を育成する能力において確かな実績のある人物を雇う必要がある。その人物は、潜在的な才能を見つけて採用し、一緒に積極的に仕事を就ける中で弱点を克服させ、長所を引き出してきた経験を持っていなければならない。

    どんな組織についてか
    アーキテクチャ
    エンジニアリング
    品質
    サイト運営
    サイトのセキュリティ
    リリース管理
    市場投入のマネジメントに責任を持つ組織

    CTO責任
    組織(全ての従業員の育成計画、定着率、製品開発・技術組織全体のそのマネジャーに対する他部門からの評価)
    リーダーシップ(企業の進路、M&A活動、作る/買う/連携するに関する決定を助ける)
    市場投入(高品質な製品を、迅速に、確実に、繰り返し、市場に送り出す)
    アーキテクチャ(機能性、拡張性、信頼性、セキュリティ、性能)
    製品発見(イノベーションの頻度)
    エバンジェリズム(広報担当者の役割、開発者、定型企業、顧客たのコミュニティ)

    ビジネスに関する目標
    顧客獲得コストを下げる
    1日のアクティブユーザー数を増やす
    新規顧客を獲得するまでの時間を短くする

    「エバンジェリズム」
    本来はキリスト教の「福音伝道(よい知らせを伝えること)」を意味し、現代のビジネスシーンでは、革新的な製品・サービスの技術や魅力を熱意を持って広く伝え、熱狂的なファンや市場を創造する活動やプロセス

    プロダクトマネージャの夢を売るためのアドバイス
    プロトタイプを使う。
    悩みを共有する。
    ビジョンを共有する(製品びか、製品戦略、製品理念)
    学習したことを惜しみなく共有する(上手く行ったことや問題)
    成果を惜しみなく共有する。
    優れたデモを行う方法を学ぶ。
    常に学習に励む。(競争相手や関連するトレンド)
    心からワクワクする。
    熱意の見せ方を学ぶ。(熱意は伝染する)
    チームと一緒に時間を過ごす。

    「BBC」
    英国放送協会

    新しいテクニックを取り入れる方法
    何を作るべきか教えてくれるように顧客に頼むことはできない。
    最も重要なことは、説得力のある価値を確立すること。
    優れたユーザーエクスペリエンスを考え出すのはそれ以上に困難である事が多く、さらに製品の成功には欠かせない。
    機能、デザイン、技術は、本質的に絡み合っている。
    アイデアの多くはうまくいかないものだし、うまくいくものも何回かのイテレーションが必要になると予測する。
    アイデアの妥当性は実際のユーザーや顧客にで立証しなければならない。
    製品発見の目標は、できる限り迅速に、コストをかけずにアイデアの妥当性を立証する事である。
    製品の発見の間に、アイデアの実現可能性を立証する必要があると。後ではダメだ。
    製品発見の間に、アイデアの事業実現性を立証する必要がある。後ではダメだ。
    共同学習が大切である。

    リスク
    財務上(資金的な裏付けがあるか)
    事業開発(パートナーに貢献するか)
    マーケティング(企業ブランドに合ってるか)
    販売(売る体制が整っているか)
    法的(法務やコンプライアンスの観点)
    倫理的(倫理的に開発していいか)

    製品発見の仕事の質問
    この仕事はどんなビジネスの目標を達成しようとしているのか?
    何を持って成功とするのか?
    この仕事は顧客のどんな問題を解決するするのか?
    どんな種類の顧客をターゲットにするか?

    顧客発見プログラム
    ビジネス向けの製品を開発する
    プラットフォーム製品(パブリックAPIなど)を開発する
    自社の従業員が使う顧客対応ツールを開発する
    コンシューマー向けの製品を開発する

    重要なひらめき
    顧客はあなたが考えてたような人たちか?
    本当にあなたが考えているような問題を持っているか?
    現在、その問題をどうやって解決しているか?
    自社製品に乗り換えさせるためには何が必要か?

    「エンドユーザー」
    商品やサービスを最終的に使用・消費する「末端の利用者」のこと

    実現可能性のリスク
    アルゴリズム
    性能
    拡張性
    フォールトトレランス
    それまで使ったことのないテクノロジーの使用
    サードパーティ製の部品やサービスの使用
    レガシーシステムの使用
    他の開発チームによる新たな変更や、関連する変更への依存

    ライブデータプロトタイプ
    フルセットのユースケース
    自動化テスト
    完全な分析計装
    国際化とローカリゼーション
    性能と拡張
    SEO作業

    製品発見
    ユーザーや顧客はこれを使ったり買ったりすることを選んでくれるか?(価値)
    ユーザーはこれの使い方がわかるか?(ユーザビリティ)
    私たちはこれをビルドできるか?(実現可能性)
    このソリューションはビジネスに貢献するか?(事業実現性)

    定性的価値テスト
    インタビュー
    ユーザビリティテスト

    特殊な価値テスト
    価値を実証するのにお金を使う
    批判を使う
    時間を使う
    アクセス情報を使う

    定量的価値テスト
    A\Bテスト
    招待制テスト
    顧客発見プログラム
    ユーザーや顧客の行動を理解する
    製品開発の進行を測る
    製品のアイデアがうまくいくかどうかを証明する
    製品開発に関わる判断を情報で裏付ける
    製品開発の仕事にひらめきを与える

    IT製品にとって欠かせない分析
    ユーザーの行動分析(クリックパス、エンゲージメント)
    ビジネス分析(アクティブユーザー、コンバージョン率、生涯価値、リテンション)
    財務分析「ASP、ビリング、タイム・トゥ・クローズ」
    性能(ロード時間、稼働時間)
    運用コスト(ストレージ、ホスティング)
    市場開拓コスト(顧客獲得コスト、販売コスト、プログラム)
    センチメント(NPS、顧客満足度、調査)

    分析はしばしば、KPI(重要業績評価指標)と呼ばれる

    イノベーション起こし方
    顧客中心の文化
    魅力的な製品ビジョン
    的を絞った製品戦略
    強力なプロダクトマネージャ
    安定した製品開発チーム
    製品発見へのエンジニアの参加
    企業の勇気
    権限を与えられた製品開発チーム
    製品開発のマインドセット
    イノベーションを起こすための時間

    スピードが失われる理由
    技術的負債
    強力なプロダクトマネージャの不在
    デリバリーマネジメントの欠如
    リリースサイクルの長期化
    製品ビジョンと戦略の欠如
    同じ場所にいて、長続きする開発チームの不在
    製品開発に早い時期からエンジニアを参加させない。
    製品発見にプロダクトデザイナーを使わず、エンジニアがビルドしている間にプロダクトデザインの仕事をさせようとする。
    優先順位を変える
    コンセンサス文化

    0
    2026年03月12日
  • INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

    Posted by ブクログ

    ネタバレ

    噂に聞く素晴らしい本。PdMのバイブルと言われるのも納得。
    ネタバレですが、メモです。
    -------------
    - チームメンバーを伝道師にする。傭兵のチームでは無い
    - 使命感を持った開発チームはビジョンを信じ、顧客のために問題の解決に全力を傾ける
    - チームが一緒に学習する。チームは顧客の悩みを一緒に受け止め、あいであが失敗するのを経験して何が重要で何をすべきかの文脈を全員が理解する

    - プロダクトマネージャ
    - 何を顧客に届けるのかを判断する(製品発見)のが主な仕事
    - 多くの顧客に有効な1つのソリューションを考え出す(顧客の数だけ考えるのでは無い)
    - 製品発見の鍵は、顧客と対話すること
    - できるだけ迅速に、コストをかけずにアイデアの妥当性を見つけ出す
    -
    - 下記知識を持つ
    - 顧客に関する深い知識
    - データに関する深い知識
    - 自分のビジネスについての深い知識
    - 市場と業界についての深い知識

    - 効率的な

    - エンジニアがPMFするための製品探し(製品発見と呼んでいる)も行うべき


    - 有能なチームは即座にリスクに取り組み、有効なソリューションに対しイテレーション(PoC検証)を何度も繰り返し実行する
    - アイデアのプロトタイプをtくり、ユーザー、顧客、エンジニア、ビジネスホルダーに対しテストする
    - 1週間に10~20イテレーションを行う

    - エンジニアは機能を提供するのがゴールではなく、本質的な問題を解決する必要性がある

    - エンジニアのパフォーマンスは結果で測定
    - ビジネスの根本的な問題を解決できなければ何も解決したことにならない
    - 製品開発チームは企業がどこへ向かっているかを確実に把握し、大きな目標に対して自分のチームがどのように貢献するのが望ましいか理解する必要性がある

    - どうやるかを指示してはいけない。何をすべきかを指示すればよい。そうすればエンジニアは創意工夫するだろう



    - プロダクトマネージャによる製品に関するエバンジェリズム
    - プロトタイプを見せる
    - 顧客の悩みを開発チームと共有する
    - 我々の仕事がそのビジョンにどれだけ貢献し、どれだけ理念に忠実であるかを見せる
    - ユーザテストや顧客訪問の後は必ず学習したことを共有する。チームみんなで考える
    - 開発チームが製品はプロダクトマネージャのものでは無く、自分たちのものだと思えるようにする
    - 失敗した場合はPdMがすべての失敗の責任を引き受け、失敗からも学べることをチームに示す
    - あなたが心からワクワクしていると周りの人に伝わるようにする
    - デザイナーやエンジニアと顔を合わせて十分な時間を使う
    - メンバーはあなたの目に宿る熱意を見ることができる
    - 相手のモチベーションのレベルが変わる

    - カスタマーレター テクニック ★★
    - 架空のプレスリリースを書く(ワーキングバックワードプロセス)
    - それはどのように顧客の生活を向上させるのか?
    - 顧客の利益は何か?

    - 開発チームがこのプレスリリースを見て胸を躍らせないなら、それは実行する価値が無い

    - 開発チームをアウトプットでは無く、アウトカム(結果)に集中させる
    - 開発チームが機能の一覧表にすぐ取り掛かるのは良くない

    - さらなる進化系
    - 仮想的なカスタマーレター
    - その製品によって顧客の生活がどんなふうに代わり向上したかが書かれている

    - カスタマーレターの方が顧客の現在の共感を生む効果が高い
    - 自分たちの仕事がどのように顧客の生活に役に立ちうるかを開発チームにより明確に印象づけられる

    - スタートアップキャンバス
    - 製品の全体像を的確に把握できる
    - ビジネスのどういう分野に影響を与えるかを理解することが容易になる

    - リスクに光を当ててくれる
    - 最大のリスクにこそ真っ先に取り組まなければならない

    - 顧客発見
    - 6つのリファレンスカスタマーを見つける


    - プロダクトマーケットフィット
    - もしその製品が使えなくなったらどう感じるか?
    - 「非常に残念」と答えたユーザーが40%以上ならばPMFしている可能性高い

    - 良いチーム
    - 人を魅了する製品ビジョンを持っていて、伝道師のような情熱で追及する
    - エンジニアが毎日プロトタイプを試す時間を確保し、製品をよりよくする方法について、自分たちの考えを提案できるようにする
    - 毎週エンドユーザーと関わって、顧客をよりよく理解し、自分たちの最新のアイデアに対する顧客の反応を見る
    - 望んだアウトカムを生み出すためには何回かの繰り返しが必要になると考えている
    - 良い開発チームはスピードが必要であり、イテレーション(繰り返し)が適切なテクニックからくると知っている
    - 自分たちの製品がどんなふうに使われているかを知るために製品にデータ取りを実装し、データに基づいて調整する
    - 良い開発チームは業績に大きく貢献した時に祝う(悪いチームはリリース時に祝う)

    - スピードが失われる理由
    - PdMが開発チームに動機や使命感を与えられてこなかった
    - 仕事の全体像と目の前の仕事がどのように全体に貢献するかについて開発チームがビジョンを持つことが重要

    - 強い製品開発文化
    - 実験の文化。テストの多くは失敗することを知っている。失敗が受け入れられることを知っている
    - 優れたアイデアは最初は必ずしもその良さがわからないことを知ってる

    0
    2025年12月28日
  • INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

    Posted by ブクログ

    プロダクトマネジメントの原則、成功するチーム・リーダーと失敗するチーム・リーダーの違いを説明した本。
    多くのIT企業のプロダクトマネジメントに関わってきた著者の経験則が原則のかたちでまとめられている。魅力的な製品を生み出すためにはどう言った組織・チーム・人にどんな文化、ビジョンが必要かといった言及がされている。
    成功のためのプロセスとして、製品発見のためのテクニックがいくつか紹介されている。私にとって、何度も読み返す必読書になるだろう。

    0
    2025年07月20日
  • INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

    Posted by ブクログ

    事業会社で事業立ち上げメンバーとしてPdM、PO、EMしています。メンバーが増えていくにつれてどのような組織体制にしていくべきかモヤモヤしているところでこの本に出会いました。PdMや開発チームの責務やマインド、プロダクトビジョンの必要性など私がモヤモヤしていた内容が多く書かれていました。
    特に前半の成功するための組織と人のパートはとても参考になることが多く、繰り返し読んで自分の言葉や自分の事業に当てはめて語れるようになりたいと思います。

    0
    2025年04月30日
  • EMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダーシップ

    Posted by ブクログ

    機能開発チームとエンパワードチームの対比からエンパワーされていることの重要性を説き、いかにエンパワーしていくか、そのうえでいかに目標を定めプロダクトを成長させていくか詳細に解説されている。
    ここではBig Techを目覚ましい成功に導いたOKRが、なぜ多くの組織では機能不全を起こしているのかといった点にも触れており目標設定にうまくいかなさを感じている向きにはこの節だけでも読んでもらいたい。

    0
    2023年06月13日

新規会員限定 70%OFFクーポン 今すぐGET