Chief Product Officer / India
The promises we changed before making them
- Institutional software clients
- 32
- Banks and finance companies across India
- Product, research and design colleagues
- 22
- Four managers; engineering separately led
- Annual function expense
- ₹7.6 Cr
- Product organisation; not company revenue
Decisions & consequences
01Removing an execution promise from a renewal control
Our deposit-inventory workflow let a treasury user prepare information for renewing a deposit. The final control said Renew. The software did not transmit an instruction to the institution holding the deposit; that happened through the client's separate banking process. In a moderated test with twenty-four participants, eleven said they believed the action had already reached the bank. Their interpretation was reasonable given the wording and the confirmation screen. A completed task in our interface had become an implied completion outside our service.
The commercial team worried that a more qualified label would make the product look less capable than competing demonstrations. Some experienced users also said the distinction was obvious to them. I asked the team to treat the novice interpretation as evidence about our promise, rather than dismiss it as a training problem. We changed the action to Prepare renewal request, showed the resulting document and stated that external submission remained outstanding. We removed a celebratory completion message that had reinforced the wrong interpretation.
The redesign added an explicit step and made the demonstration less compact. I accepted that cost. In a later test with a different group of twenty-four participants, two still described the action as having reached the bank. We investigated those responses and revised the supporting explanation. I did not present eleven-to-two as a causal effect measured in the same people, or as proof that every user would now understand the workflow. It was evidence from two small sessions about a specific misunderstanding.
Implementation colleagues updated their training, and commercial colleagues changed the demonstration script. The product decision was to align the visible promise with the service we actually supplied. We did not add transaction execution, claim that a deposit had renewed or take authority from the client's treasury team. The remaining ambiguity became part of our follow-up research instead of disappearing inside a completion percentage.
Making a changed proposal earn a new approval
A client review showed that an internally approved treasury proposal could be edited while retaining a prominent Approved badge. The history recorded the amendment, but a reviewer had to open it to discover that the displayed proposal differed from the one originally accepted. We tested forty scripted amendment scenarios across dates, amounts, instruments and explanatory notes. Nine retained the earlier approval despite a change that the client process owners considered material. No live financial loss was established by that exercise; the defect was in what the workflow communicated.
Preparers objected to sending a whole proposal back through review for a small correction. They had a legitimate concern about repeated work. Approvers, however, wanted assurance that their decision remained attached to an identifiable version. I brought both groups into the design review and separated harmless presentation corrections from changes that could alter the decision. The institution remained responsible for defining its policy. Our product would make that policy visible and prevent an old approval from silently travelling to a materially changed proposal.
We introduced a new version for a material amendment, preserved the earlier approved record and showed a concise comparison for renewed review. The latest version carried an awaiting-approval status. We also made it clear that this was internal workflow approval, not evidence that an external transaction had occurred. Engineering implemented the controls; product owned the scenarios and the user-facing explanation. Client owners reviewed the configured policy before use.
The change added work for both preparers and approvers. We did not hide that consequence behind a claim of frictionless control. The forty scenarios were rerun with the intended statuses, and the pilot team could explain which version each decision concerned. That established a narrower result than a universal control assurance. The lesson for me was that approval is a relationship between a person, a decision and a particular object. A green badge cannot carry that meaning reliably when the object is allowed to change beneath it.
Including the people who only need to read
Our proposed commercial package charged for each named user. In discussions with four prospective institutional clients, we found that access requests were being limited to preparers and formal approvers. Occasional reviewers, branch finance colleagues and oversight readers were expected to receive exported documents instead. Some participants proposed sharing access, which was unacceptable to us. The package appeared simple in a quotation but risked separating the people who needed context from the workflow that held it.
The sales lead preferred to keep the named-seat structure because the annualised value of the four proposals was ₹1.8 crore. I asked product research and implementation colleagues to map what each role actually needed. Read-only access was distinct from preparation or approval, and adding a reader did not create the same service obligation as adding another complex workflow. We developed an institution-and-workflow subscription with read-only reviewers included, while retaining individual identities and appropriate permissions. It was not unlimited access to all client data; each institution still controlled who could see what.
The revised annualised contract value for those four offers was ₹1.52 crore. Finance examined the support assumptions, and the commercial team accepted a lower initial proposition in return for a package better aligned with the intended use. I did not describe the ₹28 lakh difference as a realised revenue loss, because these were offers rather than recognised sales. Nor did I claim that future expansion would certainly recover it. The decision had to stand on its stated commercial terms and product rationale.
The immediate outcome was a clearer access model and revised proposals. We agreed to review support demand and actual adoption as contracts progressed. The product lesson was that a pricing unit can create behaviour just as surely as a screen can. If a package encourages a client to remove necessary readers from the process, better interface design alone will not restore the context they need. Commercial simplicity deserves scrutiny when its cost is carried by the user's operating model.
Declining a valuation engine inside a planning contract
A prospective client offered a three-year ₹2.2 crore contract if we added an in-house valuation engine for a set of complex treasury instruments. Our existing product could store and display institution-supplied values alongside planning records. Producing those values would be a different service, with methodology, validation, specialist staffing and continuing maintenance obligations. The requested screen looked like a natural extension. The responsibility behind it was much larger than the screen.
The account team saw an important reference client and wanted an estimate. Engineering could describe the integration work, but that did not answer who would establish the valuation methods or defend their use as conditions changed. I asked for a capability review before a delivery commitment. We had neither the specialist team nor a validated method for the proposed scope. Only two of our thirty-two existing clients had expressed a comparable need, and neither had agreed to the same operating arrangement. A large contract would not automatically make the new obligation repeatable.
I recommended declining the in-house engine and offered a narrower discovery engagement around integrating a valuation source approved by the client's responsible specialists. We proposed ₹18 lakh for that discovery, explicitly separate from a product commitment. The prospect chose another supplier and did not buy our discovery work. The potential ₹2.2 crore therefore remained an unaccepted opportunity, not lost booked revenue. I recorded that commercial consequence rather than presenting the decision as an effortless success.
We subsequently added a product-scope question to opportunity reviews: are we displaying a result, helping a user judge it, or taking responsibility for producing it? Those are different propositions. The decision preserved a boundary we could explain to existing clients and to our board. It also exposed a gap in how early we had allowed a feature discussion to become a sales promise. My responsibility was to recognise the new business hidden in the request before a delivery schedule made the commitment feel inevitable.