Owning It in Production
What changes once real people depend on it: incidents as product events, the support loop as a source of truth, technical debt as a product decision with a cost, deprecating what nobody uses, on-call for people who ship features, and postmortems that change something.
An incident is something that happened to customers, not to a server. Who was affected, what did they lose, what do we tell them and what do we owe them — the fix is one line of that response.
The support queue is the cheapest user research you have: real people, describing real problems, unprompted, every day. Build the loop from ticket to change and back to the person who wrote it.
Debt has a cost you can name in the features it slows down and the incidents it causes. Argue for paying it in those terms — against the roadmap — not by asking for a refactor sprint.
Removing something is a feature with its own users, launch and success measure: announce it, measure who still depends on it, remove it, and say what you learned about why it did not work.
If you shipped it, you own the page. That means alerts on what customers feel, a runbook that makes the page short, and treating every page as a signal about the product, not only about the system.
A postmortem is worth what it changes. One change that would have prevented this incident, owned by a named person, with a date — instead of ten action items that quietly expire.