Have you ever watched a project move quickly through the first major part of the work, only to slow down dramatically near the end. It feels as though the last 20% of the work is taking 80% of the time. The concept is clear and you’ve achieved the main structure of your project’s goals, and the people involved are motivated, excited, and clearly able to see how this project will create value. Then suddenly, the final details consume every conversation. A small wording change suddenly becomes a whole cycle of changes, or a small design concern turns into weeks of discussion. The 80% completion you already did was forward momentum that now just stalls and feels like you’ve done nothing at all, all in the name of perfecting that last 20%.
That situation is common because finishing something often feels riskier than building it. While a project is still in progress, it carries a kind of protective uncertainty where you’re just uncertain enough to keep moving ahead, since nothing is flagging as a risk. Everyone knows the project is still incomplete, so certain flaws and unknowns are expected, but everyone’s still motivated by the potential outcome. Once it’s ready to launch, even in a limited way, people begin imagining every possible criticism, or pointing out every missing element, because now the launch is real and certain, and nervousness about potential failures kicks in. Sometimes it manifests with a phrase that project managers dread hearing, “why didn’t you think of this” or “why didn’t you notice this before.” Those responses at the last minute become a motivation-killer.
This usually triggers a temptation to keep improving the work, making micro-adjustments to the plan until all of the concerns and risks disappear, which sounds reasonable until you realize that moment almost never arrives.
The familiar “80% good enough” idea is useful here, even if the number itself is not quite scientific. The point is that the first large portion of useful progress often comes faster than the final polish. Getting something from nothing to a working state, regardless of the type of project, often takes less time than getting it from functional to nearly perfect. That final stretch can be valuable, especially in areas where precision, safety, compliance, or reputation truly demand it. But the problem begins when there’s a mindset where every project is treated as though perfection is the only acceptable standard.
In many business projects, the smarter and often safer path is to launch with known gaps, learn from real use, and improve from there. A solution that is 80% complete and being used may produce more value than a solution that is 99% complete and still waiting for approval. The first project teaches you something. The second can easily become a pool of assumptions, corrections, wasted effort, and meaningless changes.
That is especially important when some of the assumptions end up being wrong. Teams can spend enormous amounts of time perfecting a solution that customers don’t even care about or tweaking a report that nobody reads anyway. That final 20% of effort was spent improving the wrong things. This is one of the silent costs of over-refinement: it gives the illusion of discipline while delaying the critical feedback that would have made the work better.
This does not mean organizations should lower their standards, and launch crummy products. It does mean that they should understand what standard the work actually requires; a minimum viable product so to speak. A customer-facing product, an internal tool, a board presentation, a compliance process, and a strategic planning document do not all carry the same risk or the same reward. Some work needs a very high degree of polish before release. Other work needs enough quality to be useful, understandable, and safe, followed by a disciplined improvement cycle. Treating every piece of work as though it requires the same level of perfection creates unnecessary delay and teaches people that movement is dangerous.
The better question is more simple than we often realize: when is it good enough for the next responsible step?
Or in other words, is 80% good enough actually good enough?
That question helps to avoid the bad choices made between sloppy work and perfect work, and focusing on “good enough” work, with a mentality that good enough really is good enough, but “better” can come later. Is the purpose clear enough? Is the core value present? Are the known gaps acceptable? Do users or stakeholders understand what is included and what still needs improvement? Can the organization learn something by moving forward now? If the answer to those questions is yes, continuing to polish may be less responsible than just releasing your solution, product, application, or service now, and improving later.
For leaders: this is where leadership discipline is essential. You need to distinguish between gaps that prevent value-add and gaps that merely offend someone’s preference. You need to know which imperfections create real risk and which ones simply make people uncomfortable. You need to protect your teams from endless refinement masquerading as “quality control” or “quality assurance.” There is a point where “just one more change” or “just one revision” becomes the reason that nothing meaningful gets delivered.
“Good enough” should never mean careless, but it should mean that the work is ready for its intended purpose, with known limitations understood and managed. It should mean that the organization has chosen movement with awareness instead of delay through uncertainty. It should mean that the next step will create more value than another round of internal polishing.
Perfection is expensive, and darn-near impossible! Use it when the work demands it. For everything else, the better discipline is knowing when things are good enough. Then just move forward, learn, and improve. Stop perfecting your assumptions, and starting testing your outcomes.