When to Ship Rough vs Polished
· product-design, gtm
The Tension
Early stage: you can ship half-baked products because users are few (often friends), feedback is direct, and learning matters more than polish. But this doesn't scale — at some point, rough edges cost you trust, word-of-mouth, and users.
The question isn't "stop shipping rough" — it's "how to preserve fast iteration ability as you scale."
The Reversibility Heuristic
The key decision factor: how cheap and reversible is a mistake?
- Ship fast when mistakes are cheap and reversible
- Polish first when mistakes are expensive or permanent
- Ask: "What's the blast radius if this sucks?"
Signals Framework
| Ship rough | Polish first |
|---|---|
| Uncertain if anyone wants this | Demand validated, now executing |
| Feature is additive (new capability) | Changes existing behavior |
| Easy rollback, no data risk | Irreversible actions (money, data, trust) |
| Users opted into early access | Users expect finished product |
| Direct feedback channel exists | Feedback = silence or churn |
| Testing what to build | Building decided thing |
Meta-signal: Are you testing whether to build it, or building something you've decided to build?
Solutions for Scaling Without Losing Speed
- Staged access / feature flags — Keep a "beta" cohort who opt into rough stuff
- Expectation framing — "Labs" / "Beta" labels buy forgiveness (Gmail was beta for 5 years)
- Preserve a fast lane — Even at scale, maintain direct feedback channels with power users
What Actually Breaks at Scale
Not just "users expect polish" — it's:
- Lose direct feedback channel (can't DM everyone)
- Bad first impressions compound via word of mouth
- Support burden grows
- Can't easily segment who gets what
Related
- [[product-design]] — shipping philosophy
- [[gtm]] — user expectations at different stages