Compatibility is only one relationship
A product roadmap is usually better at describing what will arrive than what must continue. The next generation receives a name, a proposed release and a development account. The installed family can appear as a declining line beneath it, with migration expected to resolve the remaining complications. I find that picture incomplete when the product includes an ongoing service relationship. The older customer does not cease to exist because the supplier has found a more attractive architecture. A credible plan needs to show who owns the continuing obligation and what resources the business has chosen to retain for it.
In our fictional 2025 controller review, 132 of 198 installed sites used protocols supported by a proposed remote controller. Sixty-six did not. That was a useful compatibility finding, but it was not a completed implementation plan. Even among the 132, supported protocols did not establish customer permission for remote control, engineering acceptance of the proposed installation or an agreed migration schedule. Among the sixty-six, incompatibility did not erase the service relationship. The product account had to explain these different conditions without making the successor’s apparent readiness larger than the evidence supported.
Owen Carvelen argued for concentrating development expense on the new controller and managing the older group through exceptions. I understood why. Maintaining several generations can consume attention and make it harder to improve the portfolio. The decision was not between a responsible person who cared about customers and an irresponsible person who did not. It was between two ways of allocating limited resources and describing the obligation. I thought an exception queue was inadequate as the primary account for a known group of installed sites. It would hide a recurring responsibility inside individual requests arriving after the product plan had been approved.
We reserved C$6.4 million for the older-control support programme covering 2026 through 2033, while migration planning remained specific to each site. The eight-year horizon made the retained obligation visible in the portfolio conversation. It was not a statement that every installation would remain unchanged throughout that period or that future technical conditions could be settled in advance. Service and engineering colleagues still had to examine actual circumstances. The product decision funded and named the support path; it did not replace the professional judgements required to carry out the work.
This distinction matters because a support date can become another headline that carries too much meaning. A customer may hear a promise of a particular capability, while an internal team may mean that a support programme remains funded. Those accounts need to be reconciled in the actual proposition and agreement. I do not want the portfolio to exchange one ambiguous retirement statement for an equally ambiguous extension. The purpose of the dated account is to make the work, its ownership and its limits examinable, so that continuing service can be discussed on the conditions relevant to the site.
The expense left outside the launch story
There is a financial consequence that the launch story should retain. The C$6.4 million reserved for the older family could not simultaneously be treated as unrestricted expense for the successor. That trade-off should appear in the product plan rather than be discovered after the development programme has been approved. I am not suggesting that the older architecture should always win. There are cases where maintaining it is no longer appropriate or practical. But a decision to change the service path needs its own account of the customer relationship and the work required, not a narrative shortcut in which the newest product silently becomes the only legitimate destination.
A retirement account with an owner
The product organisation also needs to distinguish a technical route from an authorised action. A compatible protocol can make a proposed integration possible. It does not grant authority to operate a customer’s process. Our earlier load-control work had already shown that some facilities wanted bounded automation and others wanted manual confirmation. That lesson applies to a successor as well. If the roadmap uses one migration count for several stages, colleagues can begin discussing a technical assessment as though a customer agreement and completed installation already exist. Separate stages keep the commercial account and the operational work aligned around what has actually happened.
For the installed customer, this is partly a question of whether the supplier still understands the purpose for which the earlier product was chosen. A site may have a different operating calendar, premises horizon or control arrangement from the one assumed in the latest family. The customer is not necessarily resisting improvement when it asks how those conditions will be handled. Product leadership should be able to examine the question without making adoption of the new architecture the proof of a reasonable customer. Sometimes the successor fits; sometimes a different service path needs to continue while another option is assessed.
A board or executive committee should therefore be able to read the next-generation proposal and understand the retained installed responsibility alongside it. Which group is compatible? Which group has agreed to the proposed change? What remains under engineering or site review? What expense belongs to the older family, and who owns decisions when its conditions change? These questions need not turn directors into product managers. They make the strategic and financial account more complete, allowing the collective decision to consider the obligation accompanying the growth proposition rather than treating it as background work outside the main plan.
I also want the organisation to notice when the older support path is consuming more effort than expected. A funded horizon should not become a reason to avoid revisiting assumptions. It should give the responsible teams a clear route to explain changed circumstances and seek a new decision. That is different from quietly reducing service because the portfolio has moved on, and different again from retaining every earlier arrangement indefinitely without examination. A visible obligation can be reviewed; an obligation hidden in scattered exceptions is harder to understand until something important has already been missed.
Retirement is consequently part of product authorship. The team deciding what will replace a family should help describe what happens to the people who use it now. In the controller case, the result was a dated support programme and site-specific migration work, with no claim of universal upgrade completion. That is a less dramatic ending than announcing that 198 sites have moved into the future. It is a more useful account of the work the business actually chose. I want a roadmap whose older customers remain present long enough for their commitments to be examined, funded and changed through an explicit decision.