I have become suspicious of product diagrams in which every client converges neatly on the same box. Sometimes the diagram describes a useful ambition. Sometimes it hides the operating differences that made the separate versions necessary. The engineering leader's task is to discover which kind of diagram is on the table. That requires more than counting repositories or asking whether a feature can technically be configured. It requires an account of the client work, the company's commitments and the attention needed to maintain the chosen behaviour. A common platform is valuable when it supports that account, not when its apparent simplicity prevents us from asking for one.
Understand the reason before choosing the mechanism
A separate implementation often begins with a reasonable local decision. A client needs a different approval sequence, a delivery date is close and the current product has no suitable extension point. A team copies a branch and fulfils the immediate commitment. Months later, another team sees duplicated code and calls it an architectural failure. Both descriptions can be incomplete. The original choice may have been sensible at the time, while its continuing cost now deserves reconsideration. I want those two judgements kept separate. Understanding why a difference began does not require us to preserve it forever, and changing it later does not require us to dismiss the people who made the first decision.
My first question is about the behaviour the client needs. An account manager may describe it as a unique requirement, while an engineer sees a small change in ordering or terminology. Neither label tells us enough. We need to observe the work, identify the outcome and establish which elements are contractual, operational or simply familiar. Some differences can become a supported choice in the common product. Others belong in an extension with a clear boundary. A smaller group may justify a continuing separate line. The mechanism should follow that understanding rather than become the language in which the requirement must defend itself.
This is why I prefer joint examination by product, delivery, account and engineering owners. A product team alone may underestimate the cost of changing a client workflow. An account team alone may underestimate the maintenance created by promising a permanent exception. A delivery team may have the clearest memory of why the difference exists but lack authority to renegotiate it. Bringing those perspectives together creates a decision that can survive outside an architecture meeting. It also identifies who must discuss the proposal with the client. A technically possible migration is not, by itself, an agreed change in the service the company has committed to provide.
Make the continuing account visible
In our workflow review, sixteen runnable branches became six: a common line and five specialist forks. That number is easy to repeat, but it is not the whole result. Ten clients' differences were examined and accommodated through an agreed route into the common product. Five remained separately supported because the common behaviour was not a responsible fit. We retained named ownership for those five. I regard that retained work as part of the outcome, not an embarrassment to remove from the presentation. An investment decision is more useful when it describes the obligations left behind alongside the duplication it has removed.
The common product also acquires obligations. A configurable behaviour needs examination, documentation and a supported combination of settings. Moving code into one repository does not make those activities vanish. If the company permits a large number of combinations without understanding their use, the apparent consolidation can conceal a different form of complexity. I therefore ask the product owner to describe the supported choices in terms a client and support colleague can understand. The engineering team should be able to show how those choices are examined. A feature flag is a mechanism; it is not a substitute for deciding which behaviour the product actually offers.
Financial discussion needs similar care. We observed monthly correction-and-regression effort move from 460 to 310 person-hours in two defined reference months after spending CNY 8.4 million on the consolidation programme. That observation helped us investigate whether the maintenance pattern was changing. It did not become an annual payroll saving, a controlled causal estimate or a reason to ignore the programme's initial cost. The engineers continued to work. Their available attention might support more useful activity, but that activity still needed a product decision. I want finance and engineering to agree what has been observed before either side turns it into a forecast.
A continuing account should also include the option we rejected. Full consolidation would have left one runnable branch, but it would have imposed unsuitable behaviour on five clients or required further product work. Retaining all sixteen would have postponed the migration cost and preserved repeated maintenance. The selected route sat between those alternatives for identifiable reasons. Recording those reasons helps future leaders revisit the choice when the product or client context changes. Without that record, the five retained forks may later look like unexplained inconsistency, and a successor may repeat the entire investigation simply to discover why they were allowed to remain.
Let the product change its answer
I do not want a variation review to become a permanent classification ceremony. A difference that justified its own branch this year may fit the common product after a later capability is introduced. A configuration that looked modest may become difficult to examine as neighbouring features change. The product owner needs a practical occasion to reconsider the answer: a material client change, a support problem, a new shared capability or a renewal discussion. The review should have a reason to occur and enough evidence to be useful. Merely asking every team to certify that its exceptions still exist creates paperwork without improving the product decision.
The cultural point matters as much as the mechanism. Engineers should be able to propose consolidation without being accused of disregarding clients. Commercial colleagues should be able to defend a genuine difference without being treated as enemies of sound architecture. Both should be asked for a reason that can be examined. I have found that the conversation improves when the question becomes what the company is choosing to keep supporting, rather than which function has created the mess. A jointly owned account of the continuing work makes disagreement more specific and gives the eventual choice a better chance of being honoured.
My own correction would be to begin that conversation earlier. In the sixteen-branch programme, initial sketches made the common design feel more settled than it really was. Some client conversations then sounded like requests to justify an exception to an already approved future. Next time I would establish the meaningful variations before drawing that future in detail. The common product should emerge from an informed choice about the work it serves. Its strength is not that every difference disappears, but that the company can explain why each surviving difference deserves its place and what it has agreed to do for it.