Source
When this applies
when your standard process timeline is longer than your actual survival runway and you must compress it radically
The takeaway
When physical iteration cycles are too slow to survive, substitute simulation for physical testing even at steep per-unit speed cost, because it collapses the overall calendar timeline.
Why it works
Simulating the product in software, even at a huge speed penalty (one frame per 30 seconds), let the team find bugs and validate design correctness without waiting for slow physical fab iteration cycles, trading painstaking manual verification time for calendar time.
One level up
Simulation converts a hard physical-cycle-time constraint into a labor/patience constraint, which is often the only constraint you can actually compress under pressure.
Where it stops holding
This stops working when no adequate simulation/emulation technology exists for the domain, or when the gap between simulated and real-world behavior is too large to trust the result.
Detail
situation: NVIDIA needed to design and ship a new chip in nine months instead of the normal two years, with no time for a prototype-and-iterate cycle.
decision: They spent roughly a third of their remaining cash ($1M) on slow chip-emulation technology from an unproven startup, manually verifying output frame-by-frame at one frame per 30 seconds, then taped out directly to mass production without a physical prototype.
outcome: The Riva 128 shipped on time, sold 1 million units in four months, and the emulation vendor (NVIDIA's only customer) later went out of business.
lesson: Betting the company on an unproven tool can be rational when it's the only path that fits the actual survival timeline.
In their words
They had to spend a million dollars just to get the emulator hardware and software to do this. Which I think they had generated some revenue, but it was still like a third of the cash that they had in the entire bank account.