A large prospective contract can change the way a team talks about its product. A capability that was exploratory becomes nearly ready. A future integration begins to sound like an existing feature. A decision the customer wants made appears to be another workflow step. The commercial opportunity is real, and the need may be important. Neither fact supplies the expertise, evidence or authority the vendor lacks. Product leadership has to keep those questions visible before a promising discussion becomes a commitment that the organisation cannot responsibly support.
In a fictional 2024 discussion, an insurer prospect proposed a ₹4.8 crore annual engagement combining workflow organisation with automated coverage judgement. Zevqanti's supported products concerned intake, evidence handling and service coordination. The requested decision responsibility was broader. We offered a separately scoped ₹1.1 crore workflow proposal that retained customer ownership of insurance judgement. The prospect declined it. No contract was signed, and neither number became revenue from the discussion.
Separate the customer's need from the current offer
I do not want a scope challenge to begin by declaring that the customer has asked the wrong question. The prospect wanted one supplier to solve a connected problem. That preference may have reflected real operating difficulty in coordinating several systems and professional responsibilities. Our inability to supply the whole answer did not make the need less legitimate. It required an honest account of what our current product could provide and what remained outside it.
A useful product conversation examines the decision being requested, not just the list of features surrounding it. Organising material for a qualified owner is different from making that owner's judgement. A service can assist a workflow without being the institution responsible for interpreting cover. The boundary cannot be settled simply by placing a human review button after an unsupported automated conclusion or describing the output with a softer label. The actual promise and intended use matter.
The commercial sponsor argued that a narrower first release could win the relationship while the remaining capability was developed. That was not an irrational suggestion. Products often grow through demanding customers, and refusing every unfamiliar requirement would prevent useful development. The question was whether the proposed commitment represented a bounded learning programme or an obligation to supply a decision capability whose basis had not yet been established. Those are different commercial propositions.
I asked the team to separate what we could demonstrate now, what required defined development and what depended on expertise or authority beyond the vendor's product remit. Engineering, legal and other responsible owners contributed to that assessment. My role was to form a product recommendation that retained their distinctions, rather than assemble a reassuring composite in which every concern became another item on the delivery plan. A delivery milestone does not by itself resolve the nature of the promised decision.
A roadmap does not complete the missing basis
A roadmap is a statement of intended work, with assumptions and choices still ahead. It can support a discussion of direction. It should not be used as though the presence of an item establishes the capability that item names. The distinction becomes especially important when the future work would change what another person is entitled to rely on. A vendor can plan to investigate a possibility without representing that possibility as a supported production decision.
There is a related danger in treating the contract as the mechanism that will force the organisation to develop the missing answer. Commercial pressure can focus effort, but it can also make later evidence difficult to hear. Once revenue, a launch date and a customer expectation depend on the broader promise, a finding that the capability is unsuitable may be interpreted as a delivery failure rather than an important result. The agreement should leave room for the actual nature of the work.
That does not mean every uncertain development needs to be abandoned. A limited discovery engagement, a clearly scoped prototype or a separately assessed programme may be reasonable where the parties understand the question and its limits. In this case, the alternative we proposed concerned defined workflow organisation. It did not claim to deliver the same coverage judgement through a different description. I wanted the reduction in scope to be substantive enough that both parties could explain what the vendor was and was not undertaking.
We also needed to avoid confusing the proposed annual amount with a loss already incurred. The ₹4.8 crore represented an opportunity under discussion. Declining it did not remove cash from an existing signed agreement, and it was not a saving. The smaller ₹1.1 crore proposal was also unaccepted. Those distinctions make the case less dramatic than a headline about protecting several crores, but they preserve the financial meaning of the decision the team actually made.
The narrower proposal can still be declined
It would be convenient to end this story with the customer appreciating the clarity and signing the revised scope. That did not happen in the demonstration. The prospect needed the broader result and rejected the narrower offer. We were left with a commercially unsuccessful discussion and a product boundary we believed was necessary. A leadership account should be able to retain both facts without claiming that every responsible decision produces a compensating sale.
The outcome also deserved a review of our own process. I would have raised the scope question earlier, before the larger engagement had become persuasive inside the organisation. Sales colleagues had invested time, the prospect had developed expectations and product teams had begun imagining how the work might fit. A later refusal was more difficult for everyone. The lesson was not that commercial teams should avoid ambitious conversations; it was that the product decision needs to enter those conversations before the price makes the scope feel settled.
I would also distinguish refusing the current agreement from closing the subject indefinitely. The unmet need could inform future research or a different partnership, provided those possibilities were assessed on their own basis. A future capability would still need evidence and the appropriate responsibilities. The organisation should not describe the earlier refusal as proof that the problem could never be solved, just as it should not describe an attractive future idea as proof that it has already solved it.
For a board or executive committee, the important question is whether the recommendation preserves the actual commitment. What would the customer rely on? Which part is demonstrated, which is developmental and which belongs to a different professional or institutional authority? What happens if the development does not support the hoped-for conclusion? A product strategy becomes more credible when it can answer those questions before a contract obliges someone else to discover the gaps.
The people and amounts here are invented, but the commercial discomfort is deliberate. The larger proposal was attractive, the alternative was narrower and the customer walked away. Product leadership sometimes requires accepting that result. The responsibility is to explain the scope faithfully, learn from the discussion and keep the next opportunity connected to capabilities the organisation can substantiate, rather than expect a signed agreement to create the expertise its promise requires.