Launch early, then keep launching早點上線，然後不停地上線

Launching early is not about being sloppy, it is about shortening the distance between your guesses and what the world tells you. The second part is where many teams fail: once you ship, you have to keep launching, again and again, in smaller, sharper steps.

Start so small that you can launch into obscurity

In Paul Graham's "How to Start a Startup" essay, he points out that early stage products almost always start narrow, ugly and underpowered. That is not a bug, it is a way to make something a few people truly love before you try to impress everyone. Launching early into a tiny circle of users gives you room to break things, adjust the product, and gradually grow the circle instead of waiting for a mythical perfect day.

An MVP is not a prototype, it is the first version you are willing to charge for

Y Combinator's guide to planning an MVP reframes it as the smallest coherent product that solves one real job well enough that someone would pay. It is not a slide deck or a hacked together demo that nobody uses after demo day. Defined this way, the MVP becomes a commitment to launch something real quickly, then upgrade it in front of real users rather than in private.

A short checklist before your next launch

• One clear user, one clear job, and one clear success moment you want them to reach
• A version that can be shipped in weeks, not months, with unpolished parts listed explicitly
• A tiny launch surface, like ten users or one channel, where you are fine being ignored
• A follow up plan for what you will improve in the next two launches
• A decision rule for when to expand the circle, and when to keep iterating in place

The takeaway

• Launch early into a small circle so you can afford to be wrong and fix it in public
• Treat your MVP as the first real version you charge for, not a disposable prototype
• Make launching a loop, not an event, and your product will improve faster than your plans