Ship it, iterate hard, and admit the outcome is a hope
The most honest word in this advice is “hopefully”. Shipping and iterating improve the odds; they do not guarantee the result.
Get your idea out in the wild, iterate your ass off, and hopefully build something spectacular.
Kyle Bragger built Forrst as a side project in 2010, a community where designers and developers could post work in progress and get feedback from peers. He said this in an interview about how it started. It grew by invitation, and its members used it heavily, which gave him the kind of steady feedback the advice depends on.
The first clause is about exposure. An idea kept private cannot be tested. Once real people use it, the founder learns what they do with it, which is almost never exactly what was planned. For a web product in 2011, getting something into the wild costs little: hosting is cheap, deployment is fast and a small community can be reached directly.
The second clause, stated bluntly, is about pace. Iteration means shipping changes often, watching what happens and adjusting. Teams that release weekly learn many times faster than teams that release twice a year, simply because they get more rounds of feedback. The work is repetitive and often dull, which is probably why the phrasing is so emphatic.
The third clause is the honest one. “Hopefully” admits that the process does not guarantee anything. Plenty of teams iterate hard on products that never become spectacular, or even viable. The effort improves the odds. It does not change the fact that most ideas do not work.
Iteration also needs a direction. Changing things quickly without a clear question about what should improve is a random walk, and random walks rarely reach anything spectacular. The useful form picks one measure at a time, such as whether new members return in their second week, and changes the product to move it. Forrst’s early decisions about invitations and feedback were of that kind: each one aimed at the quality of the community.
Some products cannot go into the wild half-built. Medical software, payment systems and anything handling sensitive data carry risks that early users should not bear. There the first release needs to be complete in the ways that protect people, even if it is small in every other way.
A reputation is also at stake. Communities remember a bad first impression, and a product that launched broken can struggle to be taken seriously after it improves. Shipping early works best when the first audience is small and forgiving, and when the founder tells them plainly that the product is unfinished.