I'm Runbo Li, Co-founder & CEO at Magic Hour.
Most companies drown in scenario planning because they try to model the future. That's backwards. You don't prepare for scenarios, you prepare for the decisions those scenarios would force you to make. If three different demand curves all lead to the same action, they're one scenario, not three.
The rule I use is what I call "decision compression." I start from the end: what are the two or three irreversible decisions we'd have to make under stress? For us, that's things like committing to GPU capacity contracts, changing pricing tiers, or cutting a product line. Then I work backwards and ask, what conditions would trigger each of those decisions? That gives me a small, concrete set of scenarios worth actually preparing for, usually no more than three.
Here's where this got real. In early 2024, GPU costs were swinging wildly. One month a provider would drop pricing 30%, the next month a different model would require twice the compute. We could have built elaborate spreadsheets modeling fifteen cost trajectories. Instead, I asked one question: at what cost-per-render do we have to change our pricing model? That gave us a single number. We stress-tested around that number, built a plan for above it and below it, and moved on. When costs did spike that spring, we already knew exactly what to do. No emergency meeting, no scrambling. We executed the plan we'd already made.
The trigger I trust most is the "two-week rule." If a shift in demand or cost would force a major decision within two weeks and we haven't prepared for it, that's a scenario worth planning for. If we'd have months to react, it's not urgent enough to pre-plan. Speed of forced decision is the filter, not probability.
People over-index on likelihood. They want to rank scenarios by how probable they are. But probability is a guess. The real question is, how fast would this scenario force my hand, and how painful would it be if I got it wrong? Plan for the fast and painful ones. Ignore the rest.