A large enterprise opportunity deserves serious attention, but its value cannot be understood from the proposed contract amount alone. The buyer may be asking for a useful configuration of a shared product. It may instead be asking the supplier to maintain a different product future, with its own sequence of decisions and obligations. I want that difference described while the company can still choose. Once exclusivity and delivery commitments have been made, a roadmap discussion can become an exercise in explaining why the promised exception must come first.
In my fictional 2023 case at Mervanith, a buyer proposed an eighteen-crore contract for an exclusive workflow. The requested branch would occupy three shared teams for fourteen months. The commercial proposal was substantial, and rejecting it carried a real opportunity cost. We chose to decline the exclusive branch and fund a configurable module for a six-client pilot. Four clients adopted that module and two declined. The eight-point-four-crore programme expense was not a saving against the proposed contract, and neither amount established a profit result.
Describe the future being sold
I would begin with the promises embedded in the request. An enterprise workflow can look like a bounded feature list while implying a continuing obligation to keep that branch compatible with later releases, support it separately or secure the buyer’s consent before changing it. Those implications need examination by the appropriate commercial, engineering, legal and operating owners. The product question is whether the company is willing to make that future part of its offer, rather than whether a team could build the first version if assigned enough time.
Exclusivity makes the distinction particularly visible. A shared product normally develops through choices that can serve more than one customer, although their needs will never be identical. An exclusive branch constrains how some of that work can be used and may influence what the company can subsequently promise elsewhere. I would ask for the requested restriction to be described precisely. A vague reassurance that the work is reusable cannot resolve an actual contractual limitation. Equally, the word exclusive should not be used to exaggerate a restriction the buyer did not request.
Nandita Vervale challenged our willingness to absorb the proposed branch. Her question concerned the work that three shared teams would no longer be able to pursue during those fourteen months. That challenge did not make the buyer unreasonable or the commercial team careless. It made the opportunity a company choice with consequences beyond the account. I found it more useful to examine those consequences together than to frame the discussion as a contest between people who understood revenue and people who cared about product purity.
Price the displaced work in its own terms
The proposed eighteen crore described an opportunity, not money already earned. The alternative programme expense described an authorised commitment, not the complete cost of ownership or a margin calculation. Putting those amounts beside each other without their meanings would have encouraged a false subtraction. I would ask finance and the relevant commercial owners to assess the economics while the product team explains the capability, capacity and sequence being promised. A clear product argument does not replace a financial assessment, and a large contract value does not settle the product argument.
Displaced work also needs a credible account. I would resist inventing a revenue figure for every roadmap item that might wait, because that can make a preferred plan look financially certain when it is still a hypothesis. The useful account identifies the work, its intended users, the evidence behind it and the consequences of delay that can actually be supported. Some commitments may already be firm. Other ideas may have weak evidence and deserve to be displaced. Protecting a shared roadmap should not mean protecting every item previously placed on it.
There is a further question about reversibility. A limited experiment can often be stopped without creating a long-lived branch, whereas an exclusive operating product can leave obligations after the initial build ends. I would want the team to distinguish development effort from the continuing support and change relationship. That does not imply every bespoke commitment is a mistake. A company may deliberately choose a service model or a strategic customer relationship that justifies it. The decision should be made in those terms, rather than disguised as a small product exception.
Our alternative did not reproduce the exclusive offer under a different label. It funded a configurable module intended to test whether a common capability could serve several clients without promising the same branch to each. Configuration still required boundaries. If every pilot participant needed an entirely different process, the exercise could become several bespoke products with a common name. I would ask what remains shared, which choices a client can make and where a request would require a new decision. That account should be understandable to those selling and supporting the offer.
Leave room for a customer to decline
Four adoptions among six pilot clients were useful evidence about that particular offer. The two declines also mattered. They showed that the module did not satisfy every participating customer and prevented us from describing it as a universal replacement for the original request. I would examine why each client declined without treating rejection as an error the product team must always overcome. A buyer can have a legitimate need that the supplier deliberately chooses not to serve. The quality of the decision depends partly on recognising that boundary before a promise is made.
A pilot does not retrospectively prove that declining the larger contract was financially optimal. The alternative may develop well or poorly, and the lost opportunity remains a real part of the choice. I would retain that uncertainty in the board account. Management should explain why it preferred a shared capability, what evidence it expected to learn and what would cause it to reconsider. The account becomes weaker if every subsequent event is recruited as proof that the original decision was inevitable. A considered trade-off still has a forgone path.
For a real enterprise-software business, I would ask the commercial and product teams to make these commitments visible early enough for a joint decision. The buyer deserves an honest account of what is available, what would require separate agreement and what the supplier cannot offer. Internally, the teams need the same understanding so that an exception is not quietly sold after it has been declined in planning. This is a discipline of describing the business being accepted, not an argument for refusing demanding customers. The fictional case illustrates a narrower choice: we accepted a smaller, testable common promise and retained the possibility that some customers would reasonably choose something else.