Time-to-market (TTM) is indeed an important factor for many businesses, especially startups. When it comes to software products, TTM translates into continuous integration and continuous deployment. The idea here is not that you ship buggy code, but that you ship fully working software on very regular basis. Although the frequency varies from team to team, it is not unusual for some companies and teams to ship several times per day, which makes a big difference compared to teams where a feature could be shipped six months to a few years later after being requested by the product owner.
In a context of continuous deployment, in order to prevent buggy code from hitting the production, teams are using extensive automated testing. Instead of spending six months developing a feature and then handling it to the quality assurance department for an eight months test-fix-test phase, those teams write tests at the same time they write code. Those tests run on every commit, and if any of thousands of tests fail, the product is not deployed on production servers, and developers are informed that they broke the build.
Note that TTM also translates in a marketing (and not technical) approach which consists of saying that it is more important to ship an often incomplete and imperfect product now, and see how actual users will use it, what would they like, and where would they encounter difficulties. Based on this feedback, the product is then adapted to the needs of the customers. Recently (i.e. for the past twenty years), this approach became successful, and is found to be efficient in a context of startups, compared to an ordinary approach consisting of doing market research and lots of studies prior to product development.
You asked for house/boat analogies, so here they are.
Imagine you're building a boat. You may spend a few months building it, then you put it in water, and notice that there are some engineering and construction flaws. You need to fix them before you can use the boat.
Instead, you may constantly be testing how your boat performs by putting it in water on daily basis. When you do an engineering or construction mistake, you'll have a feedback within a day showing that the change you did to the boat during this or the previous day caused an issue.
This may not apply well for a boat, since those things may not float well if they are half built (for instance if they are not painted yet). For software products, however, even a tiny feature of a product which is not yet built can already be tested, making software products ideal candidates for continuous integration.
TTM in marketing.
Imagine you're building a house. You may spend a few months building it and then showing it to the owner, just to learn that he wanted a swimming pool on the other side of the garden, and that he expected two more windows, and a different roof.
Or you may let the owner access the construction site once per week in order to receive very fast feedback, when it is still not overly expensive to do some changes.
Here again, the analogy is not perfect, because (1) the owner cannot live in the house which is not yet built (while users can start using a software product which lacks half of its features), and because (2) structural changes will be extremely expensive to perform once the construction started (which is often not the case for software products which were built correctly).