Evernote launched in 2008 as a simple capture tool. It eventually added notebooks, stacks, tags, reminders, templates, integrations, AI, and a business plan with shared workspaces. Bear launched as a minimal markdown editor. Notion started as a simple linked-page tool and became a relational database system. The direction is never reversed. Here's why.
The mechanism: asymmetric cost of saying no
Software product teams face a structurally asymmetric decision for every feature request. If you add a feature that 15% of users want, those users are satisfied. The 85% who didn't want it are theoretically unaffected — the feature exists and they can ignore it. If you decline to add the feature, the 15% are unsatisfied and some percentage of them leave. The app that ships a competing feature captures them.
The rational response to this asymmetry is to add features. Almost every time. Because the cost of saying no (users who leave for a competitor) is visible and measurable, while the cost of saying yes (increased complexity) is invisible and diffuse. No user writes a support ticket saying "your app is 3% harder to understand than it was last quarter." Users absolutely write support tickets saying "Competitor X has recurring tasks and you don't."
This is the ratchet: features are easy to add, impossible to remove. Complexity increases monotonically. The only direction the dial turns is up.
Evernote: a case study in the full arc
In 2008, Evernote did one thing: it captured notes across devices and made them searchable. The product was a revelation. Nothing else did this reliably. Phil Libin, the CEO, described it as a "memory extension."
By 2012, Evernote had notebooks, shared notebooks, tags, reminders, attachments, web clipping, Skitch integration, Penultimate integration, business accounts, and a marketplace. By 2016, it had templates, presentation mode, context (surface related content), Work Chat, and integrations with Salesforce, Google Drive, Microsoft Teams, Slack, and dozens of others. By 2023, the company had been through three CEOs, laid off most of its staff, moved its operations to a European holding company, and added AI features to justify a price increase.
Each individual addition made sense. At the margin, each new feature was a reasonable response to user demand. In aggregate, they produced an app that original users found unrecognizable — slow, bloated, expensive, and oriented toward enterprise use cases that bore no resemblance to the individual note-taker the product started with. The 2023 version of Evernote would have been unthinkable as a 2008 pitch. It arrived incrementally, one reasonable decision at a time.
The user heterogeneity problem
A notes app with 10 million users contains multitudes. Some users want the app to be a writing environment. Some want it to be a project management tool. Some want it to be a personal wiki. Some want it to be a CRM. Some want it to do all of these. The loudest users — the ones who write detailed feature requests, who comment on forums, who evangelize the app to others — tend to be power users with complex needs.
The silent majority of users have simple needs: open the app, capture something, find it later. These users don't write feature requests. They don't have opinions about database views or property types. They just use the app until it becomes too complicated to use comfortably, and then they stop using it.
Product feedback loops therefore systematically oversample power users and undersample simple users. Features are built for the minority that shouts and the majority that leaves quietly is never counted in the product decision.
Venture capital and the growth imperative
Evernote raised $290 million in venture funding. Notion raised $343 million. When a software product raises that amount of money, it acquires an obligation to grow at a rate that justifies the valuation. Individual users paying $10/month can only sustain so much growth. Enterprise contracts paying $20-50 per user per month offer a path to the numbers required.
Enterprise users have different needs than individual users. They need admin controls, audit logs, SSO, permission management, SLA guarantees, compliance features, and integrations with enterprise software stacks. Building these features for enterprise users changes the DNA of the product. The UI gains administrative surfaces that individual users don't need. The mental model becomes more complex to accommodate team structures that solo users don't have.
The funding round is therefore a forcing function toward complexity. Not immediately, but inevitably. The money implies a growth strategy, the growth strategy implies enterprise, enterprise implies features, features imply complexity. The ratchet has a funding crank.
The features that can't be removed
Once a feature exists, removing it breaks workflows. Users who built processes around a feature — even a rarely-used one — will notice its removal immediately. Removal generates complaints disproportionate to the feature's actual usage. The engineering team therefore cannot clean up the feature surface even when they know it should be simpler. Every removal is a political battle. Every addition is a small addition. The asymmetry is permanent.
Some companies try to manage this with progressive disclosure — hide complex features behind menus so simple users don't encounter them. This works up to a point. But features affect more than UI surfaces. They affect performance (more code to load), mental models (more things the app might do), and onboarding (more to explain). Hiding a feature doesn't eliminate its cognitive weight. It just defers the encounter with it.
The only known escapes
There are a small number of exceptions to the complexity ratchet in software history. They have things in common.
The first pattern is decisive leadership with the authority to say no against user demand, consistently. The best example is the original iPhone — Steve Jobs famously refused to add a physical keyboard despite enormous user demand, and was vindicated. But this requires a specific kind of founder authority that is rare and time-limited.
The second pattern is a narrow, specific design philosophy that serves as a filter for feature requests. "We don't add features that aren't used every day" is a concrete rule that can be applied consistently. It tends to produce software that remains simple longer, but it also requires accepting user churn from people whose use case didn't make the cut.
The third pattern is a new entrant that starts simple, gains users while incumbents are complex, and then — if the ratchet catches them — eventually becomes complex too, at which point another new entrant starts the cycle again. The simplicity of new entrants is structural, not principled. Bear was simple when it launched in 2016 because it was new and hadn't accumulated a decade of feature requests. What it does with the next decade remains to be seen.
What "we won't do" means in practice
- Feature requests are evaluated against daily use, not theoretical utility — if it doesn't get used every day, it probably doesn't belong
- Power users are listened to but not deferred to — a vocal minority with complex needs does not define the product for the majority with simple needs
- Enterprise is not the growth strategy — enterprise features imply enterprise complexity, which breaks the product for individuals
- Shipping nothing is a valid quarter — the ratchet only turns if you turn it