Perfect Vs. Good: How I Drive Product Outcomes Sooner Through Imperfection

Why striving for flawlessness might be holding you and your product back.

“You just gotta ship it.”

As a recovering perfectionist, this is the best advice I’ve ever received.

My quest for perfection started early in life, likely driven by my father. His high standards for himself became his expectation for me. I’m thankful for this learned trait, but it can also be a burden. Especially when it comes to product work.

Like many others, I started my journey thinking a perfect product was the goal. While many successful products we know and love seem perfect, they didn’t start there. Even the iPhone started as a pale shadow of its success today. It didn’t even have custom Apps or an App Store when it launched. Heck, even the mighty Amazon started as an online bookstore.

Yet, perfection remains what most of us strive for in product. As a result, many products fall far short of their potential or outright fail.

Often, we focus on the wrong thing in our pursuit of perfection.

Features. We assume if we fill the product with features, it will wow the customer with the sheer volume of options. But what this does is confuse the user. Think of any Microsoft Office product and all the features you never use. These don’t matter to you. What matters to you as a user, is what features you need and put to use every day. Apps like Snapchat or Instagram succeeded with minimal features initially. Feature bloat slows you down from delivering what your customers need.

Effort. If we work harder and longer, we assume we will create the perfect product through a sheer force of will. So, we end up starting too much at once and burning out with nothing to show for it. Have you ever felt like this? I remember a few years back when I was working with 8 clients at once and 60+ hours per week. Anyone looking from the outside would claim I was wildly busy and productive. But truth be told, it was not my best work. I couldn’t keep all the plates spinning without them crashing down.

Deadlines. We assume If we deliver when we say we will, our commitment will drive product success. But what actually happens? We cut corners in a mad rush to hit the deadline at the 11th hour. We deliver something that sort of works if you squint and look at it the right way in a certain light. Does hitting a deadline equal success? Customers don’t remember you hit a deadline. They love a product for how it makes them feel and how it improves their lives. Apple is notorious for this. They are late to the game, but they have rabid fans.

We measure output to death as if it makes the difference between product failure and success.

But no amount of features, effort, or hitting deadlines guarantees anything. 

When these things become the goal, we’ve lost. We chase quotas and fake trophies for them. But they don’t substitute for the only measure of product success.

Successful products deliver what users need in the time that they need it. Then, users use it and delight in its usefulness.

Early in my career, I worked on a strategic product with no shortage of grand feature ideas. Too many, in fact. My team did something shocking: we talked to our users. Turns out, all they needed was a simple database lookup to solve 90% of their pain. We delivered a simple tool in two weeks, with exceptional results.

• Happy customers (what they needed when they needed it)
• Happy stakeholders (low cost, high value)
• Happy team (easy effort and great results)

We achieved the unicorn of minimal output and maximum outcome. It was the right thing, in the right time, in the right way.

It’s clear. We shouldn’t focus on the traditional measures of output. So, what are we left with? How do we make products people love?

Quality. 

Although, quality is tricky. We can fall into a perfection trap with quality, too. And before long, we take our eye off the customer and lose sight of what matters most.

It’s a delicate balancing act—an unwavering focus on quality, but not too much.

Let’s dive into both external and internal quality—two sides of the same coin.

External quality is in the eye of the beholder (your user).

I often find myself polishing the perfect product, delaying what’s important: shipping.

Here we are, back to that statement I made at the beginning, “You just gotta ship it.” A colleague of mine told me this many years ago. She explained that admiring or obsessing over my creation does nothing to tell me if it’s actually any good. Straight talk; sound advice.

Your customer is your only external quality gauge.

But we often assume we know what the customer needs without verifying it.

We try to build it right the first time. This is strange. Why would we assume we can get it right on the first try? Anything new takes practice. We should know this, yet we act as if we don’t.

But how do we practice in product?

Practice happens through iteration. We try something simple, often many basic things, to see what sticks with our users. When users tell us we have something that shows promise, we iterate with them until good enough. Then, we stop.

Quality requires many tries and refinements. It’s not a one-and-done.

But here’s the tricky part: you don’t always know what quality looks like before you start. A product team I worked with went through ten iterations of an idea with their customer. And what they ended on looked and behaved like nothing they could have dreamed up in the beginning.

You can’t predict what users will love. It emerges.

The perfect amount of quality requires many practice runs. It’s a dance with your customer. And when you nail the dance moves, you stop. You have to know when enough is enough.

External product quality is a pursuit, a practice, and a balance.

But there is another form of quality—internal quality—which also has some nuances.

You and your product won’t survive without internal quality (but it could also be your downfall)

Internal quality in software product development is a speed throttle.

You reduce your productivity when you make any compromise to your internal quality. You have to work around it, it attracts other shoddy work, and it’s prone to causing other mistakes.

I’ve learned this the hard way. One of my teams would not fix defects when they showed up. We felt we could get to them later. Well, when later finally came we had over 800 defects to toil through. And they had spread through the codebase like a cancer. It was not a happy time as our progress stopped for four months to unwind our mess.

Internal quality drives your speed of delivery.

You can also focus too much on internal quality. This has sent many teams over the cliff of unnecessary perfectionism.

Often, this happens when we perfect the internals of features not needed by our customer. Should we ensure our code is perfect if nobody will ever use it? Uh, no, we should not. But I see teams make this mistake when they build without their users.

I have also worked on many teams who pile on safeguards for situations that rarely or never occur. They find that one edge case that may happen but never has. Then, they write many tests to cover it and code logic to prevent it. This is how internal quality goes off the rails.

Building quality in doesn’t matter for things never used. But nothing else matters more for things that are.

Again, striking the right balance is crucial.

By focusing on quality, you make space for things that matter.

When you focus on quality, you make room for more.

• A more sustainable pace.
• More features the user needs.
• More time to handle the unexpected.
• More space to do the things that make you better.

Why?

It’s simple. You don’t have the excess work that comes with toiling over unneeded features, chasing unrealistic dates, and cutting corners. Then, you can take all that time you save and apply it to things that matter.

The teams I’ve worked with who focus on quality are not overstressed and overworked. They don’t have low morale from working on a product that has no audience. And they don’t have to raise the alarm for product code red situations resulting from neglect. What they do have: an abundance of purpose and mastery that drives them.

In the product space, we talk a lot about having a value focus. We talk about outcomes over output. But what we should be talking about is having an obsession with quality.

Teams who focus on quality get rewarded with happy customers and fewer emergencies.

Quality is the lever you should obsess over but in the right way.

Quality is one metric you can’t game.

You either have quality or you don’t. Your users either love what you build or you end up performing to an empty stadium. Your product thrives from care and precision, or it crumbles at the first sign of trouble. You either waste time on the unneeded, or you focus on what matters.

Quality must be your focus, but be careful not to fall into an unhealthy focus on perfection.

To achieve this, you’ve got to put in the reps.

You emerge the perfect amount through practice and iteration. Users help you emerge the right amount of external utility. And you refactor, tune, and protect, building resiliency as you change your product.

Who told you product would be easy? Perfection comes from deliberate practice in the pursuit of quality. Not too much, and not too little. It has to be just right to hit perfect.

---

➡️ Sign up for weekly tips like this on doing more with less while respecting people.