Comment by daxfohl

I'd add, if feature A can't be shipped 10x faster, ask the same question about features B, C, and D and then redo your ROI calculations, before deciding to invest in feature A.

That keeps the team consistently delivering and motivated, and gives you more time to think about feature A. Some features are really important to get right and take the appropriate time, and some are just important to ship. Having that distinction explicit allows the team to maintain good shipping velocity without accruing "high interest" tech debt.

Also there's obviously no single correct ratio here. Newer companies, services, teams, products will probably lean toward shipping fast since architecture is still being defined (and too much architecture could be more detrimental than tech debt / too little architecture, if it doesn't match future requirements), whereas more mature ones will be more willing to sacrifice shipping velocity for better fit with the existing domain model.