On Shipping Something Imperfect And Why That's Actually the Job
I’ve held things back that I shouldn’t have.
A case study that was nearly done but felt slightly rough in one section. A landing page that was ready but needed “just one more pass on the copy.” A feature that was built and tested but hadn’t been documented properly.
In every case, the thing I was waiting for was some version of “ready.” And in almost every case, what I actually needed was to ship it and find out.
This is one of the quieter tensions in product work and in building things generally. The gap between “good enough to learn from” and “perfect enough that I won’t be embarrassed by it.” That gap can eat weeks if you’re not careful about it.
What waiting actually costs
There’s a version of perfectionism that looks responsible from the outside. You’re being thorough. You’re caring about quality. You’re not putting something out in the world that doesn’t represent you well.
But there’s a cost to waiting that almost never gets calculated honestly: the cost of not knowing.
Every week you don’t ship is a week you haven’t found out if it works. If it converts. If users understand it. If the thing you thought was the problem is actually the problem. You’re running on assumption, not evidence, and assumptions decay slowly without you noticing.
The feature that feels ready in week two of building starts to feel stale in week six because you’ve had six weeks to get attached to specific decisions that might be completely wrong. The longer you wait, the more invested you become in the version you have, which makes it harder to change when you discover (after shipping) that it needs to be different.
Shipping is how you stop the attachment from calcifying.
What “done” actually means in product work
I spent a while carrying around a definition of “done” that came from school: done means finished, complete, nothing left to add or fix.
That definition is almost completely useless for product work.
In product, done means: good enough to learn from. It means the thing works. It means a real user can interact with it and form a real opinion. It means you’re not sending people to something broken but you are sending them to something that might be imperfect, and that’s fine, because imperfect-and-shipped teaches you things that perfect-and-delayed never will.
This isn’t the same as careless. The things you cut in the name of shipping should be the things that don’t affect whether you can learn. You cut the polish, not the function. You cut the extra features, not the core one. You cut the refined onboarding copy, not the working onboarding flow.
The line between “too rough to learn from” and “good enough to ship” is a judgment call. And making that call well is genuinely part of the skill.
The fear underneath the delay
I want to be honest about something, because I think it gets sanitised in most of the writing about shipping quickly.
The real reason most things don’t get shipped on time isn’t because they’re not ready. It’s because shipping is when you find out. And finding out is scary.
What if nobody uses it? What if it’s slower than expected? What if the users don’t understand it and the confusion is embarrassing? What if you ship it and the feedback makes it clear that the whole approach was wrong?
These fears are reasonable. They’re also, in my experience, better when faced than when avoided.
Because the other option, sitting with the thing un-shipped, polishing it in private, imagining all the ways it could be received is its own form of anxiety. Just quieter. And it never resolves. You can’t get closure on a thing that hasn’t been sent into the world.
Shipping creates the possibility of feedback. And feedback, even hard feedback, is something you can work with. It’s less frightening in practice than the dread that precedes it.
A few things I’ve learned to watch for
Over time, I’ve noticed some patterns in myself and in the founders I’ve worked with that usually signal “this is fear, not diligence”:
When the last 20% takes as long as the first 80%. Real polish is fast when the substance is solid. If you’re spending weeks on things that aren’t changing the fundamental value of the thing, the substance might be ready and the fear might be running the clock.
When you keep finding new things to fix. There’s always something. The homepage could be tighter. The onboarding could be smoother. The mobile layout could be better. If the list keeps regenerating, you’re in a loop that shipping is the only way out of.
When you’ve stopped listening to feedback from the people who’ve seen it. Sometimes a version is good enough and the people around you are telling you that, but you’re not quite believing them. That’s worth examining honestly.
The thing that helped me most
The most useful shift in how I think about shipping came from reframing what I was actually putting out.
I used to think of it as releasing a product. Something finished, evaluated, complete.
Now I think of it as starting a conversation. The thing I ship is my opening move. The users respond. I respond to their response. The product evolves through that exchange. The “done” I was waiting for was never coming, because nothing is ever really done, it’s just in conversation or not.
When you think of it that way, the pressure to be perfect before you ship goes down. Because perfect doesn’t make sense as a criterion for an opening move. You just need it to be clear enough, honest enough, and useful enough that the conversation can begin.
That’s all shipping ever is. The beginning of a conversation you can’t have until you’ve said the first thing.
Say it. See what comes back.