> But the idea that we should produce the absolute minimal thing at every stage – whatever is needed to push the company’s commercial goals forward
In my interpretation, the purpose of rapid iterations is to validate/de-risk hypotheses. In some cases (most of the ones I've worked on), it's ALSO a useful way to ship, because for many use-cases, people are pretty tolerant of shit software. But I think there's an implicit/accidental conflation of iterate-to-learn / iterate-to-build / iterate-to-ship. The difference between them being the end audience after each minor iteration. (respectively: myself / my team-mates / my customers)
All good points, thank you - your distinction between iterate-to-build vs iterate-to-ship is an important one, and something that was in the back of my mind when I was writing. I actually had a section on Stripe that argued that Stripe "do one thing extremely well" rather than "do lots of things poorly", but it didn't have a clear instance of a major technological breakthrough, so I cut it.
The goal here was not to argue that one OUGHT to take ages to ship - I hope I made that clear in the final section – but that there are certain types of ambitious technological visions that NEED a lot of technically risky work to achieve. And so many people shy away from these visions because they feel like they need to ship immediately!
In my interpretation, the purpose of rapid iterations is to validate/de-risk hypotheses. In some cases (most of the ones I've worked on), it's ALSO a useful way to ship, because for many use-cases, people are pretty tolerant of shit software. But I think there's an implicit/accidental conflation of iterate-to-learn / iterate-to-build / iterate-to-ship. The difference between them being the end audience after each minor iteration. (respectively: myself / my team-mates / my customers)