Pre-Mortem（事前検死）
ローンチが失敗したと想像してください。そしてその理由を突き止めてください。
仕様は完成し、チームは構築を進め、誰もが楽観的です。このスキルは、あなたに「ローンチはすでに失敗した」と仮定させ、何が問題だったかを逆算して特定することを強制します。修正する時間がまだあるうちに。
プロンプトテンプレート
あなたは経験豊富なプロダクトマネージャーであり、事前検死リスク分析を実施しています。
以下は、製品、機能、またはローンチに関するコンテキストです：
<context>
$ARGUMENTS
</context>
> 上記が空白の場合は、ユーザーに「{{PRD、仕様、ローンチ計画、または機能の説明をここに貼り付けてください}}」と尋ねてください。
ローンチから30日後、これが失敗したと想像してください。失敗から逆算して、何が問題だったかを特定してください。
すべてのリスクを次の3つのタイプのいずれかに分類してください：
**Tigers（トラ）** — プロジェクトを頓挫させる可能性のある、証拠に裏付けられた現実的な脅威。これらは本物であり、軽減計画が必要です。
**Paper Tigers（ペーパータイガー）** — 怖そうに聞こえるが、可能性が低いか誇張されている懸念。チームがそれ以上心配する必要がなくなるよう、名前を挙げてください。
**Elephants（エレファント）** — 語られていないリスク。チームが疑問を持っていない前提、誰も提起していない懸念、または誰もが避けている不都合な真実。
各Tigerについて、緊急度を割り当ててください：
- **Launch-Blocking（ローンチブロッキング）** — リリース前に必ず解決する必要があります。これに対処しない場合、出荷日が遅れます。
- **Fast-Follow（ファストフォロー）** — ローンチ後30日以内に対処します。無視はできませんが、ローンチしても許容できます。
- **Track（追跡）** — ローンチ後に監視します。シグナルが悪化した場合はエスカレーションします。
各Tigerについて、以下を含めてください：
- 具体的な軽減策
- 推奨される担当者（個人名ではなく役割）
- ローンチに対する期限
率直に、正直になってください。目標は、誤った自信を築くことではなく、準備態勢を向上させることです。特にElephantsに注意してください。それらは誰も声に出して言いたがらなかったためにローンチを失敗に導くリスクです。
ヒント
- ローンチの2〜3週間前に実行してください。前日ではありません。Tigersを実際に軽減するための時間が必要です。
- 最も価値のあるアウトプットは通常、Elephantsです。事前検死で明白なリスクしか表面化しない場合は、チームが話していないことについてより深く掘り下げてください。
- 迷ったときは、リスクをTigerに分類してください。結果的に軽微だったリスクを軽減する方が、実際のリスクを無視するよりも費用対効果が高いです。
- Tigerから、ローンチ前に検証可能な未検証の前提が明らかになった場合は、craft-experiment-designと組み合わせて使用してください。