Why Perfection is the Enemy of Progress (And What to Do Instead)

I was on a call with a custom manufacturer recently, helping them think through automating their quote follow-up process. They’re a shop that builds custom products for their customers, and like most manufacturers in this space, they had a problem: open quotes were slipping through the cracks.

The idea was simple. Pull open quotes from their ERP that were older than 10 days. Cross-reference those against their CRM. If a quote didn’t already have a follow-up task, create one. Basic stuff. Maybe two hours of development time, four hours worst case.

But then the conversation started to expand.

“Could we also generate email templates for each outreach?” “What about integrating with Microsoft 365 so the emails send automatically?” “Can we assign tasks to specific reps based on territory?” “What if we built logic to change the messaging based on how old the quote is?”

Every idea was valid. Every feature would add value eventually. But stacking all of those requirements onto V1 meant we were designing a rocket ship that would never leave the launch pad.

So I pulled it back. “Let’s prove the concept first. Two hours of development. Get the basic loop running. See if it actually moves the needle on quote follow-up. Then we iterate.”

That conversation happens in some version on almost every client engagement I have. The specifics change. The pattern doesn’t. Leaders see the full vision of what something could be, and they try to build the finished product on the first attempt. The result is usually the same: nothing ships.

The Real Cost of Waiting for Perfect

This isn’t a mindset problem. It’s an operational problem with measurable consequences.

That manufacturer I mentioned? Their sales team was spending 15 to 30 minutes every day manually exporting quote data, filtering it in Excel, sorting by date, and trying to figure out which prospects needed follow-up. That’s roughly 125 to 250 hours a year burned on a task that a basic automation handles in seconds.

Every day they spend designing the perfect version is another day the team spends on manual workarounds. The cost isn’t theoretical. It shows up in the time logs, in the quotes that don’t get followed up on, in the revenue that walks out the door because nobody called back.

And this extends well beyond technology projects. I see the same pattern in process improvement, in documentation, in training programs. Teams spend months building the “right” SOP, getting every edge case documented, formatting it perfectly, getting three rounds of management review. Meanwhile, the shop floor is still running on tribal knowledge because the “draft” version never got released.

The pursuit of perfection doesn’t just slow things down. It maintains the status quo. And the status quo is what you’re trying to fix.

Solving the Wrong Problem Perfectly

There’s a second layer to this that makes it even more expensive.

I was talking to another manufacturer about their inventory management. They were doing a significant amount of work outside their existing inventory management tool, tracking things in spreadsheets, running manual counts, reconciling data by hand. The usual symptoms.

Now, the obvious move here would be to automate those spreadsheets. Build macros, connect them to the system, streamline the data flow. And sure, that would reduce some of the manual effort.

But that’s solving the wrong problem.

The real question is: why is the work happening outside the tool in the first place? If the inventory management system doesn’t support the work the team actually needs to do, perfecting the workaround doesn’t fix anything. It just makes the workaround faster. You end up with a beautifully automated process that’s still pointed in the wrong direction.

This is where the perfection trap and the “just try stuff” trap meet in the middle. On one end, you have teams that won’t move until every detail is figured out. On the other end, you have teams that keep tweaking and experimenting without ever stepping back to ask whether they’re working on the right thing.

Both patterns lead to the same place: a lot of effort with very little progress.

The Space Between Over-Planning and Winging It

The answer isn’t to abandon planning. It’s to stop planning past the point where planning is useful.

This is where I lean on a concept I call P.E.R.R.R.: Plan, Execute, Review, Revise, Repeat. It’s a continuous improvement cycle, and the key word is “cycle.” You don’t plan once and execute forever. You plan enough to get moving, execute against that plan, review what happened, revise your approach, and repeat.

The perfection trap happens when teams get stuck in the Plan phase. They plan and plan and plan, looking for certainty before they’ll commit to execution. But certainty doesn’t exist in operations. Your variables are constantly changing. Customer demand shifts. Material availability fluctuates. People leave, new people start. The idea that you can plan your way to a perfect outcome before you start is a fantasy.

