YAGNI
Many imagined requirements never become real requirements. Ship the minimum useful version, then let demonstrated needs—not forecasts—decide what gets added.
The feature you are carefully building for launch may be a feature nobody will ever need. YAGNI’s answer is blunt: leave it out and launch sooner.
E1Replace prediction with evidence
Before launch, requirements are hypotheses. Building each one immediately converts uncertain guesses into certain costs: more work, more complexity, and a later release. YAGNI delays that commitment. A minimum version reaches reality sooner, where actual use can reveal which additions deserve the effort. This preserves Optionality without allowing imagined futures to become Feature Creep.
E1Minimum still has to be useful
YAGNI is not a licence to omit what the product needs to perform its core job. It applies to speculative additions, not to requirements already shown to be necessary. The trade-off is accepting that a real need discovered later may require another round of work.
Make one feature prove its case
Before tomorrow’s build, choose one planned addition and write down the evidence that users need it now. If the case rests only on what they might want later, remove it from the launch scope and revisit it after real use produces evidence.
E1Episodes that teach this
-
The Psychology Behind Tight Deadlines | Future IQ
· explained at 5:39
6,130 views
"You ain't going to need it"; "launch with the minimum and then you can add more things later."