On the 80/20 rule that isn't one – and on the fact that the part which gets cut first is the part that decides how the product turns out.
The short version: "The first 80 percent takes 20 percent of the time" is folklore. Nobody measured it. The phenomenon behind it is nevertheless evidenced from three independent directions: defects cluster (roughly 20 percent of files hold 80 percent of the bugs), estimates are systematically optimistic (the planning fallacy), and IT projects overrun with a fat tail — one in six by 200 percent. What matters in practice is something else: the part that gets cut first is exactly where error cases, edge cases and finishing quality live. Cutting it doesn't save the work. It moves it into operations.
There's a sentence you hear in project meetings roughly every two weeks, and it's always wrong:
"We're 90 percent done."
Translated, it means: the visible part works. The rest is small stuff.
And then the small stuff takes four months.
This is the last piece in a series about forms, error states, status emails, cancellation routes, language and accessibility. Six pieces about things that routinely fall off the end of projects. This one isn't about another thing. It's about the mechanism that makes all of them fall off the end together.
1. First, the Fact-Check, Because the Rule Isn't One
I'm starting with a correction, because otherwise I'd be working with an argument that can be dismantled in three sentences.
The 80/20 distribution itself is real. Vilfredo Pareto observed land distribution in Italy in 1906; Joseph Juran turned it into the "vital few and trivial many" in the 1940s. As a distribution pattern it's well documented across many domains.
The sentence "the first 80 percent takes 20 percent of the time" is not. Nobody has collected that data. There's no study, only a rule of thumb — and its best-known version was explicitly a joke. The ninety-ninety rule is attributed to Tom Cargill of Bell Labs and was popularised by Jon Bentley in his 1985 column in Communications of the ACM:
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.
The punchline is in the sum: 180 percent. Bentley filed it under "Rule of Credibility."
So anyone arguing "according to the 80/20 rule" in a meeting loses the moment someone asks for the source. What you can use instead is considerably better: three independent, defensible findings that together explain the same thing.
2. Finding One: Defects Don't Distribute Evenly
This is where Pareto genuinely holds.
Analyses of large industrial codebases — by Ostrand and colleagues, and by Hamill, among others — repeatedly show that around 20 percent of files contain roughly 80 percent of defects, and that within those files the defects cluster again. That isn't anecdote, it's been replicated several times.
Two practical consequences follow, and both are usually understood by half:
First, evenly distributed effort is waste. Test every file, screen and flow with equal intensity and you spend most of your effort where there's nothing. That's the legitimate, useful application of Pareto: as a prioritisation tool.
Second, Pareto isn't an excuse. "80 percent is enough" doesn't mean you can leave out 20 percent of the work. It means you know where to look first. The difference between those two sentences is roughly the entire content of this article.
3. Finding Two: Estimates Aren't Imprecise, They're Skewed
If estimates were merely imprecise, you'd land above as often as below. But you land below almost every time. That has a name and a research history.
Kahneman and Tversky called it the planning fallacy and explained it through the difference between the inside view (planning from the details of your own undertaking) and the outside view (looking at how comparable undertakings actually turned out).
The best-known evidence comes from Buehler, Griffin and Ross, published in 1994 in the Journal of Personality and Social Psychology. Thirty-seven students were asked to predict when they would submit their thesis. On average they predicted 33.9 days. They actually took 55.5 days — around 64 percent longer. Only about 30 percent finished by their own stated date.
And here's the part I most enjoy quoting in project meetings: the same people were also asked when they'd be finished if everything went as badly as it possibly could. That catastrophe figure averaged 48.6 days. Reality was still worse.
Remember that for your next planning session: your worst case is, statistically, the optimistic one.
A follow-up study by the same team is particularly awkward. Participants were made to write down beforehand how they had performed on comparable tasks, and were explicitly told to take that into account. Their estimates did not improve. Knowing about it doesn't cure it.
4. Finding Three: It Isn't the Average, It's the Tail
Which brings us to the largest available dataset.
Bent Flyvbjerg and Alexander Budzier analysed 1,471 IT projects. Average cost overrun came to 27 percent — which sounds manageable. But the average conceals the actual risk: the distribution has a fat tail. One in six projects was a "black swan" with an average cost overrun of 200 percent and a schedule overrun of nearly 70 percent. The study at arXiv.
An accompanying analysis by McKinsey with the University of Oxford across more than 5,400 large IT projects landed in similar territory: on average 45 percent over budget, 7 percent over schedule — and 56 percent less value than predicted.
That last figure is the most interesting and the least quoted. It isn't just that projects get more expensive. It's that less comes out of them than planned. And in practice, less coming out means things were left out.
Which brings us to the actual subject.
5. Why the Last 20 Percent Is Different From the First 80
The reason the closing stretch is so unpredictable isn't its size. It's that it's made of something else.
The first 80 percent is the happy path. Known requirements, clean test data, a cooperative user, a working interface, the standard case. That's the part you can describe in advance — which is why it's in the concept, why it can be estimated, and why it goes quickly.
The last 20 percent is everything else. Edge cases. Error states. Real data quality instead of sample data. Integration with a system that behaves differently from its documentation. Accessibility. Performance under load. Migration of legacy records. Legal special cases. The question of what happens when someone has two surnames, lives abroad, or closes the browser mid-flow.
These things have one thing in common: you can't estimate them, because you don't know them in advance. That isn't a planning weakness. That's the nature of the thing. You find edge cases by building, not by planning.
So "we're 90 percent done" is almost always a statement about the happy path — and the happy path isn't 90 percent of the work, it's 90 percent of the visible work.
6. Why It's Exactly This Part That Gets Cut
Now the organisational core, which is what actually interests me about the topic.
The last 20 percent doesn't get cut because someone considers it unimportant. It gets cut because it comes last in time. By the point you'd have to decide about it, the budget is spent, the date is fixed, and the question is no longer "what's important?" but "what can we still manage?"
That's the difference between a decision and a condition. Nobody decided not to write the error messages. There simply wasn't a Friday left.
Three amplifiers make sure it happens again every time:
The progress bar lies. Progress gets measured in features, because features are countable. Error cases, edge cases and quality aren't. So a project looks great in week 12 and isn't.
The visible wins every trade-off. In a demo you see the new screen. You don't see the error message you didn't trigger, or the status email nobody has received yet.
The costs land somewhere else. This is the thread running through the whole series. What gets saved here reappears later in support, in rework, in chargebacks, in training, in warning letters, in operating costs. Different cost centre, different quarter, different department. Nobody connects the two numbers.
So cutting the last 20 percent isn't a saving. It's a transfer — out of a budget that's visible and into several that aren't.
7. Where 80 Percent Genuinely Is Enough
So this doesn't turn into a sermon on perfectionism: there are cases where 80 percent isn't only enough, it's correct.
Prototypes. A prototype should answer a question, not be a product. Design error states there and you're burning money.
Internal explorations and tests. Anything thrown away once the learning is banked.
First market trials with a small, informed user group that knows it's standing on a building site.
Features affecting a small minority — provided you've checked it really is a small minority and the majority can get through without them.
So the mistake isn't the principle. The mistake is misassignment: 80 percent in a prototype is efficiency, 80 percent in a payment flow is an operating risk. The question that needs asking in the project isn't "is 80 percent enough?" but: "who carries the missing 20 — us or the user?"
For the prototype: us. For the application form: the user. And they pay in a currency that arrives back with you as support costs and abandonment.
8. What to Do About It
Four measures, in ascending order of discomfort.
1. Name the last 20 percent before you start. Not "buffer" — a list: error states, empty states, edge cases, accessibility, migration, copy, status communication. What has a name can be defended. What's called "buffer" gets cut first.
2. Pull it forward where you can. Not everything can be pulled forward — but copy, error messages, empty states and accessibility can be built in parallel with the happy path. Same amount of time, spent at a point where there's still budget.
3. Definition of done instead of feature counting. A feature is finished when the error case is designed, the copy is written and keyboard operation has been checked. Otherwise you're counting progress that doesn't exist.
4. Reference class forecasting. Flyvbjerg's own remedy for the planning fallacy, and the only approach with a defensible evidence base: don't estimate from inside the project, estimate from outside. How long did your last five comparable undertakings actually take? Not how long they were planned for — how long they took. That number is your baseline, and then you adjust upward, not down.
Point four is uncomfortable, because it requires somebody to write down your own track record. In most companies that list doesn't exist, and that's no accident.
Why You Can Take My Word for It
I'm Tobias Adam, a freelance UX designer in Hamburg, more than ten years in digital product development.
I learned the craft agency-side, including at Jung von Matt and deepblue networks. I've worked for BMW, Audi, FIFA, Union Investment, Vodafone, OBI and Deutsche Messe, among others. Over 20 awards, including Webby, ADC and Cannes.
What I've learned in that time: I'm rarely the first to notice the last 20 percent — but often the first to write it down. In regulated flows like the VisualVest account opening in the Union Investment orbit that's obvious, because mandatory disclosures, identity verification and review periods sit precisely in that part. In other projects it only surfaces when someone asks what actually happens when something goes wrong. Asking that in the concept phase costs an hour. Asking it after launch costs a quarter.
Today I work freelance and together with HC Merkle as intro.team — two freelancers for the phase where an idea becomes a testable product: concept, UX, UI, prototype, user testing. Short cycles, senior staffing, no agency apparatus.
The Short Version
- "The first 80 percent in 20 percent of the time" is not a study, it's a rule of thumb — and in its best-known form, a joke.
- The phenomenon behind it is evidenced anyway, from three independent directions.
- Defects cluster. Around 20 percent of files hold 80 percent of the bugs. Use that to prioritise, not to omit.
- Estimates are skewed, not imprecise. And your worst case is statistically the optimistic one.
- Knowing doesn't cure it. Even people who know their own history keep estimating optimistically.
- The risk isn't the average, it's the tail. One in six IT projects overruns by 200 percent.
- The last 20 percent is made of different material: edge cases, errors, real data, integration. Unplannable, because unknown in advance.
- It doesn't get cut, it's simply what's left over. That's a condition, not a decision.
- Cutting saves nothing, it transfers — into support, rework, operations.
- The right question isn't "is 80 percent enough?" but "who carries the missing 20?"
And with that the series closes. Forms, error states, status emails, cancellation routes, language, accessibility: those aren't six different topics. That's the same last 20 percent, six times over.
Previously in this series: forms, field count and smart defaults — B2B software and internal tools — error states — the last mile — cancellation flows — bureaucratic and legal language — accessibility.
Sources and Further Reading
- Jon Bentley: Programming Pearls – Bumper-Sticker Computer Science, Communications of the ACM 28(9), 1985 (origin of the ninety-ninety rule, attributed to Tom Cargill) – doi.org
- Buehler, Griffin & Ross: Exploring the "Planning Fallacy", Journal of Personality and Social Psychology 67(3), 1994 – web.mit.edu
- Flyvbjerg & Budzier: Why Your IT Project May Be Riskier Than You Think, Harvard Business Review 2011 – arxiv.org
- Bloch, Blumberg & Laartz (McKinsey / University of Oxford): Delivering large-scale IT projects on time, on budget, and on value, 2012
- Ostrand, Weyuker et al. and Hamill & Goseva-Popstojanova: studies on defect distribution in large codebases
- Vilfredo Pareto (1906) and Joseph M. Juran: "vital few and trivial many"