There’s a pattern I keep seeing in product teams: we aim for the “right” version of something, and in doing so, we never actually ship the useful version.
Nobody wakes up intending to slow things down. It happens gradually:
- We add one more abstraction “because we’ll need it later,”
- We align the design system,
- We make it extensible from day one,
- We wait for the other team to catch up, and
- Suddenly the customer has… nothing.
So this is a post about resisting that pull and a few principles you can use when you feel the work drifting away from real users.
- Perfect is usually optimized for us, not for customers
When teams say “let’s do it properly,” they’re almost always talking about internal satisfaction: elegant code, unified UI, one way of doing things, future-proofing.
Customers do not care.
Customers care about:
- Can I do the thing?
- Are the numbers right?
- Is it faster than the way I do it today?
If the answer to those three is “not yet, we’re still designing the framework,” that’s a smell. That’s when “perfect” has won on the inside and “useful” has lost on the outside.
Principle: if the work looks impressive in a demo to your colleagues but invisible to a customer, you’re optimizing the wrong audience.
- Momentum > completeness
A lot of products get stuck because they try to do two hard things at once:
- Replace or clean up the old way, and
- Introduce a better, new way.
Doing both simultaneously sounds responsible, but in practice it doubles the surface area, doubles decisions, and makes it harder to declare anything “done.”
It’s almost always better to pick one axis:
- either: “We’re cleaning up what exists, no new scope.”
- or: “We’re adding net-new value, we’ll redo the old thing later.”
Trying to do both is how you end up with PM notes like “blocked on design direction” for weeks.
Principle: reduce simultaneity. Ship on one dimension at a time.
- The hidden tax of “doing it right”
“Let’s do it right” sounds mature, but it has a hidden cost:
- It introduces new dependencies (on platform, on design systems, on other teams),
- It raises the minimum viable release to something non-minimal,
- It makes it harder to test with real users because nothing is small anymore.
- What people call “right” is often just “more coordinated.”
Coordination is good. But coordination is not value.
Principle: don’t let “future-proof” outvote “presently useful.”
- Ship the observable thing first
You can’t learn from a Figma file. You can’t learn from an architecture diagram. You can only learn from something a real person used, even briefly.
So a good forcing question is:
“What is the smallest version of this work that a real user can see and tell us something about?”
It’s not:
- “What’s the smallest version that makes the system elegant”, or
- “What’s the smallest version that supports every extension”, or
- “What’s the smallest version that marketing can make a full launch page for.”
Just: can someone use it and react?
Principle: if you can’t put it in front of 3 users this week, it’s too big.
- Defer platformization
Teams love to build for “everyone who might use this later.” That’s how you end up with general-purpose, no-purpose features.
There’s a better order:
- Build the thing for you (your current use case),
- Let it prove itself,
- Then harden it for others.
This feels backwards to some people and you may hear some shouting: “We’ll have to refactor!” But, refactoring a working, used feature is always easier than resurrecting an unused, overbuilt one.
Principle: make it useful, then make it reusable.
- Say what you’re not doing
A lot of scope creep is just unspoken anxiety.
- Design worries: “Will we have to redo this for mobile?”
- Engineering worries: “Will this scale when we add X?”
- Product worries: “Will partners be angry we didn’t make it extensible?”
If you don’t name the boundaries, people will quietly build for the biggest possible future.
So write it down, for example:
- This version is web-first.
- This version is for internal data only.
- This version is not extensible.
- This version is about visibility, not automation.
- This version is for 1–2 key personas.
When you do that, it becomes much easier to ship something small without everyone feeling like they failed the imaginary final state.
Principle: constraints make shipping emotionally safe.
- Lead with the commercial / outcome story
One more thing that helps: tie the smaller, shippable version to an outcome that leadership cares about.
Examples:
- “Shipping this thin slice unblocks real-user feedback in the same quarter.”
- “Getting this out gives us retention / activation data we can’t get from mocks.”
- “A narrow v1 reduces migration/support until we know merchants actually want it.”
When there’s a clear business reason to ship small, it’s much harder for “let’s just make it perfect” to win the argument.
Principle: small releases need a big why.
- How to spot you’re drifting into perfectionism
You can almost diagnose it from meetings:
- “Let’s wait until the component library is ready.”
- “Let’s not show it to users until we can tell the whole story.”
- “Let’s solve this for all products / all regions / all payment methods.”
- “Let’s figure out the long-term IA first.”
- “Let’s make it consistent with the future experience.”
None of those are bad sentences. But if they appear before anyone has seen a working version, you’re in danger territory.
Principle: if future concerns show up before present value, you’re drifting.
- The stance
If I had to compress this into one stance, it’s this:
Shipping is how we find out. Perfect is how we postpone finding out.
You don’t discover reality by thinking harder. You discover it by putting something small, slightly embarrassing, slightly incomplete in front of the people you’re actually building for.
If it lands, great, you’ve earned the right to make it nicer.
If it doesn’t, great, you found out early and have not over invested.
Either way, you’ve learned from real world feedback, from your customers who pay to use your product.