It’s been a while. Sorry about it. Time flies.
What happened you ask?
Well, a few things. It’s been somewhat busy at work, kids were sick at points. I had some complicated personal things to care about.
That kept me busy for a few mornings.
But mostly, I made the good the enemy of “done”.
See, I wanted to describe in some detail how I figured information structuring and handling. I read some stuff and rabbit holed into it.
But it’s complicated: there’s the theory. And the philosophy behind it. And the tools. And how I configure the tools. And how it all connects together. And more hacks. And even more stuff.
And it’s all interconnected. Pulling the first thread seemed easy enough, but I started the same post a few times. And I’ve yet to figure out how to sort it.
It was never acceptable. And days went by. In order to have something perfect to share, I didn’t share anything at all.
Now. You might think I’m an insecure idiot, and you might be right. However, I want to bring this back to a lesson learned.
I have seen time and again, in each and every team I worked in, this happened at some point.
“Can we get the product in front of customers?” “Not quite yet. Almost there. We really can’t launch without this last feature ironed out.”
“Should we review the design you’re proposing?” “I don’t think it’s ready yet. It doesn’t cover a bunch of really important edge cases.”
Sounds familiar?
Maybe we are all insecure idiots, after all.
The Trap of “Almost Ready”
Here’s the thing: “almost ready” is a lie we tell ourselves. It’s a comfortable lie because it feels productive. We’re working! We’re improving! We’re making it better!
But while we’re polishing, someone else ships. While we’re adding one more feature, users are waiting for the basic functionality we already built. While we’re perfecting the design, the market moves on.
I’ve watched projects die because they were never “good enough” to launch. I’ve seen brilliant ideas gather dust because someone was waiting for the perfect conditions. The perfect conditions never come.
When Is It Actually Ready?
So how do you know when to ship?
Ship when it solves the core problem. Your blog post doesn’t need to cover every edge case if it addresses the main point. Your product doesn’t need every feature if it delivers the core value.
Ship when you’re embarrassed but not ashamed. If you feel zero embarrassment, you waited too long. If you feel shame, it’s genuinely not ready. The sweet spot is that uncomfortable middle ground where you know it could be better, but it’s good enough to be useful.
Ship when more time won’t make it meaningfully better. Diminishing returns are real. The jump from 0% to 80% takes less time than the jump from 80% to 90%. 90% to 95% might take forever. Ship at 80%. Pareto is your friend.
Waiting is Expensive
Every day you don’t ship has a cost:
Opportunity cost: You’re not getting feedback. You’re not learning what users actually want. You’re building in the dark.
Motivation cost: Nothing kills momentum like endless polishing. Shipping gives you energy. Perfecting drains it.
Market cost: Someone else is shipping while you’re polishing. They’re learning while you’re theorizing. They’re iterating while you’re perfecting your MVP.
So What Now?
I’m going to commit to shipping “good enough” more often:
Daily practice: I will get rolling even when I don’t have the perfect structure figured out. Like the SMART projects approach, starting small and iterating beats planning perfection.
Two-day rule: If I can’t improve something meaningfully today, I will ship it as-is.
Versions: Everything is v1. I can always make v2 if people care. But I need to ship v1 first.
Here’s your permission: ship it. Put it out there. Get feedback. Iterate.
Done beats perfect. Every. Single. Time.
Ship it.