We’re not building products that make users more capable. We’re building products that make users need us more.
The Cognitive Offloading Problem
When users offload thinking to our products, their brains literally restructure. The "Google effect" (or digital amnesia) showed that when people know information is stored externally, they don’t bother remembering it anymore. They just remember where to find it.
Every feature that does something for users rather than with them creates dependency. Here's a wild fact: the hippocampus, which is the navigation center of the brain, actually shrinks in heavy GPS users. That's not a bug in the product. That's the product working exactly as designed.
We're essentially building products that make themselves indispensable by making users less capable. Sure, it's a great retention strategy, but we're also creating a generation that genuinely can't function without our tools.
The Generation Effect
There's this well-documented principle in learning that says we remember and understand better when we generate answers rather than consume them. Writing by hand beats typing. Solving problems beats watching solutions. Struggling through something beats having it handed to you.
But here's the thing... struggle is terrible for metrics. It increases time-to-completion, raises bounce rates, and frustrates users. So naturally, we remove it.
Every autocomplete, every smart suggestion, every AI-powered solution removes the generation that creates real learning. We're optimizing for satisfaction scores while quietly destroying capability development. This is the product paradox we don't talk about; the better your UX metrics get, the worse your users become at the underlying task.
The Automation Paradox
Aviation learned this lesson the hard way. When autopilot got too good, pilots started losing the ability to fly manually. Now they're required to log regular manual flying hours just to maintain their skills. The better the automation became, the worse human operators got when it failed.
Your product has exactly the same problem.
The more reliable your solution is, the less capable users become without it. When your service goes down, users don't just lose access to your tool, they lose the ability to do the thing at all.
This should completely change how we think about uptime. When you achieve 99.99% availability, users never develop fallback capabilities. Maybe some strategic downtime would actually serve users better in the long term. But try explaining that to your board or even to your users.
The Anti-Scaffolding Problem
Good learning uses something called scaffolding, which is temporary support that gradually withdraws as competence grows. But SaaS products do exactly the opposite. Every update makes things easier. Version 2.0 has more automation than 1.0. The AI update does even more for users. We're building permanent crutches when we should be building temporary supports.
Look at any successful product's roadmap and you'll see the pattern. It's always about doing more for users, never about teaching users to do more themselves. We call this "reducing friction" but what we're really doing is reducing capability.
The business model depends on this, of course. A user who becomes capable doesn't need your subscription anymore. A dependent user is a retained user.
When Systems Fail
People have driven into lakes following GPS. Developers can't code without Copilot or Claude Code. Designers can't design without templates. Writers can't write without AI. I'm generalizing of course, but you get the idea.
This isn't about users being stupid. This is about products being too good at the wrong thing. We've optimized for efficiency over resilience, for ease over education, for metrics over meaning.
The fragility compounds too. Each tool assumes other tools exist. Your product probably assumes users have Google, GPS, autocorrect, and a dozen other cognitive crutches. We're not just building a product anymore. We're building on a stack of dependencies.
The Uncomfortable Truth About Metrics
Every product metric rewards dependency. Think about it.
DAU/MAU looks better if users can't function without you. Retention is maximized when users are helpless without your product. Time in app increases when users can't accomplish tasks independently. NPS scores highest when you've eliminated all user effort.
We've created a system where making users weaker makes our numbers stronger. The incentives are perfectly misaligned with human capability.
The Counter-Argument
Maybe this is all fine though. After all, we don't mourn the loss of memorizing phone numbers. Calculators freed mathematicians to tackle harder problems instead of getting bogged down in arithmetic. GPS enabled exploration rather than killing it.
There's also an equity argument here. Spell-check helps dyslexics. Translation tools help non-native speakers. AI helps those without traditional education access opportunities they couldn't before.
Maybe we're not making users weaker at all. Maybe we're making weak users stronger. Maybe dependency is just specialization by another name.
Maybe this is actually what progress looks like.
Building Better Products
What would products that actually build capability look like? They'd show their work, explaining reasoning rather than just giving answers. They'd teach patterns instead of just autocompleting. They'd build mental maps rather than just navigating.
They'd gradually reduce assistance, like training wheels that adjust over time or language apps that use less translation as you improve (Duolingo is a good example). They'd fail gracefully too. When the tool breaks, users would have enough understanding to continue manually. I dream of error states would becoming teaching moments.
But let's be honest, this is mostly fantasy though. No product builder wants to invest time and energy into products that make themselves unnecessary. No PM wants to optimize for "user graduates from needing us."
A More Practical Path Forward
I don't have all the answers, but here's what we can actually do about this.
If You're Building Products:
Start with optional "training mode" features. When users onboard, don't just show them the easiest path. Build a "learn the underlying skill" mode. GPS apps could have a "build spatial awareness" setting that asks users to predict turns before showing them. Code assistants could have a "teaching mode" that explains what they're generating and why.
Add progressive disclosure of complexity. Start simple, but gradually reveal how things work under the hood. Notion accidentally does this well. You start with basic pages, then discover databases, then formulas. That progression builds real capability.
Create fallback modes for when your AI features fail. Don't just show an error message. Provide a manual option with clear instructions. This isn't just good UX. You're teaching users they're not helpless without you.
Build in competence milestones. Gaming figured this out decades ago. Show users when they've leveled up in capability, not just usage. "You've now written 10 emails without AI assistance" means more than "You've sent 100 emails."
If You're a User:
Pick one tool to reduce your dependence on. Not eliminate, just reduce. If you use GPS for everything, try navigating to familiar places without it once a week. If you use AI for all writing, draft your first paragraphs yourself. These are small acts of independence that add up.
Learn one thing manually that you usually automate. Maybe calculate a tip in your head, remember one phone number, or write one email without assistance. These aren't huge lifestyle changes either, they're just small exercises in maintaining capability.
Try "tool fasting" occasionally. Pick a day or even just an hour to work without your usual digital assists. You'll be frustrated at first, then genuinely surprised at what you can actually do. Your brain should still be braining sometime.
For Products You're Building Right Now:
Add an "explain this" button next to every automated action. Users who want to learn can click it, and users who don't care can ignore it. But the option exists.
Create "graduate modes" for power users. After someone uses your product for X months or after having completed certain core tasks, offer them advanced features that require more understanding. Make capability prestigious, not just ease.
Build reversibility into your features. If your product does something for users, make sure they can see how it was done and could theoretically do it themselves if needed.
The Reality Check
I'm realistic though. Most of this won't happen because the market rewards dependency. VCs fund addiction, not education, and users choose easy over educational every time.
But individual builders can make small choices and individual users can maintain small capabilities. We don't need to reject all convenience. We just need to be conscious about which capabilities we're trading away.
The goal is to recognize the trade-off we're making. We don't have to go back to paper maps, that's not what I'm suggesting here. But, every convenience has a cost in capability. Sometimes that trade is worth it, and sometimes it really isn't.
At least now we're making the choice consciously instead of sliding into helplessness by default.
Start small, pick one capability you want to maintain, and pick one feature you could build differently. The revolution doesn't need to be total. It just needs to begin.