> Is there any example of a startup that actually made it by employing this strategy?
Is there any example of a startup that actually made it by releasing features that were broken or poorly thought out?
Is there any example of a startup that actually failed because they released features a week or a month after an internal deadline?
Do we have enough insight into the internal strategy of enough companies to make any claims about this at all?
Your argument is basically looking at existing startup culture, but realize that most startups that use a fail fast strategy do exactly that: fail. I'm not saying that's causal: I think success is hard and there's a myriad of reasons why startups fail. But I don't think we can look at the fraction of startups that have succeeded and point to this one element of their strategy and say, "This was a necessary component of their success."
I'm not looking at the whole industry because I don't think there's enough representative data there. I'm looking at my own experience as a user and noticing, "Hey, I actually don't even know what features are planned for any of the software I use, yet I'm still using it. So maybe future features don't have anything to do with why I use software. And maybe other users are similar."
Let me ask you: can you name 5 features that you're looking forward to in the software you use? If those features take a year longer than expected to materialize, do you think you'd switch to a competitor? That's rhetorical: I am sure some HN people can answer those in the affirmative, but I'm also sure that's not the norm.
> One of the truisms I've heard and have always followed is you need to release something you're embarrassed about, because that's the quickest way of getting user feedback, and understand if a user actually _wants_ that feature, and if it's actually worth spending time improving that feature.
Sure, but then you don't know if the user doesn't want the feature because it's not useful, or because it's badly implemented since you didn't spend time to get it right. You're collecting data faster, but you're also confounding the data so that you don't know what it means.
> It's easy to waste valuable capital paying attention to details that the user does not really care about.
Agreed. One of the details I'm saying the user does not really care about is whether your feature is released today or three months from now.
> EDIT: I've noticed that most of the software you posted here is very well established, most > 10 years. I'd be surprised if any of them follow "agile" by the books.
...which is a pretty damning statement about '"agile" by the books'.
I'll say what I've said before many times: the entirety of agile is contained on this page: https://agilemanifesto.org/ . "Agile by the books" is an attempt to make money off a successful strategy, but you can't sell six lines of text, so people write books on how they implemented agile, which if you understand agile, is fairly useless for understanding how YOU should implement agile. If you really grok those principles, then it's really clear that releasing early to get user feedback doesn't follow the principles:
Individuals and interactions over processes and tools The deadline is a process rule that you're prioritizing over literally every individual in this situation.
Working software over comprehensive documentation Releasing broken software so you can document user response doesn't follow this principle.
Customer collaboration over contract negotiation Customers should be involved long before you're releasing features.
Responding to change over following a plan The deadline is the plan. The fact that the feature isn't ready by the deadline is the change that you need to respond to.