I regard a significant enterprise sales exception as a roadmap decision, even when it is written in a commercial schedule rather than a product plan. A promised integration, a customer-specific workflow or a special release arrangement allocates future attention. Someone will have to build, test, support and explain it. If the organisation approves the revenue without owning that allocation, the product roadmap becomes partly fictional: it describes planned work while an unrecorded set of promises competes for the same people.
The answer is not to reject every unusual request. Enterprise customers often reveal needs that a product team has not understood, and some of those needs deserve to shape the product. The difficult distinction is between a useful signal and an obligation whose economics depend on permanent special treatment. A chief executive should make sure that distinction is examined while the commercial choice is still open. After signature, the discussion often shifts from whether the promise is sensible to who must absorb its consequences.
Recognise the allocation before signature
The commercial team may describe an exception as small because it occupies a few lines in a proposal or matters to only one customer. Engineering may describe it as large because it affects a shared component or complicates release testing. Neither description is meaningful without the underlying work. I ask the teams to identify the capability required, the expected support life and the effect on other commitments. That conversation should happen before a date is offered to the customer as if it were already an agreed operating fact.
At Nerivane Systems, reviewing 41 separate product branches revealed how those decisions accumulate. Some branches had clear owners and active customer requirements. Others preserved a commitment that had outlived its original sponsor. The cost was not only engineering effort. Account teams had to explain differences between customers, support colleagues needed separate knowledge and release decisions became harder to coordinate. The recurring-revenue record described a subscription base; the branch record described the work needed to keep part of that base functioning.
I want both records visible in material commercial decisions. A proposed contract can be attractive and still require a conscious allocation of product capacity. If management chooses to make that allocation, it should say what other work moves, how the exception is priced and who owns the resulting obligation. The choice may be strategically sensible. Concealing it inside an assumption that the team will find a way is not a strategy. It is a transfer of the decision to people who may lack authority to renegotiate it.
The approval process must remain proportionate. Requiring a senior meeting for every configuration question would slow ordinary business and encourage people to avoid the process. We distinguish supported configuration from a change to the product or its continuing service obligations. The boundary needs examples and periodic review because products evolve. What required an exception last year may now be standard, while a new combination of supported features may expose a dependency that the organisation has not previously examined.
Distinguish a product signal from a permanent exception
A customer request can be valuable evidence even when the requested solution is not the right product answer. I ask product colleagues to identify the underlying task and consider whether other customers face a related problem. That enquiry should not become an indefinite reason to delay a clear commercial response. We need a decision about what we can offer now and a separate decision about what deserves further product work. Confusing the two can leave a customer believing that a research interest is a delivery commitment.
We also need to distinguish a temporary bridge from a permanent branch. A bridge should have conditions for retirement: a supported capability, a migration path and an agreement about who performs the work. Without those conditions, temporary often means that nobody has funded the end state. The customer then becomes dependent on a solution the supplier privately regards as undesirable. That is an unstable relationship, especially when the colleague who originally negotiated it moves on and the remaining teams inherit different accounts of what was intended.
Pricing should reflect the obligation, but a higher price does not make every exception sensible. Some changes introduce complexity that affects many customers or creates a dependency the company does not want to carry. Management may reasonably decline them even where one customer is willing to pay. Conversely, a commercially modest request can justify product investment if it reveals a broadly useful capability. The decision depends on the nature of the work and the company's direction, not only the value attached to the immediate opportunity.
This is where executive leadership matters. Sales, engineering and finance each see a legitimate part of the issue. I do not ask one function to settle it by declaring its own measure decisive. We compare the customer need, the product consequence and the economic trade-off, then record the choice. If the recommendation depends on an assumption we cannot yet establish, the decision should identify how that uncertainty will be handled. A clear conditional offer can be more credible than an unconditional promise whose internal approval remains unresolved.
Give the existing customer a workable transition
Once an exception exists, product discipline must include the customer's position. A technical consolidation does not erase the commitment under which someone bought the system. Our branch programme therefore began with contracts, active usage and feasible alternatives. We gave each account a route: migration after a defined capability became available, continued support with an explicit owner, or an orderly discussion about the relationship's future. Treating every customer as a deployment to be moved would have ignored the commercial reason the branch existed.
Twenty-eight deployments moved onto supported configurations over thirty months. Four customers left at agreed renewal points, taking US$2.1 million of annual recurring revenue with them. Nine branches remained. I regard those details as part of a credible record. The programme did not make complexity disappear through executive determination. It resolved a set of obligations, accepted a revenue consequence and made the remaining exceptions governable. A claim that all special treatment had been eliminated would have been easier to state and inaccurate.
The test for future sales is whether those lessons have changed approval before signature. I ask to see a current exception and follow it from customer need through product ownership, commercial terms and eventual support. If the decision is sound, colleagues should be able to explain who will carry it after the original deal team has moved on. That continuity is what makes an enterprise software promise durable. Growth becomes more dependable when the roadmap and the contract record describe the same business, including the exceptions the company has deliberately chosen to retain.