Tom Cargill at Bell Labs said it in 1985: “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.” That quip, first published in Jon Bentley’s “Bumper-Sticker Computer Science” column for Communications of the ACM, has been quoted for four decades because nothing about software delivery has proven it wrong.
The Standish Group’s CHAOS data tells the same story with numbers: only 31% of software projects finish successfully. The rest are challenged or canceled. But the revealing pattern isn’t the headline failure rate. It’s what happens inside the “challenged” projects. They don’t fail at the beginning. They stall at the end.
Every product manager has lived this. A feature moves through design, through sprint planning, through the first few rounds of development, and then enters the zone: that persistent state where it’s “almost done” and stays almost done for weeks. The standard explanation is that developers are bad at estimating. That explanation is incomplete. The 90% done trap is, more often than not, a product management problem.
The Spec Described the Happy Path
Most PRDs and user stories describe what happens when everything works. The user clicks the button, the data saves, the confirmation appears. Developers can build that path quickly because the requirements are clear.
The remaining 10% is everything else: error states, empty states, edge cases, permissions conflicts, loading behavior on slow connections, what happens when a user navigates away mid-process, how the feature interacts with three other features nobody thought to test together. A 2026 survey by Refactoring.fm found that only 27% of engineers begin work with clearly defined problems and success criteria. The other 73% discover the real scope as they build.
This is not an engineering failure. Engineers discover complexity because the specification didn’t account for it. The PM who writes a story that says “user can export data to CSV” and calls it done has described one day of work surrounded by five days of undefined work. What columns? What date formats? What happens when the dataset exceeds 100,000 rows? What if the export runs during a scheduled maintenance window? Each answer spawns more questions, and each question adds time that the original estimate never included.
Daniel Kahneman and Amos Tversky identified this dynamic as the planning fallacy in 1979: people estimate based on the inside view (how they imagine the work unfolding) rather than the outside view (how similar work has actually gone in the past). In a study by Buehler, Griffin, and Ross, students predicted they’d finish their theses in 33.9 days. Their most pessimistic estimate was 48.6 days. The actual average: 55.5 days. PMs make the same mistake every sprint. The spec describes the plan; the plan describes the best case.
“Done” Was Never Defined
Across dozens of teams I’ve worked with in operations and fractional COO engagements, I’ve watched the same failure mode repeat: the feature is code-complete (the developer considers the logic finished) but nobody agreed on what “done” means for this specific feature.
Does “done” include QA sign-off? Documentation updates? Load testing? Accessibility review? Deployment to staging? A data migration script? Updating the API docs?
ProductPlan’s research on agile practices identifies the definition of done as one of the most frequently skipped collaborative steps in sprint planning. When it’s skipped, the PM and the developer carry different assumptions. The developer marks the task as 90% complete because the code works in their local environment. The PM discovers that 90% doesn’t include everything needed to ship.
The fix requires the PM to do work upfront. Before any sprint, the team defines “done” for each significant feature: the specific checklist of deliverables required before that feature can go to production. Not a generic poster on the wall. A specific list for this feature, written on this ticket.
Progress Reporting Hides the Problem
The third contributor is how teams report progress. When a developer says “I’m 90% done,” they’re measuring effort completed, not effort remaining. Those are wildly different numbers.
If you’ve completed 90% of the known work and there’s still unknown work ahead, your actual completion might be 60%. But nobody says “I’m 60% done” when they’ve checked off nine of ten planned subtasks. The reporting mechanism itself is misleading because it tracks known work, not total work.
The 2024 DORA State of DevOps research found that elite-performing teams (roughly the top 15% surveyed) don’t lean on task completion percentages. They measure lead time: the elapsed clock time from code commit to production deployment. Lead time captures all the edge cases, QA cycles, and deployment prep that percentage-complete ignores. It measures the actual distance between “building” and “shipped.”
In my fractional COO work, I push for a specific replacement in daily standups: instead of asking “what percentage is done?” ask “what is the next thing that has to happen before this ships?” That question surfaces the real remaining work. A developer who says “I need to handle the error states for three API failure modes, then it goes to QA” is giving you actionable information. A developer who says “it’s about 90% done” is not. A delivery confidence check mid-sprint catches some of these gaps, but the goal is to prevent them at the start rather than manage them once they’ve already slowed the team down.
Closing the Trap
The 90% done trap closes when the PM takes ownership of three things before the sprint begins, not after the stall.
Write the edges into the spec. Describe error states, empty states, and integration boundaries alongside the happy path. If you don’t know the edge cases, that’s a discovery question worth answering before development starts.
Define “done” per feature, not per team. “Code complete” is not “shippable.” Write the specific checklist: QA, load test, docs update, feature flag configuration, monitoring alert setup. Put it on the ticket.
Replace percentage with sequence. Stop asking how done something is. Start asking what has to happen next. The answer reveals whether you’re one task from shipping or twelve.
Cargill’s joke from 1985 was funny because it was true. Forty years later, it’s still true for teams that let the last 10% surprise them. The teams that ship predictably aren’t the ones with better engineers. They’re the ones whose PMs did the unglamorous work of defining what “done” actually meant before anyone started building.