プロダクトマネジメントの活動群を表す図 〜対話と行動のツールとして
プロダクトマネジメントの主な活動の全体像と、各活動の相互影響を表すことを試みた図を共有します。以下がその図です。
Product Management Activities の図
PDF版ダウンロード↓
この図について
プロダクトマネジメントの主な活動の全体像と、各活動の相互影響を表すことを試みた図です。
プロダクトマネジメントに画一的・統一的なプロセスは存在しませんが、多くのプロダクト企業で行われる傾向のある活動をある一つの形として表してみました。
特にプロダクトチーム（プロダクトマネージャーを含む）、プロダクトリーダーの方々に役立てて欲しいと思っています。
図を作成した背景
この図は、「プロダクトマネジメントの活動の全体像」を話したい時に使えるちょうど良い図を見つけられなかった、というきっかけから描いたものです。
しかし、この図を描く過程、図を説明する中で、特に強調していることがあることに気がつきました。自分自身の失敗や、さまざまな人から聞くプロダクト組織の課題が想起されたのです。
プロダクトチームが（プロダクトマネージャーですら）、ディスカバリーに関わらない役割分担になってしまっている。
「ディスカバリー（Discovery）」と呼ばれる活動が、戦略上の機会の探索や、作るべきものの探索ではなく、要望リストに書かれている内容を要件定義（Definition）するだけになってしまっている。
プロダクトチーム（プロダクトマネージャー、エンジニア、デザイナーなど）が、一次情報に触れないまま、又聞き情報だけでプロダクトを作ってしまっている。
「問題が実存するか」「価値と需要があるか」を検証せずに、「プロダクトを作る」プロセスに突入し、使われないものを量産してしまっている。
プロダクトデリバリー後に、成果の評価（Evaluation）を行なっておらず、作りっぱなしになってしまっている。
主要なプロダクトマネジメント活動が、過剰な役割分断・工程分断・一方通行プロセスのもと遂行されてしまっている。
プロダクトチームと（プロダクトマネージャーですら）、 Go-to-Market チーム（マーケティングや営業、カスタマーサクセスなど）の関係性が最低限になってしまっている。
ロードマップは存在するものの、ビジョンや顧客価値の面での「目指すべき将来像」からの逆算ではなく、目の前の要望の積み上げになってしまっている。
プロダクトチーム（プロダクトマネージャーですら）、ビジネス戦略やGo-to-Market 戦略を理解しておらず、プロダクトでどのようにビジネスに寄与するのか、への意識が低くなってしまっている。
プロダクトの勝ち筋（プロダクト戦略）が意思決定されていない。
ビジネス戦略とプロダクト戦略の両方を立案すべきリーダーが、どちらかの視点でしか考えられていない。
ビジネス戦略を立案するリーダーとプロダクト戦略の立案するリーダーが分かれている場合に、その両者が良い緊張感関係、かつ協調関係の上で連携できておらず、水準の高い戦略になっていない。
戦略が探索から得たインサイトをもとにしておらず、机上の空論になっている。
プロダクトビジョンが存在しない。もしくは、プロダクトビジョンが意思決定や、チームの士気の向上に役立たないものになってしまっている。
もちろん上記のような状態であっても、プロダクトとビジネスが成功していて、目指す世界に近づいており、関わる人たちが幸せなのであれば（そしてそれらが今後も続きそうであれば、）何の問題もありません。また、「活動（群）」が問題の本質でない場合も多くあります。しかし、上記のような状態がそれらの成功を阻害している原因でありうるのであれば、こういった図がその一助になるのではと思っています。
プロダクトコーチングでこの図を使う際は、私からの一方的な説明ではなく「対話と行動のきっかけ」としています。「ここに時間を使えていない」「ここは今かなり力入れるべき」などの話から始まり、「さらなる成果のために、エネルギー配分を組み換えよう」のような具体的な行動に発展します。解釈の相違や、誤読すら議論・行動のきっかけになります。
また、この図を公開するにあたって多くの方からフィードバックをいただきました。共感や違和感のポイントは十人十色で、その方の経験からくる強い信念が伝わり、敬意を覚えました。そして「そういった考えを聞くきっかけになったことも、この図の存在意義」だと感じました。
この図を見たプロダクト人材が、自組織やチームの中で、「この図ってどう思う？」「ここは違う。私たちならむしろこうあるべきでは？」「ここは大切だよね」と対話し、さらにその対話から、成果のための行動が生まれることで、さらにプロダクトの成功確率が上がると思います。プロダクトリーダーが自分の考えを発信し、対話の起点にすることにも使えるでしょう。つまりこの図は、一人で座学するため、というよりは対話とその先にある行動のきっかけとして使っていただければと思います。
また、やや余談ですが、2025年6月現在のAIの台頭の中にいると、「プロダクトマネージャー」（にかかわらず多くのプロダクト関連職種）のステレオタイプ的な職務定義を解体し、「本来なすべきこと」に改めて目を向け直すべき時機が来ていると感じています。その話のネタにもなればと思います。
対話のシーン・内容例
プロダクトチーム内での対話
自分たちの活動と図内の活動マッピングしつつ、チームとしてのエネルギー分配のバランスについて対話する。
「どこを信頼して任せ合うか」「どこを一緒に活動するのか」を対話する
プロダクトマネージャー × 上長/メンター 間の対話
プロダクト作りの全体像の共有認識・共通言語を作り、視野を広げる対話を行う
「できるようになりたい（なってもらいたい）範囲」「集中したい（してもらいたい）範囲」「染み出したい（してほしい）範囲」の希望と期待を対話する
プロダクト作りに関わる職種間での対話
プロダクトの成功のためのボトルネックに関する対話
「どこを信頼して任せ合うか」「どこを染み出し合って活動するのか」「どこの境界を無くしてしまうのか」を対話する
図の見方、留意点
大きな文字（「Product Discovery」「Product Strategy」など）が活動領域名を指し、その周辺に小さな文字（「Turn insight into strategy」「Grow talent」など）が、活動内容を指します。最初は、小さな文字は読まなくても結構です。プロダクトチーム（プロダクトマネージャー、エンジニア、デザイナーなどを含む機能横断チーム）がより直接的に関わる傾向が高いのが、色が付けられた（＝黒文字以外の）活動領域です。プロダクトリーダー（CEO/CPO/VPoP/シニアPM/CTO/事業責任者など）は図内の活動すべてに強く関わります。プロダクトチームも、黒文字で書かれる活動を深く理解し、自分たちの日々の活動との相互影響や貢献を強く意識する必要があります。
矢印は「影響を与える／受ける」ことを示しています（例： Product Discovery から得られたインサイトが Product Strategy に影響を与える）。もちろん、あらゆる活動の間で相互に影響がありますが、この図では主要なもののみ記載しています。
なお決して、「矢印間で作業者が分かれ、工程として渡される」という意味ではありません。どの活動を誰が担うか、そしてプロセスは文脈を勘案した設計が必要です。同時に過度な分担・分断の副作用は大きいため、それを避ける工夫も必要です。
また、これらの活動は「厳格な順序のある一方通行プロセス」という意味でもありません。それぞれの活動は並行的に行われることも多く、かつ常にフィードバックしあって、行き来されます。
図内の活動の概要
下部の4つの活動（Product Discovery, Product Definition, Product Delivery, Product Evaluation）のループは、プロダクトマネージャーを含むプロダクトチームが日々従事する、基本となる活動群です。
作るべき、価値・事業実現性のあるアイデア（解くべき問題とその解決策）を探索・発見し（Product Discovery）、作るための定義を行い（Product Definition）、価値を提供できる形とし、顧客やユーザーに展開する準備を整えます（Product Delivery）。リリース物を Product Go-to-Market の活動と連携しながら市場にローンチし、プロダクトの定着を促進することで利益を生み出します。そして、市場から得られた情報を評価して学びを得て、その後の活動に生かします（Product Evaluation）。
あなたがもしビギナープロダクトマネージャーなのであれば、まずはごく小さな案件でも良いので、この4つの活動を一気通貫で経験し、各活動の精通に集中すると良いでしょう。
そして、その一連の活動は、主にプロダクトリーダー（CEO/CPO/VPoP/シニアPM/CTO/事業責任者など）が主導して策定する Product Strategy と Business Strategy から大きな影響を受けます。
別の言い方をすると、Strategy が「勝ち筋」として、他の活動に明快な方針を与えます。と同時に、それらの Strategy も先述の4つの活動、そして Product Go-to-Market 活動から得られたインサイトを重要なインプットとします。なお、Product Strategy と Business Strategy は互いに呼応しながら、一体に近いものとして更新されます。
そして、Product Strategy は Product Vision 、つまり「そのプロダクトを通じて作り出す世界」の実現を担っています。別の言い方をすると、良い Product Vision は大胆な Product Strategy を導き出します。
プロダクトリーダーでなくとも、プロダクトチームは最低限この領域を能動的に理解する必要があります。プロダクトマネージャーであれば、ミドルやシニアになるにつれて、策定にも関わることとなるでしょう。
図内の活動のさらなる説明
Product Discovery のループ
Product Discoveryは、解くべき問題とその解決案を探索・発見する活動であり、多くの活動の起点となる重要な活動です。市場・ドメイン・顧客・ユーザー・データ、そしてそれらに付随する背景情報を深く理解し、大量の一次情報に触れて、インサイトや仮説を導き出します（要望チケットに書かれていることを鵜呑みにして作るものを決定するのは Product Discovery ではありません）。顧客やユーザーにとって価値があり、事業として十分な規模の市場と需要があり、戦略に合致し、技術的にも実現可能なアイデアの仮説を探索・発見するのです。
また、相対的に時間とコストのかかる4つの活動の大きなループを回すことなく、この Product Discovery のループのみを最低限のリードタイムで回すことに執着し、価値や需要の仮説を可能な限り早期に検証／反証し、「成功確率の高い、作るべきもの」を見つけ出します。
Product Discoveryには、Product Strategy（や Business Strategy）の種となるような「解くべき大きな問題」を求めて広範に探索する Product Discovery と、戦略で規定された範囲における、「解くべき問題とその解決策」を特定する（＝Product Definition へと繋がる）、限定的な Product Discovery の両方が存在します。これら両方を、組織的に意図を持って行うことが重要です。前者は長ければ3ヶ月程度かけることもある一方で、後者は数日から数週間であることが多いでしょう。
Product Discovery は、特定の目的（新規事業発見、戦略策定、ソリューション決定など）に対して一時的かつ集中的に行うことが基本である一方で、一時的な活動のみに留まらずプロダクトリーダーや、プロダクトマネージャーを筆頭に、プロダクトチームが絶え間なく行う活動でもあります。プロダクトマネージャーは最低でも週に一回は一次情報に触れているべきでしょう。累積的なインサイトを持つ人材やチームから、イノベーティブな戦略やアイデアが生まれるのです。
また、Product Strategy、Product Vision の策定に迷った際にも、この Product Discovery 活動に立ち返り、仮説を立てながら一次情報に触れ直すことで、目の前がひらける経験をしたことがある人は多いことでしょう。
※Product Discovery のプラクティス、フレームワークやキーワード：
ユーザー/顧客インタビュー（探索型、検証型）、フィールドワーク（ユーザー観察、ビジネスエスノグラフィ調査、Contextual Inquiry、丁稚奉公）、エキスパートインタビュー、Jobs-to-Be-Done、Double Diamond、仮説リスト、仮説マップ、Value Proposition Canvas、Lean Canvas、Opportunity-Solution Tree、Opportunity Backlog、狩野モデル、ペルソナ、共感マップ、業務フロー図、Customer Journey Map、Experience Map、User Story Map、Storyboard、プレトタイプ、プロトタイプ（ラピッド、ハイファイ）、コンシェルジュ型MVP、オズの魔法使い型MVP、スモークテスト、ゲリラテスト
Product Definition と Product Delivery のループ
Product Discovery で「成功確率の高い、作るべきもの」が見つかれば、本格的に市場に出すことを目指して、Product Definition で詳細化します。いつの間にか関係者の脳みそから離れてしまいがちな「誰がどんな状態になると成功なのか」 を改めて明文化し、「対象者が、価値を享受して成功している状態」をストーリーとして表現し、そのソリューションが生み出す成功を測る指標を立て、要求・要件（機能要件、非機能要件）、UIやアーキテクチャを定義します。
また同時に、複数の「作るべきもの」に対して優先順位づけをつけ、プロダクトバックログやロードマップ、リリース計画などの形で描きます。それがチームにとっての短期のマイルストーン、短期のゴール設定となり、良いリズムが生まれます。また社内ステークホルダーと対話するためのツールにもなります。
率直いうと、この Product Definition 領域は顧客・ユーザーからすると付加価値の少ない領域であり、この領域の仕事量が、それによって得られる効果に対して過剰となっていないか（関連する活動の効率性や品質、将来の自分たちの生産性に対する適切な投資となっているかなど）に常に注意を払うべきです。
※Product Definition のプラクティス、フレームワークやキーワード：
PRD、MRD、プレスリリース＆FAQ（PR/FAQ）、プロダクトバックログ、短期〜中期の機能ロードマップ、リリース計画、User Story Map、ユーザーストーリー、JTBDステートメント、ワイヤーフレーム、モックアップ、情報設計、機能要件・非機能要件、データフロー、イベントストーミング、顧客・ユーザーヒアリング、顧客・ユーザーテスト
Product Delivery は実際に「価値を提供可能な形にする」活動です。設計、コーディング、テスト、デプロイをなるべく短いリードタイムで回します。1日に何度もデプロイされ、フィーチャートグルなどの仕組みでデプロイとリリースは分けて管理されている状態が望ましいでしょう。
また、次の Product Evaluation で根拠ある判断を下すためには、各機能を計測可能にしておくことが必須です。プロダクトとしての可観測性もまた、顧客・ユーザーに損失を与える障害の防止と原因究明のスピードを高めます。
なお、Product DefinitionとProduct Deliveryのループは過度に工程分断されることなく、日々（なんなら分単位・時間単位で）プロダクトチーム内で行き来しながら行われます。
また、このループにおいても、ものを作るだけの活動に閉じこもってしまうのではなく、可能な限り早く市場・顧客・ユーザーからフィードバックが得て、価値のないものを作り込んでしまわない工夫が必要です（最小のスコーピング、早めの顧客・ユーザーテストなど）。
Product Evaluation
リリースした後はProduct Evaluationで明確な「市場からの学び」へと変換します。各指標はダッシュボードなどで視覚化し、また分析可能な状態としておきます。リリース結果は定量データ（プロダクト指標、ビジネス指標）と定性情報（顧客・ユーザーの声・状況など）の両面で分析し、あらかじめ決めていた成功指標の定義を中心に評価します。得られた学びはチーム内や他チーム、ステークホルダーにも共有しつつ、組織内で一元管理されます。そして、その学びは継続実施されているProduct Discoveryのループに流し込まれます。
Product Strategy、Business Strategyの対
並列的に双方向矢印が描かれているように、Product Strategy と Business Strategy は互いに呼応しながらアップデートされます。"プロダクト"チーム、"プロダクト"マネージャー、"プロダクト"リーダーだからと言って、Business Strategy に関わらなくて良いわけはありません。特に、経営に近い役割へと進むに従って、企業戦略や企業価値向上を踏まえた Product Strategy の立案が必要となります。
両者は「事業価値視点での勝ち筋」と「顧客価値視点での勝ち筋」の対応関係ではありますが、その策定のための活動は明確に分かれることなくオーバーラップする部分が多いでしょう。例えば、Business Strategy の周辺に配置している、Self-assess core competencies（強みや優位性の自己認知）、Analyze competitive landscape（競合環境の把握）、Identify opportunities and threats（機会と脅威の特定）、Evaluate the market（市場の評価）などはプロダクト視点でも熟考するでしょう。
Product Strategy
Product Strategy では、長期のProduct Vision（〜5年）を見据えつつ、特に中期（3ヶ月〜1年程度）の指針が明確に示されます。その戦略は企業戦略と整合している必要があります。
中期的に集中する領域と、その顧客の成功状態を物語として描き、その成果指標が設定されます。また中期〜長期の各時期（半年後/1年後/2年後など）のプロダクトポートフォリオがどのようになると価値が最大化されるのかを常に想定しておきます。そしてその実現のために、既存の良いプロダクトチームの力が最大限発揮され続け、なおかつ理想の投資ポートフォリオを実現できる組織と文化を築きます。
ただし、プロダクト最初期や、ピボット検討期のように集中的に大きな可能性を探索する時期においては、得られた学びに応じて Product Strategy が週次レベルで見直されることもあるでしょう。
重要な点として、Product Strategyは決して机上だけで作り出すものではなく、Product DiscoveryやProduct Evaluation、Product Go-to-Market から得たインサイトをもとにして産み出すものです。
そしてあらゆる活動を超えて最も重要な戦略的取り組みは、人とチームの成長を促進することです。
※Product Strategy のプラクティス、フレームワークやキーワード：
中期〜長期のプロダクトポートフォリオ計画、中期〜長期のProduct Strategyロードマップ 、STP、TAM-SAM-SOM、JTBD-Based Segmentation、OKR、競合マップ、SWOT/クロスSWOT、5フォース分析、コンピテンシーマトリクス、3 Horizons、プレスリリース＆FAQ、シナリオプランニング、One Metric That Matters
Product Vision
Product Vision は長期（〜5 年）の時間軸を見据え「どのような世界を作り出すのか」を示す、プロダクト作りにおける最も重要な要素の一つです。組織内外の人々を惹きつける要素でもあります。また、ビジョンは意思決定の役に立つ必要もあります。良い Product Strategy が描けないとしたら、それは Product Vision に問題があるサインかもしれません。
Problem Founder Fit している場合は、最初期からファウンダーに内在しているものを起点に描かれることが多いでしょう。そのようにビジョンが初期から強固な場合もあれば、初期においては安定せず、明確でもないケースもあります（社内に二本目の柱となるプロダクトを作る場合などに起こりやすいでしょう）。その場合は、今すぐそれらしいビジョンを無理に描くよりは、プロダクトリーダーが徹底的に一次情報に触れ直し、インスピレーションを得る時間を増やした方が良いでしょう。また、初期には強固であったビジョンも、プロダクトの成長や環境の変化に伴ってアップデートが必要なこともあります。
Product Vision は、簡潔な1〜2行のステートメント文だけではなく、未来の世界を情景・情緒・群像豊かなストーリー形式で描き出し、その実現のために解くべき、本質的で大きな課題も明確に示すべきです。ビジョン実現のためのその時点で考えうるマイルストーンを描き、ビジョンが夢物語ではないことも示します。また、「Vision の実現状況を示すといえる指標」 を設定しておくと、チームの北極星となり、日々の活動においても、長期の方向性を見失わないですむでしょう。
また、プロダクトによっては、プロダクト原則（例：Chromium の Core Principles）を設定することで、そのプロダクトの軸とすべきコンセプトが明確になり、戦略レベル〜機能仕様レベルまでの広範な意思決定に役立ちます。
※Product Vision のプラクティス、フレームワークやキーワード：
ビジョンステートメント、エレベーターピッチ、ビジョン小説、コンセプトムービー、North Star Metric、プロダクト原則、ワンページャー、バックキャスティング、フューチャースペクティブ、フライホイール、ビジョンタイプ
Product Go-to-Market
プロダクトをリリースしただけで、顧客やユーザーに価値が届くわけではありません。需要を創出し、マーケティングや営業部隊、チャネル、パートナーをイネーブルメントし、顧客・ユーザーの成功を支援することで価値が現実のものとなります。そして、プロダクトが市場に定着することで、収益が増加します。Go-to-Marketチーム（マーケティングや営業、カスタマーサクセスなど）とプロダクトチームは緊密に連携し、市場への展開（リリースやローンチ）を計画・管理する必要があります。決してプロダクトチームのエゴだけでリリースやローンチが行われてはなりません。
またGo-to-Marketチームは、既存顧客・ユーザーや見込み顧客・ユーザーに日々接しており、市場の動向や顧客・ユーザーの声を広範かつ具体的に集めている強力な部隊であり、それらへの造詣が深いでしょう。Product Discovery の起点となる情報を、市場の代弁者である Go-to-Market チームから得たり、共に Product Discovery を進めることも多くあります。その意味でも、Go-to-Market チームとプロダクトチームの信頼関係、緊密さは重要です。
対話の種としての問い
対話の際には、ぜひ以下の問いを活用してみてください。
重要な順に並んでいるわけではありませんので、チームで気になるものをいくつか選んで対話してみてください。
そして「すべては成果（顧客・ユーザーの成功、ビジネスの成功、ビジョンの実現、チーム・人の幸福）のため」です。これらの問いにうまく答えられることが「成果」ではありません。あくまでもさらなる成果を志向した時に、その成功確率を上げるためのヒントを得るために利用してください。決して手段と目的がすり替わらないように注意してください。
全体
プロダクト戦略、プロダクトポートフォリオ全体には誰が結果責任を持っている？持つなら誰が適任？
各プロダクトの成功に結果責任を持つのは誰？持つなら誰が適任？
プロダクトチームは機能横断的で、プロダクトの成功のために日次レベルで協働している？協業度を上げることで得られるものは？
プロダクトチーム内で協力し合って（活動によっては、プロとして背中を預け合って）、Discovery、Definition、Delivery、Evaluation全体に取り組めている？それぞれが今よりも役割を染み出すためには何ができる？
プロダクトマネージャーを含むプロダクトチームは、ビジネス戦略、Go-to-Marketも理解し、それらへの寄与に積極的？今よりも理解するためには誰から話を聞くのが良い？
プロダクトマネージャーを含むプロダクトチームは、ビジネスチーム（事業責任者やBizDev）やGo-to-Marketチーム（営業やCS）に染み出し、緊密に連携できている？良い連携のために、相手の仕事上の目標や信念を理解している？
それぞれの活動は並行的、かつ常にフィードバックし、必要に応じて行き来している？価値を生むまでのリードタイムを今よりも短くするために、どのボトルネックにアプローチできる？
Product Vision周辺
プロダクトビジョンは存在する？今でもそのビジョンは機能している？
これから作る（作り直す）なら誰がたたき台を作れそう？これまでのプロダクトの歴史の中で、最も想いを持っていた人は誰？その人から話は聞ける？
自分たちが「解くべきコアな問題」は「誰」の、「何」？
自分たちのプロダクトが将来創り上げる世界を、情景・情緒・群像豊かなストーリーとして表すならどんなものになる？1年後/3年後/5年後の途中段階の世界はどんなもの？
そのストーリーで登場する自社プロダクトを、今プロトタイピングしてみることはできない？
どんなビジョンを設定すれば良いかさっぱり思い浮かばない場合は、どんな一次情報に触れることでインスピレーションが得られそう？
ビジョンが意思決定に役立ったのはいつ？過去の難しい意思決定について、どんなビジョンであれば役にたった？
ビジョンはプロダクト組織内の誰もが語れる？プロダクト組織外にも知られている？社内のあの人に響いてもらうためには何が足りない？
Product Strategy 周辺
プロダクト戦略は存在する？日々の意思決定の役に立っている？
プロダクト戦略は机上だけで検討・決定していない？戦略を導くためのディスカバリーで、触れるべき一次情報は？
戦略立案のためにビジネス戦略・経営戦略を深く理解できている？その戦略は競争優位性を高め、企業価値を向上させる？誰と話せばそこへの理解が深まり、議論が深まる？
この3-6か月で「集中すべきテーマ」、「勝ち筋／勝つための方法」を一言で言うと？「やらないこと」は？戦略項目に厳密な優先順位をつけるならどういう順番になる？そのうちのTOP3に絞った場合の機会損失は？その損失は許容不可能？
戦略を作る・見直すために丸1日、考える時間を確保するとしたら、いつなら確保できる？何月何日？どのミーティング・仕事をリスケすれば時間が空けられる？
1年後/3年後/5年後のプロダクトの機能群はどのような構成になっている？限られた資源の中で、ギャップを埋めていくために、最も注力すべきことは？
競合は類似する戦略を立てられる？類似する戦略をとってきた場合、差別化要因となる自社・自プロダクトの強みや能力は？
見立てていた戦略が外れた場合、ピボットする条件は何？
許容不可能なリスクは何？許容可能なリスクは何？
デモグラフィック（人口統計的属性）/ファーモグラフィック（企業統計的属性）でセグメンテーションするとどのようなセグメントがありうる？ジョブ（JTBD）ベースでセグメンテーションするとどのようなセグメントがありうる？
プロダクトの成功を表す先行指標は？今の戦略に沿う最も重要な先行指標を一つに絞るならどれ？追っている遅行指標は？追っている指標は虚栄指標となってしまっていないか？その指標を過度に追い求めることで行動が歪むことはなさそう？
1年後/3年後/5年後の組織はどのようになっている？今のままのタレント/チームへの投資を続ければ、それぞれのフェーズで「良いリーダー」「良いチーム」は十分な人数育っていそう？
ビジネス、プロダクト、人すべてににとって良い文化とはどんなもの？
プロダクト戦略とビジネス戦略は相互にフィードバックしあえている？相互にフィードバックし合う上で、双方が理解しておくべき相反する利害はある？利害を超えて一致する共通のゴールは何？
Product Discovery周辺
戦略策定のためのディスカバリーと、プロダクト定義（≒ソリューション定義）のためのディスカバリーの両方を組織的に実行できている？
ディスカバリーに割いている時間が十分でないとしたら、一時的にでも止めたり、誰かに任せられる仕事やミーティングはない？（「あなたがディスカバリーに時間が割けるように、その仕事は私が手伝いますよ！」がチーム内で起きると良いですね）
解くべき問題の発見のために、二次情報（営業・CSチームからの伝言、顧客からの機能要望など）だけでなく、一次情報（顧客・ユーザー自身、顧客・ユーザーの実務・現場、顧客・ユーザーの上司・担当役員、購買決定者、競合、ドメインエキスパート、オピニオンリーダーなど）に継続的に触れられている？
今社内で最も一次情報を持っているのは誰？その人をどのように巻き込むとよさそう？
数ある課題や仮説は整理され、管理されている？
どうすればプロダクトションコードを書くことなく、その「課題の存在」、「ソリューションの価値」、そしてその「需要」を証明できる？
Product Definition周辺
社内で「プロダクトディスカバリー」と呼んでいる仕事が、この「プロダクト定義」の仕事（要求や仕様の定義）にとどまってしまっていないか？探索に染み出すためには、誰に巻き込んでもらえば良い？巻き込んでもらうための信頼を得るためには何ができる？
その機能は「誰」が「どんな状態」になると成功？「誰」を実名で挙げるとすると誰？
「リリースされ、市場・顧客・ユーザーに受け入れられた時の理想のストーリー」はどんなもの？
作るべきものに厳密な優先順位をつける（優先順に、重複のない連番をつける）とどうなる？
バックログアイテムごとの成功指標は何？今の戦略上の重要指標とどのように関連している？
戦略やディスカバリーを担うべき人がこのプロダクト定義にばかり時間が取られてしまっていないか？この平均的な1週間の仕事の配分を円グラフで表すとどうなる？仕事のシェアするために頼るべき・助けを求めるべきは誰？
Product Delivery周辺
デリバリーのリードタイムを短くするための改善アイデアは？劇的に短くするための改革アイデアは？
戦略やディスカバリーを担うべき人がデリバリーマネジメント（プロジェクトマネジメント）に時間を取られすぎていないか？
自動テスト、CI/CDなどの環境は整っている？システムの可観測性は高い？機能の利用状況は計測可能？
フィーチャートグルなど、Go-to-Marketを勘案したリリースを実現するための仕組みが存在する？
Product Evaluation周辺
プロダクトの利用状況は視覚化し、常に閲覧可能とするためには、誰の助けを借りられる？
デリバリーした機能は定量・定性の両面で評価されている？定義した成功指標の達成状況はチェックされている？確実にそれを実行するための仕掛け、仕組みは？
デリバリー単位だけでなく、プロダクト全体とビジネスの重要指標は定期的にチェックされている？誰がそれを主導できる？
見るべき指標が多すぎない？TOP3の指標に絞った時に失う機会損失は？本当にそれは許容不可能？
見落としている重要指標はない？今の重要指標と戦略・ビジョンとの関連を説明するとしたらどういうものになる？
先行指標、一致指標、遅行指標は意図して区別されている？
ローンチによって市場から得られた学びはディスカバリーや、戦略に活かされている？この四半期の数ある評価から得られた学びを、次の戦略に生かすとするとどのような戦略アイデアがある？
よくあるご質問
Q. プロダクトマネジメントのループを「Product Delivery」「Product Discovery」の二つとしている図を世の中でよく見ますが、なぜこの図には「Product Definition」「Product Evaluation」があるのですか？
以下のような課題を多く見聞きするので、あえて細分化することで別個に重要な活動であることを明確化しようと試みています。
社内で「ディスカバリー」と呼ばれている仕事が、価値や機会の「探索」ではなく、要求の「定義（Definition）」に過ぎない
プロダクトデリバリー後に、プロダクトの評価（Evaluation）を行なっていない
「細分化することで過剰な分断を促すのでは」と迷いましたが、現時点ではこのようにしています。
Q. Business Strategy は Product Strategy （や Product Vision）の上位に位置すると思うのですが。
おっしゃる通り、実際には Business Strategy が並列ではなく上位に来るケースが多いですが、ここではプロダクトマネージャー、プロダクトチームがビジネス戦略の水準を引き上げるような影響力を発揮していたり、プロダクトリーダー、プロダクトマネージャーがプロダクトとビジネスの境界を溶かしていたり、Product Vision から生まれたアイデアが強烈なビジネスを作り出す世の中の事例を反映する形で、並列に配置しています。
Q. 各アクティビティについて、より具体的で詳細なアクティビティや成果物を知りたいです。
なかなかそこにまで踏み込めておらずすみません。一旦本記事内の各種キーワードからヒントを得ていただければとおもいます（AIに聞いたり、検索したり）。より具体的で詳細な活動や成果物例については、要望があれば、随時の提供を検討しています。
Q. 社内で再配布などして構いませんか？
むしろぜひです！ライセンスは CC BY-SA です。
フィードバック先
長い長い文章、ここまでお読みくださりありがとうございます。フィードバックがありましたら、ぜひ X: @ykmc09 宛にください。
謝辞
この図は、クライアントの方々に提供し、その提供過程で日々ブラッシュアップを行いました。いつも良いディスカッションをさせていただいているクライアントの皆様に感謝します。
このnote公開前に以下の方々にフィードバックをいただきました（50音順）。皆さんからの多様で建設的なフィードバックから、改めて多くの学びをえて、改善に活かすことができました。反映しきれなかったフィードバックも多々あったのですが、今後の改善や追加の発信の参考にさせてもらいます。本当にありがとうございました。