I once approved a replacement selector because it made an untidy industrial range appear easier to navigate. The attraction was practical. A customer or sales colleague could begin with an older product and find a proposed successor without working through several catalogues. The mistake was in the claim I allowed that convenience to carry. I treated a mapped successor as though it established a direct replacement. It did not. A relationship between product records could help begin the assessment, but it could not complete the assessment of the customer's installation.
The fictional case took place at Lanveth Controls in 2000, when I was a product manager. We examined 150 legacy products. The selector mapped 116 to proposed successors and left 34 unresolved. Within the mapped group, 18 required changed connections. Minzhen Qiu challenged the direct-replacement language during a review. I had approved that language, so the correction was my responsibility. We withdrew the unqualified proposition and separated 98 direct-replacement candidates, 18 adapter-dependent cases and 34 unresolved mappings. CNY 1.8 million supported the review and correction. Those categories described what the work could support; they were not a certificate of suitability for every application.
## A useful mapping can still carry the wrong promise
The original selector did something useful. It reduced the work required to find a possible successor. A product team does not have to discard a useful relationship merely because its first presentation was too confident. The difficulty is that a simple interface can make a provisional relationship appear conclusive. A person who sees a single replacement result may reasonably infer that the questions needed for substitution have already been answered. If the team has established only a catalogue mapping, that inference goes beyond the work completed.
My error was therefore more than an imperfect label at the edge of an otherwise finished product. The label affected the action the selector invited. Direct replacement suggests a different customer task from candidate for assessment. An adapter-dependent case suggests another task again. A customer may need to examine connection arrangements, installation conditions and the appropriate technical evidence before choosing a course. Product management should make the route understandable, while engineering and the responsible application specialists determine the questions within their authority.
The commercial argument for one answer was not foolish. A fragmented selector can discourage use, increase the burden on sales colleagues and leave customers unsure where to begin. Minzhen's challenge did not remove that problem. It required us to solve it without presenting uncertainty as certainty. We could still show a proposed successor, but the recommendation needed to explain which path followed. The work became a choice about the product experience: what could be concluded immediately, what needed an adapter assessment and what remained unresolved.
I also had to recognise that the 116 mapped products did not form one uniform group. Once 18 required changed connections, describing the whole group as directly substitutable was untenable. The remaining 98 became direct-replacement candidates, not universally approved substitutions. The absence of a known connection change did not establish every other condition of use. That distinction prevented the correction from replacing one overstatement with another. A narrower claim should still be examined for the evidence it requires.
## Make the unresolved application part of the product decision
The 34 unresolved mappings were the least attractive part of the story, but they were part of the product problem. Omitting them would have made the selector look more complete without giving their users a valid answer. I wanted the unresolved result to remain visible, with an appropriate route for further assessment. That did not require inventing a successor or promising that every older application would receive the same eventual solution. It required the user to know that the selector had reached its limit.
This changed the conversation inside the team. We could no longer treat completion as the presence of a destination beside every legacy entry. We had to consider whether the destination, category and next step were honest about the application work that remained. That made the selector more demanding to maintain. A new product record or revised connection arrangement could change a recommendation, and a convenient display was no substitute for the underlying review. The case records the correction work; it does not claim a later measured reduction in selection errors.
The 18 adapter-dependent cases also deserved a distinct explanation. An adapter is not simply a footnote that restores the original promise. It may affect what must be procured, installed, assessed or supported. The appropriate technical owner has to determine the relevant conditions. My product responsibility was to prevent those cases from appearing identical to a candidate whose connection arrangement had not been identified as changing. The selector needed to help the next person ask the right question, rather than make the question disappear.
There was a cost to accepting Minzhen's challenge. We had to revisit approved work, spend CNY 1.8 million on review and correction, and explain why the proposition had changed. It would have been easier to call the 18 cases exceptions and retain a confident headline. I chose to withdraw that headline because it was the organising promise of the tool. A qualification hidden after the recommendation would not have corrected the invitation to act that I had already approved.
## Correct the claim without claiming that every risk is settled
The useful outcome was a selector whose categories better matched the evidence. We retained the candidate relationships, identified the cases needing changed connections and kept the unresolved mappings outside a false sense of completion. That was a meaningful correction, but it did not prove that every installation was suitable, that all customers had changed equipment or that no selection problem could occur later. Those conclusions would require different evidence. An executive account should be able to describe the improvement without borrowing those unearned outcomes.
The case has stayed with me because I was responsible for the overstatement. It is easy to build a leadership narrative around occasions when someone else's assumption was challenged. This example is useful precisely because the convenient assumption was mine. I wanted a clear successor story and accepted wording that made our work appear more complete than it was. Minzhen made the missing distinction visible. My responsibility was to change the product account and accept the additional work, rather than explain away the challenge.
In later portfolio work I have returned to the question of what a proposed successor actually promises. A common family, a revised catalogue or a planned retirement can all make a range easier to describe. None automatically settles the customer's installed conditions. Product leadership involves choosing which promise the organisation can support and making the remaining work intelligible. The selector error taught me to examine that promise before celebrating the clarity of the interface that carries it.
This is a fictional account, with invented organisations and colleagues. A real case would require authorised evidence and technical review appropriate to the products involved. The principle I would retain is narrower than a universal replacement method: a product mapping should state the next decision it supports. When the evidence identifies a candidate, an adapter-dependent path or an unresolved application, the public claim should preserve that distinction. The customer can then begin with a useful recommendation instead of inheriting certainty the product team has not earned.