What a Zombie Feature Actually Is
A zombie feature is a product element that appears to exist for users but primarily serves the company. It’s not quite dead, because dead features get removed. It’s not quite alive, because it isn’t actively developed or genuinely useful. It occupies a third state: maintained just enough to influence behavior, never enough to actually work well.
This is different from abandonware or technical debt, though it can wear those disguises. Technical debt is code that’s become a burden through neglect. A zombie feature is code that’s been deliberately left in a particular state. The distinction matters because intent determines what you can do about it.
The clearest example most developers will recognize is the export function that’s always been slightly broken. It works just well enough to prevent users from citing it as a failure in support tickets, but not well enough to actually complete a migration away from the platform. That’s not an accident. Someone, somewhere, made a resource allocation decision that kept that feature in exactly that state.
The Architecture of Deliberate Friction
To understand how zombie features are built, think about how a feature team actually operates. Features get resourced based on a combination of user demand metrics, revenue impact, and strategic priority. A feature that’s heavily used but whose improvement would reduce lock-in will consistently lose in that prioritization game.
The engineering reality is that keeping something broken in a specific way requires ongoing work. APIs change underneath old features. Dependencies get updated. If a feature is truly abandoned, it stops working entirely within a few release cycles. The fact that many features stay at a consistent level of low-quality functionality for years is evidence of sustained effort, not neglect.
This is where it gets interesting from a systems design perspective. The zombie feature isn’t just sitting there passively. It’s generating data. Every user who attempts the broken export, fails, and returns to the main workflow has just handed the platform a behavioral signal: this user tried to leave and didn’t make it. That signal feeds back into retention models and shapes which users get targeted with re-engagement campaigns, loyalty pricing, or new feature announcements.
Shadow Banning’s Quieter Cousin
Shadow banning, as platforms like Twitter developed it at scale, involves showing users content they posted while hiding it from everyone else. The user believes they’re participating; they’re actually contained. Zombie features operate on a similar principle but in the opposite direction: rather than suppressing output, they suppress exit.
The connection to shadow banning’s playbook is worth sitting with. Both techniques share a core design philosophy: the most effective behavioral control is the kind the user doesn’t recognize as control. A user who knows they’re being blocked will find a workaround or leave in frustration. A user who thinks they’re just dealing with a clunky interface will keep trying, keep adapting, and keep generating value for the platform.
This is why zombie features tend to cluster around specific functional areas: data export, account deletion, cross-platform integrations, and third-party API access. These are the exit ramps of software. Keeping them technically functional but practically painful is one of the more effective retention mechanisms a product team can deploy, precisely because it doesn’t look like a retention mechanism.
How to Spot One in the Wild
From a developer’s perspective, zombie features have a distinctive fingerprint in codebases and in user-facing behavior.
In the code: look for functions with minimal test coverage despite handling critical user data. Look for API endpoints that haven’t been updated to match current data schemas but are still publicly documented. Look for UI components that haven’t been touched in years but haven’t been deprecated either. These aren’t bugs waiting to be fixed. They’re territories that have been deliberately left unmapped.
In user behavior: watch what happens when someone tries to leave. If the process requires multiple non-obvious steps, generates confusing error states, or produces outputs that aren’t compatible with common alternatives, that’s worth examining. The question to ask is: does this complexity serve any legitimate technical purpose, or does it only serve the platform’s retention interests?
A useful mental model is to imagine you’re doing a code review for the feature. Ask yourself: if a junior developer submitted this code, what would you tell them to fix? If the answer is obvious and the fixes are straightforward, but the feature has stayed broken for years anyway, you’re probably looking at a zombie.
This connects directly to how companies hide their best features for economic reasons. Zombie features are that logic applied in reverse: rather than hiding something valuable, you expose something useless in a way that still extracts behavioral data.
The Consent Problem Nobody Talks About
There’s a meaningful argument that zombie features cross an ethical line that’s distinct from ordinary dark patterns. A confusing interface might be bad design or might be intentional manipulation, but both cases involve something that visibly happens to the user. The user can point at the confusing button and say “this is hard to use.”
Zombie features operate below that threshold of visibility. The user’s mental model of the product includes a working export function. They’ve decided to stay on the platform in part because they believe they could leave if they wanted to. Their autonomy feels intact. If the exit feature is deliberately broken, that belief is false, but the user has no way to verify it without attempting the exit, which is precisely the high-friction thing they’re trying to avoid.
This is why regulatory frameworks like GDPR’s data portability requirements are worth paying attention to from a technical standpoint. When regulators require that export functions actually work within specific time and format constraints, they’re implicitly acknowledging that the alternative is a category of product design that’s standard practice and actively harmful.
The Product Manager’s View
I want to be fair here: not every understaffed feature is a zombie, and not every product manager working on retention is acting in bad faith. Software prioritization is genuinely hard, and there’s always more work than capacity. It would be naive to claim that every broken export function is malicious.
But the pattern becomes harder to explain charitably when you look at which features consistently get deprioritized across an entire industry, and why. The features that stay broken tend to be the ones that would reduce switching costs if they worked. The features that get rapid engineering attention tend to be the ones that increase engagement, add data collection surface area, or introduce new monetization hooks.
That’s not random. It reflects an incentive structure where retention metrics are rewarded and switching cost reduction is never a goal anyone is explicitly asked to optimize for. The zombie feature is often the emergent result of that structure rather than a conscious conspiracy, which makes it no less real and no less worth examining.
What This Means
Zombie features are a category of product design that sits at the intersection of technical architecture, behavioral economics, and corporate incentives. They persist because they work, because they’re invisible, and because no organizational structure actively rewards removing them.
For developers: learn to read the absence of effort as information. A feature that has stayed broken in the same specific way for years is telling you something about priorities.
For users: the features worth testing before you commit to a platform are the exit features. Import works great at signup. Export is where you learn what the company actually thinks of you.
For regulators: technical compliance with data portability requirements is necessary but not sufficient. A feature that exports your data into a proprietary format after a 72-hour wait is technically compliant and functionally a zombie.
The honest summary is this: software that appears to serve you while primarily serving the company’s retention interests is not a glitch or an oversight. It’s a design decision that someone made, that someone is actively maintaining, and that someone benefits from every day you stay.