The opposite trap, the one where teams “just try stuff,” happens when they skip the Plan phase entirely. They jump to Execute without defining what success looks like. So they iterate endlessly, but they have nothing to measure against. There’s no way to know if the changes they’re making are actually improvements because they never established a baseline.

The productive space is in between. Plan enough to know what you’re trying to accomplish and how you’ll measure it. Then go. Execute the plan, even though it’s not perfect. Collect the feedback. Revise. Repeat.

That automation project? The V1 plan took about 15 minutes to define. Pull quotes older than 10 days, check for existing tasks, create tasks where they don’t exist. The success metric was straightforward: is the sales team spending less time on manual follow-up? Are more quotes getting touched?

That’s enough to get started. The email templates, the territory assignment logic, the Microsoft 365 integration? Those are V2, V3, V4. They happen after V1 proves the concept works.

Why Leaders Get Stuck Here

There are a few reasons this pattern is so common, and none of them are because leaders are bad at their jobs.

The stakes feel high

When you’re running a $10M or $20M manufacturing operation, decisions feel permanent. You’re buying equipment, hiring people, signing contracts. The fear is that getting it wrong is expensive. And it can be. But getting nothing done is more expensive.

Previous failures create caution

Most leaders I work with have been burned by a bad implementation before. A software rollout that went sideways. A process change that the team rejected. A consultant who delivered a binder and disappeared. Those experiences teach leaders to be thorough, which is good. But thoroughness without a deadline becomes paralysis.

The team expects a finished product

There’s a real concern that rolling out something imperfect will erode trust. “If we launch this and it’s not right, the team won’t buy in.” I hear this a lot. And it’s valid, up to a point. But here’s what I’ve found: teams lose more trust from being told “we’re working on it” for six months than they do from being handed something that works 80% of the time on day one.

Perfection feels like diligence

This is the sneaky one. Over-planning feels responsible. It feels like you’re being careful, thorough, strategic. It doesn’t feel like procrastination. But if the planning never converts into action, the intention doesn’t matter. The output is the same as if you’d done nothing.

What Actually Works

Here’s what I tell clients when I see them circling the perfection trap.

Define “good enough for V1”

Before you start any project, process change, or system implementation, answer one question: what’s the minimum version that proves whether this idea works? Not the full vision. Not the version you’d be proud to show at a conference. The version that gives you real data.

Set a time limit on the planning phase

If you’ve been planning something for more than two weeks without executing, something is wrong. Either the scope is too big (break it down), the decision-maker isn’t clear (fix that first), or the team is avoiding the discomfort of execution (that’s a leadership conversation).

Separate the problem from the solution

Before you perfect a solution, make sure you’re solving the right problem. The inventory management example is a perfect case. Automating spreadsheets feels productive. Asking why the system isn’t working in the first place is productive.

Ship, then iterate

Get the V1 out. Collect real feedback from the people actually using it. Then make it better. Real-world feedback is worth more than six months of planning because it tells you things your team couldn’t anticipate from a conference room. The shop floor will always surprise you.

Measure against the plan, not against perfection

Go back to the basics: did we do what we said we were going to do? Did it produce the result we expected? If yes, iterate forward. If no, dig into why and revise. That’s the cycle. That’s how sustainable improvement works.

Final Thoughts

Operational excellence isn’t about getting everything right the first time. It’s about building a system that gets better over time. That requires movement. You can’t improve something that doesn’t exist yet.

The custom manufacturer I mentioned at the top? They’re going to have a working automation inside of a week. It won’t do everything they imagined on that first call. It will do the one thing that matters most: make sure open quotes don’t fall through the cracks. And once they see it working, they’ll have the data and the confidence to add the next layer.

That’s the model. Not perfection. Progress. Define the problem. Build the simplest version that tests your hypothesis. Review what happens. Revise. Repeat.

Your business is full of variables that change constantly. The idea that you can plan your way to a perfect outcome before you start moving is the most expensive illusion in operations.

So ask yourself: what project, process, or decision are you holding back because it’s not “ready”? What would it look like to ship V1 this week?

That’s it for today.

See you all again next week!

Dave