You've been three weeks away from shipping for the past month.
You know the argument. Shipping beats perfection. Iteration beats polish. Learn in public beats shipping in secret. You believe all of it.
But there's still one feature that isn't quite right. One thing that would take just two more days to finish. One thing that feels unfinished if it launches without it.
So you keep polishing. And shipping doesn't happen.
Define your core
Here's what actually matters: what does this solve? Not what would be nice to have. What does it solve?
Write that down. One sentence. That's your core.
Everything else is optional.
Your core might be: "This saves people from losing a lead on a cold email." That's what it has to do, or it doesn't ship.
Your core is probably not: "This has a beautiful animation on the onboarding flow" or "This has every integration we could possibly add" or "This has the exact UI pattern we use everywhere else."
Those are nice. They're not core.
Defer everything else to phase 2
Phase 2 is not a lie. It's not a promise. It's a holding pen.
Phase 2 says: "This feature is interesting. We're not building it now. We might build it later. Or we might not."
That's honest. That's what phase 2 is for.
If you've been telling yourself a feature is "almost done" for two weeks, it's not almost done. It's a sign that it's not core. Move it to phase 2 and stop touching it.
Most phase 2 features never ship. Some do. Either way, you've freed up the bandwidth to actually launch.
Your ruthless prioritization framework
This is simple. For every feature still in the product, ask three questions:
Does this solve the core problem? If no, it's phase 2.
Does it have to work before people can use it? If no, it's phase 2.
Would you ship without it? If no, you know your answer.
That's it. Apply it to everything that isn't locked in yet.
You'll find stuff that sounds important but isn't. Most things fall into phase 2 when you actually ask.
Ship before you're ready
Ready never comes. There will always be one more thing.
But there's a difference between shipping with 80% of the features and shipping with bugs that break the core promise.
Incomplete is fine. Broken is not.
If it solves the problem, ship it. The people who need it are waiting. The improvements come after they see it.
And you learn more from real users in one week than from three more weeks of polishing.
What features you cut that no one notices
You probably already know this, but it's worth saying out loud: most features you cut to get to launch? No one ever asks for them.
The "better onboarding experience" you deferred? Not mentioned once.
The "more filter options" you moved to phase 2? You might hear the request once or twice over time. You could probably build it in a day if you had to.
The dashboard widget you thought was essential? Your power users don't use it.
What people actually care about is whether the core works. Whether it does what you said it does. Whether they can use it without breaking.
Everything else is noise.
FAQ
Q: What if the team disagrees about what's actually core?
You have a real disagreement. The framework exposes it. If someone insists a feature is core and you want it in phase 2, that's a prioritization conflict, not a scope issue. Resolve it before building, not after. Usually the disagreement disappears once someone has to defend "core" in concrete terms. Often they realize they haven't actually thought it through, just felt like it should be there.
Q: Won't shipping incomplete features hurt adoption or brand perception?
The opposite. Shipping incomplete and being transparent about it builds credibility. Users respect a working MVP over a perfect product that doesn't exist yet. Your brand gets hurt by shipping late and claiming you've been polishing for quality. It gets stronger by shipping fast and proving you iterate based on real feedback.
Q: How do I communicate to stakeholders that phase 2 features might never ship?
Tell them directly: "Phase 2 is a holding area. We'll build it if people need it. If no one asks, it probably wasn't core anyway." Most stakeholders respect honesty over false promises. And when a phase 2 feature quietly disappears because the product worked fine without it, that's proof your scope call was right.
Q: What should you tell customers about the features you deliberately cut?
Be direct: "We're shipping X. Phase 2 includes Y. Here's why we prioritized this way: Z." Transparency disarms skepticism. Vague roadmaps invite suspicion. Most users will respect the honesty.
Q: What if it's broken only for 5% of users?
Ship it. "Broken" means the core doesn't work as promised. "Doesn't work perfectly for 5% of edge cases" is iteration, not a blocker. If 95% of users can use it and you have a fix queued, ship it and be public about the limitation and your timeline to fix it.
Apply this to your stuck project today. Define your core, cut the rest, and ship. If this doesn't land for you, share it with a builder who's stuck. They need it.