Users only care about 20% of your application

How much of large applications people actually use

• Several commenters argue even 20% is too high for tools like Word/Excel; estimates of 1–2% are floated.
• Many “Word users” only change fonts and sizes; features like styles, headings, and advanced layout are largely unknown or avoided.
• Some say these advanced features are also flaky or hard to use correctly, which pushes people back to ad‑hoc formatting.

Training, cognition, and fear of breaking things

• Many users never received proper training; companies talk about “re-training” when basic training never happened.
• Switching from Microsoft Office to open‑source suites caused long delays in some public offices because staff couldn’t map old habits to new UIs.
• Several comments stress teaching fundamentals (communication, formatting, concepts like orchestration) instead of tool‑specific skills.
• Fear of “breaking something” discourages exploration; modern systems often make rollback and discoverability of changes difficult.

Different users, different 20%

• A recurring point: each user’s 20% is different, especially in complex apps like Office or enterprise SaaS.
• Attempts to cluster users by feature usage sometimes showed near‑random patterns—everyone uses a different subset beyond the basics.
• This makes feature pruning risky; “rarely used” functions may be deal‑breakers for specific users or act as signals of capability (e.g., 3D bone rigging).

Interoperability, Unix philosophy, and modularity

• Some see this as an argument for small, composable tools (Unix style) rather than bloated applications.
• Others note that even Unix tools have their own unused 80%, and integration, discoverability, and fault tolerance become the hard problems.
• There is praise for platforms and editors (VS Code, Emacs, Neovim, suckless tools) that provide a minimal core plus extensibility, though some dispute whether they truly embody 80/20 modularity.
• A strong thread criticizes “applications” as silos that resist being part of pipelines, contrasting them with shell utilities.

Product, business, and enterprise implications

• Modified Pareto ideas appear: heavy users consume disproportionately, but the “bottom 80%” still matter enough to design for.
• For MVPs, commenters argue lack of features is rarely the adoption problem; messaging, fit, and perceived value usually matter more than sheer feature count.
• Enterprise software is described as dominated by “hygiene” and compliance features (SSO, permissions, logging, certifications, data policies, etc.) plus many one‑off features demanded by big customers.
• This leads to roadmaps driven by sales conversations, tech debt, burnout, and broad agreement that features are easy to add and very hard to remove.

Developers, telemetry, and OSS/hobby projects

• “Desire paths” and usage metrics are seen as crucial to decide what to improve or cut, but also likened to inescapable telemetry.
• Hobbyist and open‑source developers report reluctance to release tools because they don’t want to build or maintain the unused 80%, and sometimes face hostile demands for features they don’t need themselves.

Lineage and examples

• Multiple comments note the article closely echoes earlier writing on bloat and the 80/20 myth, particularly classic software‑engineering essays.
• Spreadsheets are cited as a counterexample: a complex, power‑user‑friendly mass‑market tool that many doubt could be created in today’s simplification‑obsessed culture.