"Better" is the Enemy of "Good Enough"

“Better” is the Enemy of “Good Enough”

Sergey Georgiyevich Gorshkov, Admiral of the Fleet of the Soviet Union. Responsible for a massive naval build up that could rival Western forces by the late 1970s.

About a year and a half ago, I was working on a brochure for my cousin’s massage clinic. I was decent at Photoshop and Illustrator at the time and my cousin had a clear mission for his business. In terms of the project timeline, none of this matter. That little tri-folded piece of paper took us over 40+ man hours to create. Here’s the sick part… It’s not even finished.

So what happened? Perfectionism. We were too busy trying to perfect every message, every graphic, and every design. We were trying to create a work of art instead of just connecting a piece of the puzzle in the larger work of art - the massage clinic business. Scott and I lost site of that and the project never shipped. You can call it feature creep, mission creep, or just plain creepy. Whatever you call it, trying to go “Better” can really hurt your project:

“Better” breeds ego-involvement. The more you try to perfect something, the more effort goes into development. With that effort comes an attachment. I’ve been way over-involved on a few projects and when I was told that all of my effort wasn’t necessary, I was practically breathing fire. When developers are too close to their code, emotions can flare. This hurts the team as much as it does the project.
“Better” consumes time on something that might not be necessary in the first place. Look at the brochure example. My cousin’s business is doing great. He may never even use the brochures. The closer you get towards perfect, the more time it will consume to make it marginally better. That extra effort put in doesn’t justify the extra time spent. When it’s your first few iterations, don’t worry so much about the details, just get the project out the door.
“Better” stalls customer feedback. Why go great lengths to improve a feature when customers may end up wanting something entirely different? Get your basic idea functional and then let your customer’s decide if it’s good or bad. If they like it, then you can spend time perfecting it for the next iteration. If they hate it, then you can start on what they want. Either way, directional feedback is reached much faster when you ship with “Good Enough.”
Trying to go for “Better” kills momentum. When you hit your goals and see projects ship, you gain confidence and self-efficacy. You establish inertia as you move towards a certain direction. To quote my favorite business book, Rework: You can‘t build on top of “We’lldecide later,” but you can build on top of “Done.”
Perfectionism is toxic towards the team. If one member goes out of their way to be a perfectionist, then their persnickety qualms may flow into the entire project. They will say, “Why didn’t you polish this feature?” or “Why didn’t you finish that entire module?” because they are used to doing things that way. Let me rephrase that, they are used to overworking themselves in a blind direction. If they keep silent, they may resent the rest of the team for their so-called “Lazyness.” Either way, trying to go “Better” is too stressful. Why make deadlines harder to hit?

So don’t get so crazy about the first bunch of iterations. Think of them as feedback sensors. Get the feature to “Good Enough” and get the project out the door.