You're here when: Something works but isn't great. Sales wants it yesterday, engineering wants another sprint, design says it's embarrassing. You need to decide: ship or polish.
The Heuristic
Default to shipping. The burden of proof is on waiting, not launching.
- Is this change reversible? If you can roll back or iterate post-launch, the risk of shipping early is low. If it's a hardware release or a pricing change that locks in contracts, polish matters more.
- Does it deliver the core value proposition? Not the full vision. Not the polished version. The core thing you promised. If a user can get the main benefit, it's ready.
- Who is blocked waiting for this? Real people (customers, sales, partners) waiting for a solution they need. Their cost of waiting is concrete. Your cost of imperfection is usually ego.
- Will extra polish change the outcome? Be honest. Will two more weeks of design polish change whether users adopt this? Or will it just make the team feel better about something that needs market feedback either way?
Decision Tree
Quick Example
An email product once launched in beta with a search-first interface, dramatically more storage than the market standard, and a handful of obvious gaps. It lacked dozens of features that came later. But the core value was already working. It didn't need to be finished to be valuable. It needed to deliver the one thing that made people switch.
The Anti-Pattern
The Perfection Trap. Endless polishing that delays learning. If you're not a little embarrassed by the first version of your product, you've probably launched too late. But know what "embarrassed" means here. Software has been around long enough that user expectations are high. You should not be embarrassed by how your product looks or feels. Your onboarding should be polished, interactions should feel smooth, the product should look legit. What you should be embarrassed about is the scope. It won't do the fifty things you wish it could. That's fine, that's the "limit the details, perfect the details" principle in action. Be embarrassed that it only does three things. Don't be embarrassed that those three things feel rough. The gap between "embarrassing scope" and "embarrassing quality" is the difference between a focused launch and shipping trash.
Here's the useful nuance: you're better off with a kick-ass half than a half-assed whole. The goal isn't to launch something incomplete, it's to launch fewer things done well. Cut the feature list in half, then make sure what ships actually feels good. The first version doesn't have to do much. It just has to do it well.
Written with ❤️ by a human (still)