A product can be quiet and still require a future
Activity data can identify a portfolio question. It cannot settle the obligations that make a retirement decision responsible.
Product portfolios often reveal their age through the items nobody mentions in a growth presentation. A module has few recent enquiries, its usage appears quiet and the team would like to move on. The case for retirement can seem obvious. Yet the business may still owe support, access or a workable transition to someone who bought it under a different set of expectations. I want that obligation in the discussion before a quiet product becomes an easy source of promised capacity. The decision may still be to retire it, but the route matters as much as the count.
At Zevrali we reviewed forty-eight modules while examining development priorities. Eleven showed no recent activity in the period used for the review. An early proposal grouped them as potential withdrawals. Looking beyond the activity record, we found that three still supported explicit client commitments. The resulting plan retained those and established an eighteen-month transition for the other eight, funded with ₹1.1 crore. The smaller retirement number was not a failure of ambition. It was a more accurate description of the decision the company could responsibly make.
## Separate the signal from the obligation
An activity report is a signal that deserves investigation. Its meaning depends on what it records, the period it covers and the way customers use the product. A training module may be needed only at particular times, and a client may retain a right to use it even when recent activity is limited. None of that proves the product should remain indefinitely. It means the review needs more than one source. Product records, customer arrangements and the experience of the people providing support should be reconciled before the company treats inactivity as evidence that responsibility has ended.
The three retained modules were not simply exceptions to be footnoted after the announcement. They changed the proposal. We asked commercial and delivery colleagues to explain the commitments and product leaders to describe the work needed to honour them. The strategy team could then separate continued support from new development and examine each on its own terms. That distinction helped avoid a false choice between investing in every old module forever and withdrawing everything that no longer attracted attention. A company may stop adding capability while continuing an agreed service, provided the boundary is understood and properly managed.
The account should also distinguish technical possibility from the commercial right to act. An engineer may know how to disable a module or move a customer to another version. That does not settle the customer's entitlement, the suitability of the replacement or the communication required. Similarly, a contract may permit a change that would still be costly or unwise in the relationship. I want the relevant owners to examine those issues together. Strategy should make the choice clearer without pretending to replace legal judgement, product acceptance or the customer conversation with a single portfolio score.
## Fund the work between a decision and an ending
The eight-module transition required eighteen months and a ₹1.1 crore allocation for support and migration work. That cost belonged in the retirement proposal. A plan that releases future capacity may first need scarce people to help customers move, document the replacement or maintain an interim arrangement. If those tasks are left unfunded, the organisation can approve a retirement that exists mainly in presentation form. The old work then continues through exceptions while the new plan assumes its resources have already become available. The result is pressure on teams rather than a real strategic choice.
I did not describe the allocation as a deduction from a theoretical saving. The approval concerned a defined programme of work; any later capacity release needed its own evidence. A module count is not a headcount calculation, and several products may share support or engineering resources. Retiring one item does not necessarily remove a separable cost. Finance and delivery colleagues should help determine what changes when the work ends. The proposal can still be worthwhile if its benefit is reduced complexity, a more coherent product direction or a clearer customer obligation, but those reasons should be stated honestly.
Implementation needs an accountable owner and a way to return to the decision if an assumption fails. A customer may not be ready for the proposed transition, a replacement may require more work or a previously overlooked commitment may emerge. Those findings should not automatically cancel the programme, nor should they be suppressed to protect the original count. I want management to distinguish a problem it can resolve within the approved plan from a change that requires renewed authority. The strategy remains useful when it gives the business a disciplined way to adapt, rather than a date it must defend regardless of circumstances.
## Bring the lesson back to the next launch
Portfolio retirement is often treated as cleaning up an old problem. I see it as evidence for the next product decision. A team proposing another module should explain the likely support obligation, the sources that will need updating and the conditions under which the company might stop investing. Those answers will be imperfect, but asking early changes the proposal. It encourages designs that are easier to maintain and commercial terms that reflect the service being offered. It also makes the eventual transition less surprising to colleagues whose budgets did not exist when the initial launch was approved.
This does not mean every product needs an elaborate end-of-life plan before the first customer can use it. The level of planning should match the commitment. A small experiment with clear limits differs from a product embedded in a customer's recurring training process. The important point is to recognise when an experiment becomes an ongoing obligation and adjust the account accordingly. Companies can accumulate long-term responsibilities through a series of short-term decisions, especially when each extension appears modest. A periodic review should make that accumulation visible while there is still a practical choice about its direction.
Directors can ask whether a portfolio proposal connects commercial activity, customer responsibility and the cost of transition. They should understand what management expects to stop, what it must continue and what evidence will demonstrate that the intended change has occurred. They do not need to select a replacement module or manage individual migrations. Their contribution is to ensure the decision recognises the company's material obligations and that management has authority and resources proportionate to the task. A board that hears only a retirement count may approve a promise very different from the work the business actually has to perform.
The lesson I took from our review was to be more precise about endings. We approved a route for eight modules, retained three obligations and left implementation with the responsible leaders. That account is less dramatic than saying eleven inactive products were removed, but it is more useful to everyone who must act on it. A product has a future until the company's responsibilities around it have been resolved. Strategy should help the organisation choose that future deliberately, whether it involves further investment, bounded support or a transition whose cost the business is prepared to carry.