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
Gmail launched in 2004 as an invite-only beta with 1GB of storage, a search-first interface, and conversation threading. It lacked labels, filters, rich text, and dozens of features that came later. Google shipped it because the core value (fast search + massive storage) was working. The beta label stayed on for five years. Gmail didn't need to be finished to be valuable. It needed to deliver the one thing that made people switch from Hotmail.
The Anti-Pattern
The Perfection Trap. Endless polishing that delays learning. Reid Hoffman said "if you're not embarrassed by the first version of your product, you've 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.
Jason Fried adds a 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. Basecamp reinvents its product every five or six years, each time as a total rewrite, because Fried would rather ship a focused, polished core than a bloated product that tries to do everything. The first version doesn't have to do much. It just has to do it well.
Written with ❤️ by a human (still)