Ship monthly, it's 12x learnings/yr. Ship daily, it's 365x

An arbitrary, overly ambitious release cadence like this sounds like a good way to end up knee-deep in technical debt.

What about the quality of learning opportunities? It seems that in order to maintain the quality of learning opportunities with more frequent releases, the team has to increase in size, too.

If the team size stays the same while the # of releases increases, I highly doubt daily releases can compete with weekly/monthly releases when it comes to the quality of learning opportunities.

Sometimes rapid iteration is the only way.

Shipping matters, yes, but what matters more is ADOPTION. Who cares if products or features are getting released if there isn't 1) support for them in the form of help center documents 2) marketing support to help get it in front of prospects 3) some analytics platform tracks the features/application usage?

I get that people want to keep pushing products into the world. I want to do that too. But we need to mindful that a product is only successful if its adopted, and the user's experience is measured and prioritized in their first 1-2 weeks of usage.

So, if your going to launch 12 products, you need to measure their adoption over time. This way, if a product is launched, you can measure whether or not people are spending time in it, and where they are dropping off or quitting. For all you know the products are just being put into the world and going unused. But without data you don't know.

Sadly, I have to disagree.

This kind of shipping cadence make indies hackers to forget about the other important side of a business: talk with clients... a LOT.

If they only focus on shipping they'll end with a nice software full of features, but with no clients.

I think it's a balance of speed and leverage of what you ship.

Shipping a bug fix that you don't learn anything from is not valuable learning.