Recognise the new business hidden in a feature request

A feature request can look small because it occupies a familiar place on a screen. A client asks for a new value beside an existing record, and the conversation quickly turns to inputs, calculations and delivery dates. The visual proximity encourages everyone to treat the request as an extension of the product already in use. But the new value may carry a different obligation. A supplier that previously displayed a client's result may now be expected to produce, explain and maintain that result itself. That is where I pause the feature discussion and ask what business we are proposing to enter.

Describe the obligation before estimating the work

A prospective client offered Sarnovel a three-year ₹2.2 crore contract if we added an in-house valuation engine for a set of complex treasury instruments. Our existing software could hold institution-supplied values and place them in planning workflows. It did not establish the valuation methods behind those figures. The requested addition therefore involved more than a calculation field. It would require specialist competence, a basis for validation and a continuing response to changes in instruments, assumptions and use.

The account team saw a valuable reference client. Engineering could describe much of the integration and presentation work. Neither observation answered the central question: who would take responsibility for the method and its maintenance? We did not have a specialist team or a validated method for the proposed scope. I wanted that gap visible before a schedule made the commitment appear settled. A technically feasible implementation can still be an unsuitable product if the company cannot support the meaning of its output.

I asked the team to distinguish three activities. We might display a result supplied by the institution. We might help a user compare or question that result. Or we might produce the result and become responsible for the method used. Each activity requires a different proposition and different evidence. Combining them under one feature name would make it difficult for colleagues and clients to understand what we had agreed to provide. The distinction needed to appear in the commercial discussion, not only in internal technical notes.

We also examined whether the request represented a repeatable need across our client base. Only two of thirty-two existing institutions had expressed a comparable interest, and neither had agreed to the same operating arrangement. That did not prove that a market could not exist. It did mean that the prospective contract should not be treated as evidence that a common product was already established. We would have been making an investment in a new capability, with one client's requirements strongly influencing its direction.

The capability review did not make the decision automatic. Companies can choose to enter adjacent businesses. They can recruit specialists, acquire methods or partner with qualified providers. But those are strategic choices that require resources and accountability. They should not happen by implication inside a feature estimate. I wanted the executive team to decide whether we intended to build that capability, rather than discover after signing that the contract had already made the choice for us.

Separate an opportunity from a booked outcome

I recommended declining the in-house engine. We offered a narrower discovery engagement, priced at ₹18 lakh, to examine integration with a valuation source approved by the client's responsible specialists. That proposal did not commit us to build the broader product. The prospect selected another supplier and did not purchase our discovery work. I recorded the result plainly. We had given up a potential ₹2.2 crore opportunity and had not replaced it with a paid engagement.

It would be misleading to describe that amount as lost recognised revenue. No contract had been accepted. It would be equally misleading to present the refusal as a success with no commercial cost. The account team had invested time, and the company had declined an opportunity that might have supported growth. A credible product decision record should preserve both facts. Restraint is easier to praise after the event if the foregone possibility has quietly disappeared from the account.

The sales team's disappointment deserved a direct response. I explained why the narrower offer was the most we could responsibly propose with our current capability, and I acknowledged that it might not meet the prospect's need. I did not ask the team to imply that a partnership or a future hire had already closed the gap. A conditional possibility is useful only when the customer understands the condition and the company has a realistic route to satisfying it.

There is a temptation to defend a refusal by inventing a larger avoided disaster. We did not know that accepting the contract would have caused a loss or a failure. What we knew was that the obligation exceeded the capability we could demonstrate and that we had not approved an investment to close that gap. That was sufficient grounds for the decision. Keeping the reasoning at that level made it more useful for future opportunities, because it did not depend on an untestable claim about what might have gone wrong.

Make the boundary useful for future decisions

Afterwards, we added a scope question to opportunity reviews: are we displaying, helping someone judge, or producing the result? The question gives commercial and product colleagues a shared way to recognise a change in responsibility. It does not ban adjacent growth. It directs a different kind of proposal to the people who can assess capability, resources and continuing obligations. That is more useful than asking every account team to remember the details of one declined contract.

We also asked product managers to describe maintenance before launch. Who will review the method, respond to an exception and decide whether a changed use remains within scope? What evidence will the customer expect when a result is challenged? How will the company price the continuing work? These questions can change the economics of a proposal substantially. They should therefore be answered while there is still a choice, rather than treated as operational detail to be resolved after a sale.

An external source can be part of a narrower proposition, but integration is not a way to make accountability disappear. The client and supplier still need to understand the source, the permitted use, the handling of changes and the responsibilities on either side. In our case, discovery would have examined those questions before any product commitment. The fact that the prospect declined that route did not make the route wrong; it showed that our offer and its desired scope did not align at that time.

For a board, the important issue is whether growth commitments are being made at the right level. A director should not approve every feature, but should be able to see when management is taking on a new type of obligation. Large opportunities can make a capability gap look temporary or minor. The board's role is to ask whether the proposed investment, evidence and accountability match the promise, and whether the commercial timetable leaves room for a real decision.

I want our product organisation to be ambitious about problems it can learn to solve and precise about the work required to solve them. Those positions belong together. A company can expand its competence deliberately, or it can overstate its competence accidentally. The difference is often visible before the first line of code is written. Recognising a new business inside a feature request gives us the chance to choose, resource and explain that expansion rather than inherit it from an attractive sales conversation.