"Good Enough" Is a Product Skill

Why perfection is the enemy of progress in product management

👋 Hey, Sam here! Welcome back to The Product Trench. Every other Wednesday, I cut through the noise to share actionable insights, no-nonsense advice, and stories related to product management and leadership. Occasionally, I share hot takes on topics that get me fired up.

Was this forwarded to you? Join The Product Trench 👇

---

Early in my career, I thought good enough was just a euphemism for cutting corners. If you weren't chasing the perfect design, the cleanest code, the most seamless experience—what were you even doing? I'd sit in meetings where we'd agonize over the tiniest details, believing we were upholding quality.

After years of failed attempts, including my own startup missteps, I came to a realization—perfection was keeping me stuck. I had spent too much time chasing flawless execution while customers were left struggling with broken, inefficient workarounds.

One release in particular made this clear. We had built a feature that streamlined a critical workflow for our users. But instead of shipping it, we debated whether it needed additional configuration options before launch—despite knowing that users already struggled with an inefficient process. Weeks passed, and while we chased the "right" answer, customers were still dealing with a frustratingly broken process.

That was the moment it clicked. Perfection wasn't the goal. Better was.

Product work is about making meaningful progress, not crafting a masterpiece. The key is recognizing when something is good enough to deliver value without getting trapped in endless refinement.

Why "Good Enough" Feels Wrong—But Is Often Right

The pushback against good enough is understandable. Designers want things to feel intentional. Engineers want the codebase to be clean. And PMs—especially newer ones—worry that anything less than polished is a failure.

But customers don't live in our Figma files. They don't see the 10 rejected design variations. They don't care that the API could be a little more elegant. They care about one thing: does this help them do their job better?

The shift happens when you stop measuring against an imagined perfect version and instead compare against reality:

• What do customers have today? If they have nothing, shipping something is already a win.

• How painful is their workaround? The more annoying or broken their current solution, the faster we should get them relief.

• Is this meaningfully better? Not perfect, just better.

This mindset has saved me and my teams countless hours, allowing us to focus on delivering solutions that actually help customers instead of obsessing over minor refinements.

How to Decide When to Ship

Here's how I make the call in practice:

1. If it solves the core problem, ship it.

The best way to tell if something is ready is to put it in front of real users. They'll tell you what's missing way faster than an internal debate ever will.

🚀 Example: On a recent project, we debated whether to delay launching a new reporting dashboard until filtering was available. Instead, we shipped without filters, and users told us exactly which ones they needed most. Instead of guessing, we built what actually mattered.

2. Prioritize what users will actually notice.

Some improvements seem important internally but don't make a real difference for customers. If users won't notice or care, it's not worth delaying a release.

🚀 Example: A team I worked with delayed a mobile app update because the loading state animation wasn't polished. When they finally shipped it, users didn't even mention the animation—because they cared about the feature, not the visual flair.

3. Set a deadline to prevent endless tweaks.

Leaving work open-ended creates a false sense that just a little more time will make things perfect. It won't. A deadline forces focus on what actually matters.

🚀 Example: During my digital agency days, a startup we worked with kept pushing back a pricing page redesign because leadership wanted it to "feel right." They set a hard deadline, focused on the most impactful changes, and launched. Conversions went up, proving that the endless tweaks weren't needed.

4. Remember: You can always improve later.

A release isn't the finish line—it's the starting point. The sooner it's live, the sooner you can gather insights and make it better.

🚀 Example: At Railz, we debated whether Step 2 should be before or after Step 3 in a sign-up flow. Instead of delaying, we picked one, launched it, and adjusted it based on drop-off data. Instead of guessing, we had real answers in weeks.

Final Thought: Good Enough is a Skill, Not a Cop-Out

Knowing when something is 'good enough' isn't about lowering standards—it's about making smart tradeoffs. Progress beats perfection when real customer impact is at stake.

At the end of the day, shipping something valuable beats waiting for perfection.

Takeaways You Can Use Today:

✅ When deciding whether to ship, compare against the current reality, not an idealized future version.

✅ If it solves the core user problem, ship it—you can refine it later.

✅ Set deadlines to prevent endless tweaking.

✅ Focus on what customers will actually notice.

✅ Treat launches as the start, not the finish line.

---

👋 And that’s a wrap folks. Thank you for reading.

If you enjoyed reading today's newsletter, feel free to forward it or share your referral link with someone! Or you can always hit the like button on this post so more people can discover it on Substack.

See you next time.

— Sam ✌️

---