Every company I have worked in or with has at least one: a product, tool or feature that has users, costs money, and belongs to nobody. It sits between teams. It survives on the goodwill of engineers who maintain it in the margins of their real jobs. Nobody can quite remember why it exists, and nobody wants to be the one to decide its future.
These orphans are more expensive than they look — and the cost is not the infrastructure bill.
The hidden bill
An unowned product taxes the organisation in quiet ways. Engineers carry it as background anxiety and context-switching. Security and reliability debt accumulates where nobody is looking. Customers build workflows on something the company has mentally abandoned, which makes every future decision harder. And the team learns a corrosive lesson: that some things here are simply not decided.
Leaving an orphan to rot costs more than either of the honest options: give it a home, or shut it down.
How to make the call
When I take ownership of an orphaned product, I run the same sequence:
1. Find out who actually uses it, and what for. Not the dashboard vanity metrics — the cohort analysis. Somewhere in the usage data there is usually a group of people for whom this thing is genuinely load-bearing. If that group doesn't exist, the decision has largely made itself.
2. Price the three honest options. Commercialise or properly fund it; fold it into another product and migrate the users; or deprecate it with a respectful migration path. Each option gets a real cost estimate, including the engineering time nobody wants to count. "Keep ignoring it" is explicitly not on the list.
3. Decide with evidence, then commit. The worst outcome is not killing a product people love — it is the half-decision where a product is neither funded nor closed. Once the evidence points somewhere, the job is to make that path real: roadmap, ownership, and a date.
A worked example
I did exactly this with an internal security-scanning tool that had started as a side project. The data showed a committed cohort of security practitioners using it daily. We gave it a home, a commercial model, and a roadmap — and it grew into a product used by thousands of customers a month, doubling its entire previous year's usage within months of relaunch. I have written the full story up as a case study.
I have also made the opposite call — deprecating products that could not justify their keep — and done it in a way that let the team stop carrying dead weight and move on to work that mattered. Both decisions, made cleanly, are wins.
The point
Product leadership is not only about the shiny new thing on the roadmap. It is about the whole portfolio, including the uncomfortable corners. Adopting an orphan — whether to fix it or to bury it properly — is some of the highest-leverage work a product leader can do, precisely because nobody else wants to touch it.
If your organisation has a product nobody owns and nobody will decide on, that is exactly the kind of problem I enjoy. Get in touch.