Scenario War Room
Model cascading what-if scenarios across all business functions. Not single-assumption stress tests — compound adversity that shows how one problem creates the next.
Keywords
scenario planning, war room, what-if analysis, risk modeling, cascading effects, compound risk, adversity planning, contingency planning, stress test, crisis planning, multi-variable scenario, pre-mortem
Quick Start
CODEBLOCK0
Or describe the scenario:
CODEBLOCK1
What This Is Not
- - Not a single-assumption stress test (that's
/em:stress-test) - Not financial modeling only — every function gets modeled
- Not worst-case-only — models 3 severity levels
- Not paralysis by analysis — outputs concrete hedges and triggers
Framework: 6-Step Cascade Model
Step 1: Define Scenario Variables (max 3)
State each variable with:
- - What changes — specific, quantified if possible
- Probability — your best estimate
- Timeline — when it hits
CODEBLOCK2
Step 2: Domain Impact Mapping
For each variable, each relevant role models impact:
| Domain | Owner | Models |
|---|
| Cash & runway | CFO | Burn impact, runway change, bridge options |
| Revenue |
CRO | ARR gap, churn cascade risk, pipeline |
| Product | CPO | Roadmap impact, PMF risk |
| Engineering | CTO | Velocity impact, key person risk |
| People | CHRO | Attrition cascade, hiring freeze implications |
| Operations | COO | Capacity, OKR impact, process risk |
| Security | CISO | Compliance timeline risk |
| Market | CMO | CAC impact, competitive exposure |
Step 3: Cascade Effect Mapping
This is the core. Show how Variable A triggers consequences in domains that trigger Variable B's effects:
CODEBLOCK3
Name the cascade explicitly. Show where it can be interrupted.
Step 4: Severity Matrix
Model three scenarios:
| Scenario | Definition | Recovery |
|---|
| Base | One variable hits; others don't | Manageable with plan |
| Stress |
Two variables hit simultaneously | Requires significant response |
|
Severe | All variables hit; full cascade | Existential; requires board intervention |
For each severity level:
- - Runway impact
- ARR impact
- Headcount impact
- Timeline to unacceptable state (trigger point)
Step 5: Trigger Points (Early Warning Signals)
Define the measurable signal that tells you a scenario is unfolding before it's confirmed:
CODEBLOCK4
Step 6: Hedging Strategies
For each scenario: actions to take now (before the scenario materializes) that reduce impact if it does.
| Hedge | Cost | Impact | Owner | Deadline |
|---|
| Establish $500K credit line | $5K/year | Buys 3 months if churn hits | CFO | 60 days |
| 12-month retention bonus for 3 key engineers |
$90K | Locks team through fundraise | CHRO | 30 days |
| Diversify to <20% revenue concentration per customer | Sales effort | Reduces single-customer risk | CRO | 2 quarters |
| Compress fundraise timeline, start parallel process | CEO time | Closes before runways merge | CEO | Immediate |
Output Format
Every war room session produces:
CODEBLOCK5
Rules for Good War Room Sessions
Max 3 variables per scenario. More than 3 is noise — you can't meaningfully prepare for 5-variable collapse. Model the 3 that actually worry you.
Quantify or estimate. "Revenue drops" is not useful. "$420K ARR at risk over 60 days" is. Use ranges if uncertain.
Don't stop at first-order effects. The damage is always in the cascade, not the initial hit.
Model recovery, not just impact. Every scenario should have a "what we do" path.
Separate base case from sensitivity. Don't conflate "what probably happens" with "what could happen."
Don't over-model. 3-4 scenarios per planning cycle is the right number. More creates analysis paralysis.
Common Scenarios by Stage
Seed:
- - Co-founder leaves + product misses launch
- Funding runs out + bridge terms unfavorable
Series A:
- - Miss ARR target + fundraise delayed
- Key customer churns + competitor raises
Series B:
- - Market contraction + burn multiple spikes
- Lead investor wants pivot + team resists
Integration with C-Suite Roles
| Scenario Type | Primary Roles | Cascade To |
|---|
| Revenue miss | CRO, CFO | CMO (pipeline), COO (cuts), CHRO (layoffs) |
| Key person departure |
CHRO, COO | CTO (if eng), CRO (if sales) |
| Fundraise failure | CFO, CEO | COO (runway extension), CHRO (hiring freeze) |
| Security breach | CISO, CTO | CEO (comms), CFO (cost), CRO (customer impact) |
| Market shift | CEO, CPO | CMO (repositioning), CRO (new segments) |
| Competitor move | CMO, CRO | CPO (roadmap response), CEO (strategy) |
References
- -
references/scenario-planning.md — Shell methodology, pre-mortem, Monte Carlo, cascade frameworks - INLINECODE2 — CLI tool for structured scenario modeling
情景作战室
跨所有业务职能的模型级联假设情景。不是单一假设的压力测试——而是复合逆境,展示一个问题如何引发下一个问题。
关键词
情景规划,作战室,假设分析,风险建模,级联效应,复合风险,逆境规划,应急规划,压力测试,危机规划,多变量情景,事前验尸
快速开始
bash
python scripts/scenario_modeler.py # 带级联建模的交互式情景构建器
或描述情景:
/war-room 如果我们失去最大客户并且错过Q3融资会怎样?
/war-room 如果3名工程师离职并且我们需要在Q3前交付会怎样?
/war-room 如果我们的市场萎缩30%并且竞争对手融资5000万美元会怎样?
这不是什么
- - 不是单一假设的压力测试(那是/em:stress-test)
- 不是仅财务建模——每个职能都会被建模
- 不是仅最坏情况——建模3个严重级别
- 不是分析瘫痪——输出具体的对冲措施和触发点
框架:6步级联模型
第1步:定义情景变量(最多3个)
每个变量需说明:
- - 变化内容——具体、尽可能量化
- 概率——你的最佳估计
- 时间线——何时发生
变量A:最大客户(占ARR 28%)发出60天终止通知
概率:15% | 时间线:90天内
变量B:A轮融资比目标完成时间延迟6个月
概率:25% | 时间线:Q3
变量C:首席工程师辞职
概率:20% | 时间线:未知
第2步:领域影响映射
对于每个变量,每个相关角色建模影响:
| 领域 | 负责人 | 建模内容 |
|---|
| 现金与跑道 | CFO | 烧钱影响、跑道变化、过桥方案 |
| 收入 |
CRO | ARR缺口、流失级联风险、管道 |
| 产品 | CPO | 路线图影响、PMF风险 |
| 工程 | CTO | 开发速度影响、关键人员风险 |
| 人员 | CHRO | 流失级联、招聘冻结影响 |
| 运营 | COO | 产能、OKR影响、流程风险 |
| 安全 | CISO | 合规时间线风险 |
| 市场 | CMO | CAC影响、竞争暴露 |
第3步:级联效应映射
这是核心。展示变量A如何触发领域后果,进而引发变量B的效应:
触发:客户流失(56万美元ARR)
↓
CFO:跑道从14个月降至8个月
↓
CHRO:招聘冻结;留存风险增加(士气受挫)
↓
CTO:3个工程职位冻结;路线图延迟
↓
CPO:Q4功能发布延迟→客户留存风险
↓
CRO:NRR下降;现有账户速度降低→更多流失风险
↓
CFO:[次级级联——如不中断则可能死亡螺旋]
明确命名级联。展示可以在何处中断。
第4步:严重性矩阵
建模三种情景:
| 情景 | 定义 | 恢复 |
|---|
| 基准 | 一个变量发生;其他未发生 | 按计划可控 |
| 压力 |
两个变量同时发生 | 需要重大应对 |
|
严重 | 所有变量发生;完全级联 | 生存危机;需要董事会干预 |
对于每个严重级别:
- - 跑道影响
- ARR影响
- 人员影响
- 达到不可接受状态的时间线(触发点)
第5步:触发点(早期预警信号)
定义可衡量的信号,在情景确认之前告诉你它正在展开:
客户流失风险触发点:
- 赞助人失联超过3周
- 使用量环比下降超过25%
- 12月1日前未确认Q1季度业务回顾
融资延迟触发点:
- 流程开始60天后收到少于3份投资意向书
- 领投投资者要求尽职调查延长超过30天
- 竞争对手以更低估值融资(市场信号)
工程人员流失触发点:
- 工程团队在Glassdoor上有活动
- 工程师提出2次以上推荐面试请求
- 过去3个月内需要高于市场水平的offer反制
第6步:对冲策略
针对每个情景:现在采取的行动(在情景发生前),以减轻其影响。
| 对冲措施 | 成本 | 影响 | 负责人 | 截止日期 |
|---|
| 建立50万美元信用额度 | 5000美元/年 | 若发生流失可争取3个月 | CFO | 60天 |
| 为3名关键工程师提供12个月留存奖金 |
9万美元 | 锁定团队直至融资完成 | CHRO | 30天 |
| 将每客户收入集中度分散至<20% | 销售努力 | 降低单一客户风险 | CRO | 2个季度 |
| 压缩融资时间线,启动并行流程 | CEO时间 | 在跑道合并前完成融资 | CEO | 立即 |
输出格式
每次作战室会议产生:
情景:[名称]
变量:[A, B, C]
最可能路径:[实际发生的组合,附概率]
严重级别
基准(仅A):[跑道/ARR影响] — 恢复:[X项行动]
压力(A+B):[跑道/ARR影响] — 恢复:[X项行动]
严重(A+B+C):[跑道/ARR影响] — 生存风险:[是/否]
级联图
[A → 领域影响 → B触发 → 领域影响 → 最终状态]
早期预警信号
- - [信号1 → 指示的情景]
- [信号2 → 指示的情景]
- [信号3 → 指示的情景]
对冲措施(立即采取这些行动)
- 1. [行动] — 成本:$X — 影响:[带来的好处] — 负责人:[角色] — 截止日期:[日期]
- [行动] — 成本:$X — 影响:[带来的好处] — 负责人:[角色] — 截止日期:[日期]
- [行动] — 成本:$X — 影响:[带来的好处] — 负责人:[角色] — 截止日期:[日期]
建议决策
[一段话。做什么、按什么顺序、为什么。]
良好作战室会议的规则
每个情景最多3个变量。 超过3个就是噪音——你无法有意义地为5变量崩溃做准备。建模真正让你担心的那3个。
量化或估算。 收入下降没有用。42万美元ARR在60天内面临风险才有用。不确定时使用范围。
不要停留在一阶效应。 损害总是在级联中,而不是初始打击。
建模恢复,而不仅仅是影响。 每个情景都应该有我们做什么的路径。
将基准情况与敏感性分析分开。 不要混淆可能发生什么与可能发生什么。
不要过度建模。 每个规划周期3-4个情景是合适的数量。更多会导致分析瘫痪。
各阶段的常见情景
种子轮:
- - 联合创始人离开 + 产品错过发布
- 资金耗尽 + 过桥条款不利
A轮:
- - 未达ARR目标 + 融资延迟
- 关键客户流失 + 竞争对手融资
B轮:
- - 市场收缩 + 烧钱倍数飙升
- 领投投资者要求转型 + 团队抵制
与高管角色的整合
| 情景类型 | 主要角色 | 级联至 |
|---|
| 收入未达标 | CRO, CFO | CMO(管道)、COO(削减)、CHRO(裁员) |
| 关键人员离职 |
CHRO, COO | CTO(如工程)、CRO(如销售) |
| 融资失败 | CFO, CEO | COO(延长跑道)、CHRO(招聘冻结) |
| 安全漏洞 | CISO, CTO | CEO(沟通)、CFO(成本)、CRO(客户影响) |
| 市场变化 | CEO, CPO | CMO(重新定位)、CRO(新细分市场) |
| 竞争对手行动 | CMO, CRO | CPO(路线图应对)、CEO(战略) |
参考资料
- - references/scenario-planning.md — 壳牌方法论、事前验尸、蒙特卡洛、级联框架
- scripts/scenario_modeler.py — 结构化情景建模的CLI工具