99% Is Closer to 0% Than 100%

Unshipped work has zero value—relentless focus on completion, not progress

Dmitry Zlokazov
Dmitry Zlokazov

99% Is Closer to 0% Than 100%

"If something is 99% done, it's closer to 0% rather than 100%." - Dmitry Zlokazov

What It Is

This framework is an execution mindset that treats incomplete work as effectively worthless. Until a feature is fully shipped—including adoption, training, and customer value delivery—progress is an illusion. The gap between "almost done" and "done" is where most value gets lost.

The insight comes from observing how often products get built but fail to deliver value because the "last mile" work never happens. Engineers finish the code, but customer support isn't trained. Marketing knows it exists, but sales doesn't position it. The feature is technically complete but practically useless.

This mindset forces product owners to think beyond shipping code to owning the entire value chain: Is support ready? Does marketing know? Are users actually using it? If not, you're at 0%, not 99%.

How It Works

The Problem with "Almost Done":

  • Code complete ≠ value delivered
  • Technical readiness ≠ organizational readiness
  • Feature shipped ≠ customer success
  • Progress feels good but doesn't matter until completion

What Actually Constitutes 100%:

  1. Feature is built and bug-free
  2. Customer support is trained and ready
  3. Sales and marketing can articulate the value
  4. Users can discover and adopt the feature
  5. Success metrics show actual usage
  6. Value is being created for customers

Why 99% Feels Like Progress:

  • Teams celebrate milestones that don't matter
  • Roadmaps track completion, not value
  • Demo-ability creates false confidence
  • The hard work often comes at the end

How to Apply It

  1. Redefine "done" - Create a definition of done that includes enablement, adoption, and value—not just code merge

  2. Track value, not velocity - Measure features by usage and outcome, not by shipping date

  3. Front-load adoption planning - Start enablement work before development finishes, not after

  4. Make PMs own the whole journey - Hold product owners accountable for usage metrics, not just launches

  5. Identify the last-mile work early - Map all stakeholders who need to change behavior for the feature to succeed

  6. Resist the urge to move on - Stay on a feature until it's truly delivering value, even when the next project beckons

When to Use It

Apply this mindset when:

  • Features repeatedly ship but fail to get adoption
  • There's a pattern of "technical complete" without customer impact
  • Teams celebrate launches but don't track outcomes
  • Organization has many stakeholders who need enablement
  • Product owners tend to hand off to "release" and move on

Balance with:

  • Sometimes learning comes from shipping imperfect things
  • Not every feature needs full enablement investment
  • Some features are genuinely complete when code ships
  • Perfectionism can also block progress

Source

  • Guest: Dmitry Zlokazov
  • Episode: "Dmitry Zlokazov"
  • Key Discussion: (00:56:29) - Discussion of execution mindset and what "done" really means
  • YouTube: Watch on YouTube

Related Frameworks

Back to Execution