> [!tldr] Rushed to a basic prototype to evaluate before doubling down on what may not be working There was a tight iteration timeline for the iPhone. They said there were timelines for prototype deliverables where we would stop and look at how things are working before going too far out on a limb that won't work. This is sort of [[Zero-Based Budgeting]] for product development. And/or [[Low-Cost Trials]]. Make something fast. It won't be perfect. You will [[1000 failures from mastery|Fail fast. Learn fast.]]. Then **stop and evaluate**. [[First Idea ≠ Best Idea]] - avoid [[Sunk Cost Bias]] by using a large-scale [[Scheduled Breaks|Scheduled break]] to stop and evaluate "how is this going? Should we keep going this way?" **** # More ## Source - [[Inside the Box]]