derisk-measurement-advisor について
derisk-measurement-advisorは、プロダクトマネージャーが製品やAIのアイデアに伴う内外のリスクを評価し、優先順位付きリスク一覧を作る対話型スキルです。4つの内部リスクと6つのPESTEL要因を調べ、各リスクを即時対応か追跡に振り分けます。
主な機能
- 0110のリスク領域をスキャン
- 02製品・事業成果のリスク評価
- 03外部PESTEL要因の確認
- 04即時対応または追跡への分類
- 05優先順位付きリスク一覧の作成
活用シーン
- 01製品やAIのアイデアを進めるか判断
- 02ロードマップへの追加前にリスクを確認
- 03内部または外部リスク評価の不足を補完
- 04経営陣にリスクと対応優先度を説明
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ deanpeters/ product-manager-skills --skill derisk-measurement-advisorインストール後、Claude Code で/derisk-measurement-advisorを入力して読み込まれたか確認します。
詳細
目的
プロダクトマネージャーが、4つの内部リスクと6つの外部リスクからなる10のリスク次元を対象に、測定、テスト、追跡すべき最も重要な項目を特定し、それぞれをすぐに対処するか追跡を始めるかに振り分けられるよう支援します。成果物は、何が起こり得るかを示すだけでなく、何から取り組むべきかを伝える、優先順位付きのリスク登録簿です。
これは一般的なリスク一覧ではありません。あなたの具体的なプロダクト、顧客、市場の状況に沿って確認していくためのガイドです。この問いに答えます。苦労に見合うだけの価値はありますか?
入力
最適な入力: ストレステストしたいプロダクトやAIのアイデア。 あると役立つ情報: 段階(コンセプト、プロトタイプ、市場投入後)、すでに検証済みのこと、リスクが高いと把握している次元。
起動時に渡された内容(スキル名の後のテキスト、貼り付けられたコンテキスト、または追記されたARGUMENTS:行)は、すでに回答済みの情報として扱います。その情報を使い、該当する内容は再度質問しないでください。
何も用意していなくても大丈夫です。 アドバイザーがまず、アイデアを1〜2文で尋ね、その内容に照らして10のリスク次元を確認します。
起動例: De-risk this: an AI agent that auto-drafts insurance claim responses for adjusters — prototype stage, no compliance review yet.
重要な概念
2つの視点、1つの問い
すべてのプロダクトアイデアには、2種類のリスクが伴います。多くのPMは一方を確認し、もう一方を見落とします。
内部リスクでは、プロダクト自体が機能するかを確認します。
- プロダクト成果指標(望ましさ+使いやすさ)=「顧客/ユーザーにとって、どんな価値がありますか?」
- ビジネス成果指標(実現可能性+事業性)=「自社/組織にとって、どんな価値がありますか?」
外部リスクでは、周囲の環境が実現を阻む可能性がないかを確認します。
- PESTEL要因(政治、経済、社会、技術、環境、法律)=「どのような不意打ちが起こり得ますか?」
両方に共通する唯一のトリアージの問いは、**今すぐ対処するか、それとも追跡を始めるか?**です。
内部リスクフレームワーク(DUFV)
Marty Caganの4つのプロダクトリスクを応用し、2つの測定カテゴリに分けています。
| カテゴリ | 次元 | 中核となる問い |
|---|---|---|
| プロダクト成果指標 | 望ましさ | 顧客は、購入するだけの価値を感じますか? |
| プロダクト成果指標 | 使いやすさ | 顧客は使い方を理解できますか? |
| ビジネス成果指標 | 実現可能性 | 構築できますか?規模を拡大しても持続できますか? |
| ビジネス成果指標 | 事業性 | 持続可能なビジネスとして成り立ちますか? |
プロダクト成果指標が答えるのは、*「顧客/ユーザーにとって、どんな価値がありますか?」*です。プロダクトが重要な問題を解決し、想定するユーザーに価値を提供できているかを測定します。
ビジネス成果指標が答えるのは、*「自社/組織にとって、どんな価値がありますか?」*です。提供可能性を維持しながら、プロダクトがシームレスな顧客体験をどれだけ効果的かつ確実に支えられているかを測定します。
ポジショニングとのつながり:プロダクト成果指標は問題のポジショニングステートメント(顧客への約束)を検証します。ビジネス成果指標は問題のフレーミングステートメント(ビジネス上の根拠)を検証します。
外部リスクフレームワーク(PESTEL)
組織の外部にある、製品計画を再構築したり、遅らせたり、頓挫させたりする可能性のある6つの要因です。
| カテゴリ | 対象となるもの | リスクの例 |
|---|---|---|
| 政治 | 政府の政策、貿易規制、政治的優先事項 | 政府請負業者向けに新たなAI安全規則が導入される |
| 経済 | 市場状況、資金調達、格差、サプライチェーン | VCによるAIへの資金提供が枯渇し、収益性重視に方針が移る |
| 社会 | 人口統計、世論、デジタルリテラシー、文化的変化 | AIが偏見を助長すると非難され、公平性を証明できるか問われる |
| 技術 | プラットフォームへの依存、標準、競合技術 | 新しいAIモデルに自社モデルが追い越され、迅速なイノベーションが必要になる |
| 環境 | エネルギー消費、持続可能性、カーボンフットプリント | AIのカーボンフットプリントが批判され、環境負荷をどう減らすか問われる |
| 法務 | データプライバシー、コンプライアンス、知的財産、変化する規制 | AIディープフェイクをめぐる訴訟の渦中で、製品を保護できるか問われる |
教室で得られた重要な洞察: 市場の状況は変化するだけではありません。私たち自身や事業、製品を変える可能性もあります。PESTELは、PMがその変化をただ観察するのではなく、分類して対応するのに役立ちます。
対応/監視のトリアージ
明らかになったリスクには、次の2つのラベルのいずれかを付けます。
- 直ちに対応: リスクが現存し、重大で、今すぐ対応が必要です。テストを実施する、計画を変更する、ギャップを緩和するなどの対応を取ります。
- 追跡を開始: リスクは現実的ですが、まだ緊急ではありません。監視し、しきい値を設定し、一定の頻度で見直します。
このトリアージは、内部リスクと外部リスクのどちらにも同様に適用されます。答えを出せない望ましさのギャップは、規制の期限と同じく「今すぐ対応」です。今後起きると予想される人口動態の傾向は、すでに一部緩和した実現可能性の懸念と同じく「監視」です。
アンチパターン: すべてに「今すぐ対応」とラベルを付けることです。すべてのリスクが緊急なら、どれも優先されません。対応/監視をおよそ40対60に分けるようにしてください。
このスキルを使うタイミング
次の場合に使います:
- 製品やAIのアイデアがあり、取り組むべきか判断する必要がある
- 何かをロードマップに載せる前に、体系的にリスクを確認したい
- 内部リスクに集中していて、外部要因を確認していない(またはその逆)
- リーダーから「何がうまくいかない可能性があるか」と尋ねられ、「何もありません、問題ありません」より良い答えを出したい
次の場合は使わないでください:
- 具体的な製品アイデアがまだない(まず
problem-framing-canvasを使ってください) - データや出典を含む詳細なPESTEL分析が必要(コンポーネントスキルの
pestel-analysisを使ってください) - すでにアイデアを検証済みで、検証方法を選ぶ必要がある(
pol-probe-advisorを使ってください) - アイデアがすでに本番稼働していて、リスク低減ではなく最適化を行っている
ファシリテーションの基準
このスキルでは、標準の対話プロトコルとして workshop-facilitation を使用してください。
以下を定義しています:
- セッション開始前の案内と参加モード(ガイド付き、コンテキストの共有、最善の推測)
- 平易な表現のプロンプトを使った、1ターンにつき1つの質問
- 進捗ラベル(例:Context Qx/4、Risk Scan Qx/6)
- 中断への対応と一時停止/再開の動作
- 判断が必要な場面での番号付き推奨事項
- 通常の質問に対する番号付き選択肢(役立つ場合は
Other (specify)を含める)
このファイルでは、分野固有の評価内容を定義しています。競合する内容がある場合は、このファイルの分野別のロジックに従ってください。
適用
このインタラクティブスキルでは、適応型の質問を用いて、製品アイデアを10のリスク次元(内部4つ+外部6つ)にわたって確認し、明らかになった各リスクを対応/監視にトリアージして、優先順位付きリスクリストを作成します。
セッション開始:事前説明と進行モード(必須)
エージェントの開始時のプロンプト:
「始める前に簡単に説明します。通常、所要時間は約15~20分です。まず4つのコンテキストに関する質問を行い、次に10のリスク領域を確認します。内的リスクが4つ(顧客が求めるか、顧客が使えるか、構築できるか、ビジネスとして成り立つか)、外的リスクが6つ(政治、経済、社会、技術、環境、法律)です。明らかになったリスクは、それぞれ優先度を判定します。今すぐ対処するか、継続的に追跡するかを決めます。
どのように進めますか?
- ガイドモード: 各領域を1つずつ確認します。
- コンテキストの一括共有: アイデアについて分かっていることを貼り付けてください。すでに説明されている内容は省略します。
- 最善の推測モード: アイデアを1文で教えてください。妥当な前提を置き、前提であることを明記します。」
ステップ0:コンテキストの収集
エージェントは次の質問を1ターンに1つずつ尋ねます。
コンテキストに関する質問1/4:「評価対象のプロダクトまたはAIのアイデアは何ですか?何をするもので、誰を対象としているのか、1~2文で説明してください。」
コンテキストに関する質問2/4:「このアイデアは現在どの段階にありますか?」
- コンセプト — 取り組むかどうかを検討している段階です
- プロトタイプ — テスト可能なものはありますが、取り組むことはまだ確定していません
- 開発中 — 取り組むことを決定し、開発を進めています
- 拡大中 — リリース済みで、成長させている段階です
コンテキストに関する質問3/4:「現時点で最も懸念していることは何ですか?」
- 実際にこれを求める人はいるでしょうか?(需要/望ましさのリスク)
- ユーザーは使い方を理解できるでしょうか?(使いやすさのリスク)
- 実際に構築し、維持できるでしょうか?(技術/実現可能性のリスク)
- ビジネスとして成り立つでしょうか?(事業性/ビジネスモデルのリスク)
- 外部の何かによって計画が妨げられる可能性があります(規制、市場、競争)
コンテキストに関する質問4/4:「顧客は誰ですか?このプロダクトを使ったり購入したりする人を指します。会社名ではなく、職種や役割を教えてください。」
質問4の後、エージェントが要約します:
「以下の内容をもとに進めます。
- アイデア:[要約]
- 段階:[段階]
- 主な懸念:[懸念]
- 顧客:[役割]
リスクを確認しましょう。まず内的リスク(プロダクト成果指標とビジネス成果指標)から始め、次に外的要因(PESTEL)を確認します。」
ステップ1:内的リスクの確認 — プロダクト成果指標(望ましさ+使いやすさ)
エージェントの導入:
「まず、プロダクト成果指標を確認しましょう。顧客にとってどんな価値があるのでしょうか?これらの指標は、プロダクトが顧客にとって価値があり、使いやすいものになるかを測定します。2つの領域について、テストと指標を提示します。それぞれについて、あなたのプロダクトにとって最も重要なものを2つ選んでください。」
リスク確認の質問1/10 — 望ましさ:「[顧客の役割]が[プロダクトのアイデア]を実際に求めるかを検証するうえで、最も重要なテストや指標はどれですか?2つ選んでください。」
- ランディングページを使って初期の関心度を測る
- 解説動画や広告への反応をテストする
- 広告キャンペーンからの登録率を分析する
- ストーリーボードのデモに対するフィードバックを観察する
- ユーザーとのやり取り中のセッション時間を測定する
- 時間の経過に伴う機能の利用率を追跡する
- その他(独自の案を説明してください)
各選択に対して、エージェントが尋ねます:「これは今すぐ対処(テストを実施する、ギャップを埋める)する必要がありますか、それとも追跡を開始(時間をかけて監視する)しますか?」
リスク確認の質問2/10 — 使いやすさ:「[顧客の役割]が[プロダクトのアイデア]をストレスなく使えるかを検証するうえで、最も重要なものはどれですか?2つ選んでください。」
- ユーザーがワイヤーフレームをどのように操作するかを観察する
- 使いやすさに関する知見を得るためにウィザード・オブ・オズテストを行う
- 紙のモデルに対するフィードバックから、分かりにくい点を観察する
- フラストレーションの原因を特定するため、連打クリックを追跡する
- タスク完了ワークフローでの離脱を測定する
- 操作の妨げになる点を特定するため、タスクの完了時間を分析する
- その他(独自の案を説明してください)
各選択に対して、エージェントが尋ねます:「今すぐ対処しますか、それとも追跡を開始しますか?」
ステップ 2:内部リスクスキャン — ビジネス成果指標(実現可能性+事業性)
エージェントの導入:
「次はビジネス成果指標を確認しましょう。ビジネスにとってどんなメリットがあるでしょうか? これらは、ビジネスとテクノロジーがこの製品を支えられるかどうかを測定します。」
リスクスキャン Q3/10 — 実現可能性:「[product idea] を実際に構築し、維持できることを確認するうえで、次のうち最も重要なのはどれですか? 2つ選んでください。」
- システムの稼働時間と安定性を測定する
- ユーザー負荷をシミュレーションし、スケーラビリティを確認する
- テスト中のリソース使用量と効率を追跡する
- 環境全体の障害率を監視する
- 類似システムを参考にコストを評価する
- 重要な依存関係との統合準備状況をテストする
- その他(独自の項目を記入)
選択するたびにエージェントが質問:「すぐに対応しますか、それとも追跡を始めますか?」
リスクスキャン Q4/10 — 事業性:「[product idea] がビジネスとして成り立つことを確認するうえで、次のうち最も重要なのはどれですか? 2つ選んでください。」
- 類似製品の類似データを調べる
- 隣接する製品を分析し、比較可能な知見を得る
- シミュレーションモデルを使って損益分岐点を推定する
- 顧客調査を通じて価格感度をテストする
- 収益構造とコスト構造のスケーラビリティを評価する
- トレンド分析を行い、長期的な市場の可能性を評価する
- その他(独自の項目を記入)
選択するたびにエージェントが質問:「すぐに対応しますか、それとも追跡を始めますか?」
ステップ 3:外部リスクのスキャン — PESTEL
エージェントの導入:
「次に、外部要因をスキャンしましょう。組織の外部にあり、計画を一変させたり、遅らせたり、頓挫させたりする可能性のある要因です。6 つのカテゴリーを順に確認します。それぞれについて、製品や業界に関連するリスクを提案します。重要なものと、対処するか注視するかを教えてください。」
リスクスキャン Q5/10 — 政治:「[product idea] と [customer role] を踏まえると、どのような政治的要因が計画に影響する可能性がありますか?」
最初の質問候補(エージェントが状況に合わせて調整します):
- 規制遵守の要件(既存または審議中)
- 業界に影響する政治的優先事項の変化
- 地域ごとの政策要件や管轄区域の違い
- 輸出規制や貿易政策の変更
「これら(または他の要因)のうち、関連するものはどれですか?それぞれ、すぐに対処しますか、それとも追跡を始めますか?」
リスクスキャン Q6/10 — 経済:「[product idea] に影響する可能性のある経済的要因は何ですか?」
最初の質問候補:
- 顧客セグメントの予算に影響する経済格差
- 納期やコストに影響するサプライチェーンの混乱
- 資金調達環境の変化(VC、企業予算)
- 採用市場における人材不足
「関連するものはどれですか?対処しますか、それとも注視しますか?」
リスクスキャン Q7/10 — 社会:「[product idea] の導入に影響する可能性のある社会的・文化的な変化は何ですか?」
最初の質問候補:
- AI や製品カテゴリーに対する社会的な意識の変化
- ターゲット顧客層におけるデジタルリテラシーの格差
- ターゲット市場における人口動態の変化
- 顧客の働き方に影響する都市化やリモートワークの傾向
「関連するものはどれですか?対処しますか、それとも注視しますか?」
リスクスキャン Q8/10 — 技術:「[product idea] に影響する可能性のある技術の変化は何ですか?」
最初の質問候補:
- プラットフォームへの依存(API、クラウドプロバイダー、AI モデルプロバイダー)
- 製品が満たす必要のある業界標準の進化
- 現在のアプローチを飛び越える可能性のある競合技術
- 周波数割り当てやインフラの変更(該当する場合)
「関連するものはどれですか?対処しますか、それとも注視しますか?」
リスクスキャン Q9/10 — 環境:「[product idea] に影響する可能性のある環境要因は何ですか?」
最初の質問候補:
- エネルギー消費への懸念(特に AI やコンピューティングを多用する製品)
- 顧客や規制当局による持続可能性要件
- 一般の人々や投資家による二酸化炭素排出量への監視
- インフラや供給に影響する資源不足
「関連するものはどれですか?多くの製品ではこのカテゴリーの影響は小さいため、該当しない場合は『最小限』と答えて次に進みましょう。関連するものがあれば、対処しますか、それとも注視しますか?」
リスクスキャン Q10/10 — 法務:「[product idea] に影響する可能性のある法的リスクは何ですか?」
最初の質問候補:
- データプライバシー規制(GDPR、州のプライバシー法、業界固有の規則)
- AI 固有の責任や透明性に関する要件
- 知的財産の保護に関する課題(特許、営業秘密、オープンソースライセンス)
- 雇用または請負業者の分類に関する法律(製品が仕事に影響する場合)
「関連するものはどれですか?対処しますか、それとも注視しますか?」
ステップ 4:統合 — リスク登録簿
エージェントが選択内容をリスク登録簿にまとめます:
「[product idea] のリスク低減計画はこちらです。
すぐに対処
| # | 項目 | リスク/テスト | 推奨される最初のステップ |
|---|---|---|---|
| 1 | [例:望ましさ] | [例:ランディングページで初期関心を測定する] | [例:メールアドレスを収集する 1 週間のランディングページテストを開始する] |
| 2 | [例:法務] | [例:EU の顧客に対するデータプライバシー遵守] | [例:今週中に GDPR の要件をデータアーキテクチャに対応付ける] |
| ... |
追跡を開始
| # | 項目 | リスク/シグナル | 注視する対象 | 見直しの頻度 |
|---|---|---|---|---|
| 1 | [例:経済] | [例:AI 分野における VC 資金調達の縮小] | [例:四半期ごとの VC レポート、競合他社の資金調達状況] | 四半期ごと |
| 2 | [例:社会] | [例:医療分野における AI への意識の変化] | [例:業界調査、メディアの論調、顧客インタビュー] | 毎月 |
| ... |
概要
- 明らかになったリスクの合計: [N]
- すぐに対応: [N] — これらは、これ以上コミットする前に取るべき次のステップです
- 追跡を開始: [N] — これらのレビュー周期に合わせてカレンダーにリマインダーを設定します
- 最大のギャップ: [今すぐ対応が必要な未解決項目が最も多い領域]」
エージェントは次に、以下を提案します:
「次に何をしますか?
- 今すぐ対応する項目を深掘りする — 具体的なテストや測定方法の設計をお手伝いします
- PESTEL 分析を一通り実施する —
pestel-analysisスキルを使って、外部要因を詳しく調査します - 検証方法を選ぶ —
pol-probe-advisorを使って、最も大きなリスクを検証する最も低コストなテストを選びます - このリスク一覧をエクスポートする — チームで共有できる Markdown ドキュメントに整形します」
例
例:AI を活用した臨床試験マッチングツール
コンテキスト:
- アイデア: EHR データに基づいて患者と臨床試験をマッチングする AI ツール
- 段階: コンセプト
- 主な懸念事項: 外部規制リスク
- 顧客: 臨床業務責任者
内部リスクスキャンの結果:
製品成果指標:
- 望ましさ:ストーリーボードのデモからフィードバックを観察する(対応)+機能の採用率を追跡する(監視)
- 使いやすさ:タスク完了ワークフローの離脱率を測定する(監視)+摩擦が生じる箇所を把握するために完了までの時間を分析する(監視)
ビジネス成果指標:
- 実現可能性:EHR との依存関係について統合準備状況をテストする(対応)+環境ごとの失敗率を監視する(監視)
- 事業性:類似製品のデータを調査する(対応)+収益とコストの拡張性を評価する(監視)
外部リスクスキャンの結果:
- 政治:FDA のデジタルヘルスに関するガイダンスが変化している(監視 — 四半期ごと)
- 経済:パンデミック後の病院 IT 予算への圧力(対応 — 今すぐ支払い意思を検証する)
- 社会:AI 主導の患者マッチングに対する臨床医の信頼(対応 — 信頼性に関するインタビューを実施する)
- 技術:EHR プラットフォームの API の安定性とアクセス方針(対応 — 今回のスプリントで統合をテストする)
- 環境:影響は最小限
- 法務:PHI の AI 処理に関する HIPAA コンプライアンス(対応 — プロトタイプの前に法務レビューを実施する)
リスク一覧の出力:
すぐに対応(5 項目):
- 望ましさ — 臨床業務責任者 5 名を対象にストーリーボードのデモを実施する
- 実現可能性 — EHR 統合の技術検証(API アクセスとデータ形式をテストする)
- 事業性 — 類似製品のベンチマーク調査(類似ツールの料金を調べる)
- 経済 — 病院 IT 購入担当者 3 名に予算の決裁権限を確認する
- 法務 — PHI の AI 処理に関する HIPAA コンプライアンスレビュー
追跡を開始(5 項目):
- 望ましさ — 機能の採用率(リリース後の指標)
- 使いやすさ — タスク完了時の離脱率と完了までの時間(プロトタイプ完成後)
- 実現可能性 — 環境ごとの失敗率(構築後)
- 事業性 — 収益とコストの拡張性(パイロット後)
- 政治 — FDA のデジタルヘルスに関するガイダンス(四半期ごとのレビュー)
最大のギャップ: 法務/コンプライアンス — 実際の患者データをプロトタイプで扱う前に、HIPAA レビューを完了する必要があります。
よくある落とし穴
1. 汎用的なリスク一覧
失敗パターン: 「望ましさはリスクです。実現可能性はリスクです。規制はリスクです。」具体性がなく、実際の製品との関連もありません。
結果: どの製品にも当てはまるリスク一覧となり、どの製品にも役立ちません。
対策: すべてのリスクに、この製品とこの顧客に固有のテストまたはシグナルを明記する必要があります。「初期の関心を測る」は汎用的です。「EHR 統合を訴求するメッセージで、臨床業務責任者を対象としたランディングページを 1 週間運用する」は具体的です。
2. 対応ばかりで監視がない
失敗パターン: リスクを見ているとすべてが急を要するように感じられ、すべてのリスクに「すぐに対応」とラベルが付けられています。
結果: 優先順位が付けられません。チームは 15 個のリスクに同時に対処しようとして、どれも進展しません。
対策: 必ず振り分けてください。リスクが 10 個ある場合、「今すぐ対応」は 4~5 個以内にします。残りも現実のリスクですが、今日対処する問題ではありません。レビュー周期を設定して、次に進みましょう。
3. 内部のみまたは外部のみ
失敗モード: PM が徹底的な DUFV スキャンを実行するものの、PESTEL をまったく確認しない(またはその逆)。「需要と実現可能性を検証した — 出荷しよう!」。そして 6 か月後、規制によって製品が中止になる。
結果: まさにスキャンしなかった次元に盲点が生まれる。
修正: このスキルは、まさにこれを防ぐために存在します。毎回、両方のレンズを使います。外部カテゴリの影響が小さい場合(SaaS における Environmental でよくあること)、「最小限」と述べて先に進みます — ただし、問い自体を省略しないでください。
4. 次のステップのない分析
失敗モード: 美しいリスク登録簿があるが、推奨される最初のステップがない。Google Doc に置かれたまま。誰も行動しない。
結果: リスクシアター — 実質を伴わない、勤勉さの見せかけ。
修正: すべての「今すぐ行動」項目には、具体的な次のステップが必要です。誰が何を、いつまでに実行し、リスクが対処されたことをどうやって知るのか。「テストを実行する」は次のステップではありません。「[顧客役割] を対象にメールアドレス収集付きの 1 週間のランディングページを公開し、登録率を測定し、[日付] までに go/no-go を決定する」が次のステップです。
参考資料
関連スキル
- pestel-analysis(コンポーネント)— 6 つのカテゴリすべてにわたるデータ駆動型分析を含む PESTEL の詳細テンプレート。このスキルでさらに調査する価値のある外部リスクが明らかになった後に使用します
- pol-probe-advisor(インタラクティブ)— 最優先の「今すぐ行動」リスクに対して、最もコストの低い検証方法を選択します
- pol-probe(コンポーネント)— 特定のリスクに対する Proof of Life プローブを文書化します
- recommendation-canvas(コンポーネント)— リスク登録簿の調査結果を用いて go/no-go の推奨事項を構造化します
- problem-framing-canvas(インタラクティブ)— リスクをスキャンする前に問題をフレーミングします
外部フレームワーク
- Marty Cagan — Inspired(2018): 製品ディスカバリーの基盤としての 4 つの製品リスク(Value、Usability、Feasibility、Viability)
- Francis Joseph Aguilar — Scanning the Business Environment(1967): PEST 分析の起源であり、PESTEL に拡張されたもの
Dean の業績
- Productside AI Product Management コース、Unit 07:「De-Risking Your AI Bets — Unpacking Unknowns and Assumptions」
- PESTel Risk Planning アクティビティ(act/watch トリアージを用いた外部リスク)
- Measuring What Matters アクティビティ(DUFV 象限選択を用いた内部リスク)