Not the OP, but I believe he and you are talking about two different stages in the life of a company. He's describing mature products and organizations (as is the blog author), and you're talking about a company that is attempting to complete their first offering.

> 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.

In my last job we were sufficiently sophisticated users of AWS that we routinely had conversations with product managers to learn if specific features were on the roadmap, and if so, if there was an ETA. We had these conversations because we were debating whether we wanted to write a solution of our own, or if we wanted to wait for a generalized one to be released.

That said, the product managers generally left us with information such as "this is actively being worked on", "this is planned work in the upcoming quarter, but it could change", "this is on the roadmap without a date", and "this is not on the roadmap". No specific dates promised, but it was still good enough for our purposes.

I hope they weren't using our requests to push for specific dates, internally.

It is worth noting that ALL the agile values you spelled out are actually important. That said, the values on the right do not take precedence over the values on the left.

Processes and tools are important so long as they don't diminish individuals and interactions.

Documentation is important so long as it doesn't get in the way of building software that works.

Contract negotiations are important so long as they don't get in the way of a collaborative relationship with customers.

Following a plan is important so long as it doesn't get in the way of responding to change as a competitive advantage.