Does anyone know who owns the export feature now?
Depends whether you mean the code, the customer complaints, or the sentence in the launch announcement.
Support has a spreadsheet called export things. It has fourteen tabs and no owner.
So we shipped a feature, celebrated the feature, and forgot to invite it to the next planning cycle.
Let us name the team responsible for its next outcome, not just the team that touched it last.
Every product team has one. The feature that appeared during a launch, solved an urgent problem, and then became everybody’s least favourite relative.
Nobody hates it enough to remove it. Nobody loves it enough to own it.
What we know
Features create obligations. They need support answers, analytics, documentation, accessibility review, edge-case decisions, and someone who notices when the world changes underneath them.
The launch plan usually has an owner. The afterlife does not.
What we infer
The orphan feature is rarely a single team’s failure. It is a system that rewards visible delivery more than quiet stewardship. Shipping produces a screenshot. Maintenance produces a slightly less bad Tuesday.
So the feature survives on borrowed time and borrowed people. A PM remembers it during planning. An engineer fixes it during an interrupt. Support invents a workaround. A customer finds the edge case.
Launch ownership is not product ownership
Launch ownership is temporary by design. It coordinates a moment: scope, readiness, communication, rollout and the first wave of incidents. Product ownership is different. It covers the continuing decisions that begin when the launch checklist ends.
Who can change the behaviour? Who watches whether the feature still creates value? Who decides when a compatibility promise is no longer worth its cost? Who keeps documentation honest? Who can remove the feature?
When those questions have different answers, that can be healthy. A platform team may operate the service while a stream-aligned product team owns the customer outcome. What matters is that the boundary is explicit and the teams know how decisions cross it.
Team Topologies describes stream-aligned teams as teams aligned to a flow of work and value rather than a temporary project. That idea is useful for orphan features because durable ownership follows a value stream more naturally than a launch org chart. The feature needs a home in the ongoing system, not the name of the person who happened to run the project.
The hidden inventory of obligations
A feature is not only code. It creates a small inventory of promises:
- a customer expects the workflow to remain available;
- support needs a reliable answer when it behaves strangely;
- analytics needs definitions that survive interface changes;
- legal and security assumptions need review as conditions change;
- sales may include it in a commercial story;
- other product areas may quietly depend on it.
This inventory accumulates even when usage is low. In fact, low usage can make it harder to maintain because fewer people notice degradation and less evidence exists to justify investment. The feature becomes simultaneously unimportant and impossible to remove.
Teams often call this technical debt, but some of it is product debt: unresolved questions about audience, purpose, policy and end-of-life. Refactoring cannot answer whether a promise should still exist.
Objectives reveal the missing owner
SVPG’s overview of team objectives argues for giving product teams problems to solve and outcomes to achieve rather than lists of features to deliver. That framing gives ownership a useful test. Which current objective would make this feature worth improving? Which team outcome would worsen if it failed tomorrow?
If no team can connect the feature to an outcome, the organisation has learned something. The feature may be infrastructure that needs explicit service ownership, a contractual obligation that belongs in operational planning, or a candidate for retirement. “Nobody prioritised it” is not a neutral status; it is a decision being made through neglect.
The retirement conversation
Removing a feature is emotionally harder than not building it. Existing users are visible, while the opportunity cost of maintenance remains scattered. A responsible retirement process therefore needs evidence and options.
Start with actual use: who uses it, how often, in which critical journeys and with what alternatives? Then map dependencies and commitments. Speak directly with the people most affected. Decide whether to migrate, replace, narrow or remove. Publish dates only after the team understands the work required to make the change survivable.
The goal is not aggressive deletion. It is honest stewardship. Keeping a feature forever because no one owns the removal decision is not customer care.
A small ownership contract
Before release, write down:
- The outcome this feature is expected to support.
- The team that can change its product behaviour.
- The team that operates its technical service.
- The signals that trigger review.
- The conditions under which retirement will be considered.
This can fit on one page. Its value is not administrative completeness. It prevents the organisation from treating launch as the end of responsibility.
Questions to take back to your team
- Which live feature would cause the most confusion if its original PM left tomorrow?
- Who can make the next product decision about that feature without forming a temporary committee?
- What support, data, security and commercial promises did the launch quietly create?
- Which feature has no current objective but remains too politically awkward to retire?
- If you had to publish an owner and retirement condition today, where would the conversation get stuck?
Choose one neglected feature and write the ownership contract before discussing another roadmap addition. What future confusion are you currently calling flexibility?
My take
Before shipping, ask one unglamorous question: who gets to make the next three decisions about this?
Not who is on the launch project. Who owns the meaning of the feature after the launch deck has disappeared?
If the answer is “the team,” write down which team. If the answer is “we’ll see,” you are not shipping a feature. You are opening a small account with future confusion.
The gossip is that ownership is bureaucracy. The evidence says it is just memory with a name attached.