A customer has found an export setting that does not match the help article. Who owns the outcome for this feature now?
I own the service code, but I do not own the customer workflow or the help content. We should separate those responsibilities.
Sales is still discussing it with prospects, so we need a named contact for questions. We cannot keep routing them through the old launch channel.
It shipped before we agreed on an outcome or a review date. That is probably why it disappeared from planning after launch.
Support has a spreadsheet called export things with fourteen tabs. It contains the current issues, but no owner and no retirement criteria.
Let us name the outcome, the accountable owner and the review date. The person who launched it is not automatically the person who owns it today.
I will write the ownership note and a retirement trigger today. Tom owns the service, Elena owns the support workflow, and Maya will review the outcome next month.
Every product company has a feature that arrived as a strategic priority and now survives like an adult child who still receives post at the family home.
Ours was Export Studio.
At launch, Export Studio had a countdown, a customer webinar and a video in which rows of data flew gracefully into a file. Victor posted three rocket emojis. Jules called it a commercial unlock. Maya wrote a launch note containing the phrase โjust the beginning,โ which was accurate in a way she did not yet understand.
Six months later, Elena found the beginning in a support spreadsheet called export things FINAL v8 actually-final.xlsx.
The customer issue seemed small. A saved export sometimes inherited an old permission rule. Tom opened the code and discovered three generations of implementation, two scheduled jobs and one comment reading temporary until migration, dated before Bea joined the company.
Maya searched the roadmap. Export Studio was not there.
She searched the team objectives. Also not there.
She searched Slack and found the launch party.
The feature had not disappeared. It had simply moved from the organisation chart into everybodyโs peripheral vision.
The afterlife begins at launch
Launch ownership is temporary by design. It coordinates a moment: readiness, rollout, communication, incidents and the first customer reactions. Product ownership is the continuing series of decisions that begins when the 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 the documentation honest? Who can remove it?
In Export Studio, each question had a different answer and none of the answers knew they were in a relationship.
Tomโs team technically operated the service. Elenaโs team handled customer confusion. Julesโs team included it in commercial conversations. Maya remembered why it existed. Data owned a dashboard whose event names no longer matched the interface. Security had reviewed version one, but nobody was sure whether version three still satisfied the assumptions.
This is how a feature becomes an orphan without anybody abandoning it. Everyone keeps one small promise. Nobody owns the whole consequence.
Team Topologies describes stream-aligned teams as teams aligned to a flow of work and value rather than a temporary project. That idea matters here because durable ownership follows the customer or business outcome more naturally than the launch org chart. A feature needs a home in the ongoing system, not the name of whoever ran the project plan.
Victor asked the obvious executive question: โWhich team owns Export Studio?โ
Four people answered at once, each using a different noun.
Engineering owned the service. Product owned the roadmap area. Customer Success owned the escalation. Platform owned the job scheduler. Sales owned the opportunity, which is commercial language for being able to create urgency without necessarily receiving the pager.
Victor wrote all four answers down. This was not agreement, but it was the first accurate map.
A feature is an inventory of promises
Teams talk about features as interface and code. Customers experience them as promises.
Export Studio promised that data would remain portable. It promised that a saved configuration would behave predictably. It promised that support could explain failures. It promised that permissions would survive a schedule. It promised Sales a line in a demo and Legal a set of controls that had been true when the review occurred.
The inventory grows even when usage is low. In fact, low usage can make a feature harder to maintain: fewer people notice degradation, less evidence exists to justify investment, and the remaining users may depend on it in unusually important workflows. The feature becomes simultaneously unimportant and impossible to remove.
Teams often call all of this technical debt. Some of it is product debt: unresolved questions about audience, policy, purpose and end-of-life. Refactoring cannot answer whether a promise should still exist.
Elena opened the support spreadsheet. One tab was called โknown weirdness.โ Another was โworkarounds that work unless scheduled.โ The final tab was โquestions for Product,โ created seven months earlier and apparently designed as an archaeological message.
Maya felt the particular guilt of seeing your past self described in a column heading.
One lightly used feature, comes with obligations
- Support answers and customer workarounds
- Analytics definitions from two interface generations
- Permission assumptions last reviewed at launch
- A commercial promise and no retirement condition
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 provides a useful ownership test: which current objective would make this feature worth improving? Which team outcome would worsen if it failed tomorrow?
If nobody can connect a feature to an outcome, the organisation has learned something important. It 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 neutral. It is a decision made through neglect.
Export Studio originally aimed to reduce manual reporting work for enterprise administrators. Nobody had checked that outcome after launch. The dashboard celebrated export creation, not whether reporting work decreased. Customers had created more exports, partly because failed schedules had to be recreated. By the launch metric, the feature was thriving. By Elenaโs Tuesday, it was reproducing.
The team chose a new home based on the outcome, not the code. Mayaโs group would own the customer behaviour and retirement decision. Tomโs platform partners would own service reliability with an explicit interface between the two. Elena would no longer be the unofficial memory system, though she retained veto power over any documentation claiming the feature was โintuitive.โ
This did not magically create capacity. Ownership is not a resource spell. It made the trade-off visible enough to enter planning instead of arriving as surprise work.
The retirement conversation everyone postpones
Removing a feature is emotionally harder than not building it. Existing users are visible; the opportunity cost of maintenance is scattered across calendars. 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? 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 what makes the change survivable.
The goal is not aggressive deletion. Keeping a feature forever because nobody owns the removal decision is not customer care either.
For Export Studio, retirement was premature. The outcome still mattered, usage was meaningful and the permission bug was fixable. But the team removed two obsolete modes, migrated saved schedules and wrote down a review trigger: if maintenance exceeded a threshold without corresponding customer value, the feature would return to an explicit investment decision.
The launch page stayed online. The rocket emojis remained in Slack, preserved like cave paintings from a more optimistic civilisation.
A small ownership contract
Before release, write down five things:
- The outcome the 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 fits on one page. Its value is not administrative completeness. It prevents the organisation from treating launch as the end of responsibility.
It also changes planning language. Instead of โwe can always clean it up later,โ teams must name who โweโ is, what โcleanโ means and which future priority will make room. The sentence becomes less comforting and more honest.
At 17:40, Maya posted the ownership note. Tom fixed the permission inheritance. Elena closed the customer loop. Jules updated the demo language so it no longer promised the behaviour of a future version.
Nobody organised a re-ownership party. There was no video. Stewardship has poor launch marketing.
The next morning, however, the spreadsheet called export things gained a final tab: โArchive.โ Elena moved thirteen old workarounds into it and renamed the file Export Studio โ support log.
It was the most meaningful product rename of the quarter.
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 deck disappears? If the answer is โthe team,โ name the team. If the answer is โweโll see,โ you are not shipping flexibility. You are opening a small account with future confusion.
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 it without forming a temporary committee?
- What support, data, security and commercial promises did its launch create?
- Which feature has no current objective but remains too 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. The gossip says ownership is bureaucracy. The evidence says it is organisational memory with a name attached.