Before the workflow tells somebody to act

In 2018, as product director, I approved an offline-intake design that displayed received once a device placed a submission in its local queue. The team wanted to give field users a clear end to a difficult journey with intermittent connectivity. I accepted that rationale without adequately distinguishing local persistence from acknowledgement by the receiving service. The interface's apparent completion was stronger than the event it represented.

Manoj Qevzarthi challenged the behaviour in an eighty-scenario scripted review. Seventeen scenarios displayed the acknowledgement without server receipt; sixty-three represented the state correctly. The delivery lead wanted to retain the simple success screen and explain the distinction in training. I disagreed after seeing the review, because the next action should not depend on a user remembering that an ordinary word meant something narrower than it appeared to mean.

I authorised ₹43 lakh for correction and accepted a six-week delay. The revised design distinguished queued material from a received submission and supplied an unresolved route when acknowledgement was absent. Engineering owned the implementation and technical checks. The product decision defined what the user could be told and which state remained unsupported.

On retesting the eighty scripted scenarios, seventy-five represented the state correctly and five remained withheld from release. I did not present that result as proof across every device or connectivity condition. Nor did the exercise establish that an actual insurance claim had been lost or a payment had been affected. These were findings from the defined review, with continuing work for the five scenarios.

The correction also required me to explain my own earlier approval. The screen had made the journey feel complete, and I had allowed that experience to stand in for the receiving event. Next time I would define the evidence for each product state before approving the interaction pattern. A reassuring ending is useful only when the person relying on it can understand what has actually happened.

A 2022 booking prototype supported field assignments involving a customer and an external service participant. Its proposed confirmed state appeared once either side supplied an available slot that matched the request. In a thirty-six-job scripted exercise, twenty-two had confirmation from both parties and fourteen had confirmation from only one. The interface had made the whole appointment look settled before the required agreement existed.

The commercial sponsor preferred the shorter journey because additional confirmation could reduce the number of apparently completed bookings. Service-design colleagues pointed out that the missing step would still have to happen outside the product. Calling the appointment confirmed did not supply the other person's agreement, and it could make a later coordination call feel like a change to a promise already made.

I recommended separate proposed and confirmed states, with each party's contribution visible to the appropriate user. A ₹62 lakh change and eight-week delay allowed product, engineering and operating owners to agree the transition and handling route. The receiving insurer retained responsibility for its service arrangements. Our software did not certify a provider's qualifications, capacity or eventual attendance, and it did not determine insurance coverage.

The revised scope preserved the twenty-two jointly confirmed scenarios and left the fourteen single-party cases awaiting the missing confirmation. It did not turn those fourteen into failed appointments or establish how many real visits would subsequently take place. The team accepted a less impressive completion count for the prototype and additional coordination work in the pending route.

The lesson was to identify whose commitment a product state represents. A convenient booking event for one participant may still be a proposal for another. I would involve the receiving service owner before settling the status vocabulary in a future design, so that the product's apparent efficiency is not purchased by handing an unexplained obligation to the next person.

A 2023 product review examined sixty inspection-image packages used in a defined customer workflow. Forty-one retained both original images and annotated derivatives. Nineteen retained only the annotated versions. The annotation feature helped people explain a point on an image, but the product had not consistently preserved the distinction between source material and the version created to discuss it.

The feature sponsor wanted to treat the visible picture as sufficient because it still showed the subject and carried useful markings. Customer professional owners asked for the original relationship to remain available. An annotation can be helpful without becoming a substitute for the source. My team was not qualified to declare that a derivative alone supplied everything required for a particular insurance interpretation.

We allocated ₹72 lakh and delayed the relevant release by four weeks. The product specification retained originals separately, linked derivatives to their source and made the distinction visible in the supported handling route. Engineering and security owners retained the technical implementation and access responsibilities. Customer insurers retained the assessment of what the material could support in their own processes.

Sixteen of the nineteen missing originals were recovered through the authorised source route. Three remained unresolved. The revised account therefore had fifty-seven packages with both forms and three whose missing source was explicitly retained as an outstanding issue. Recovery did not prove the authenticity of every image, certify a loss or resolve a claim. We did not recreate an original by removing visible markings from its derivative and describe that reconstruction as the source.

The delivered change made the evidence-handling behaviour more faithful, while accepting the work the product could not complete. I would define the source-retention requirement before designing an editing feature next time. A tool that makes material easier to explain should not quietly make it harder for another professional to distinguish what was supplied from what was added in discussion.

In 2024 an insurer prospect proposed a ₹4.8 crore annual engagement that combined workflow organisation with automated coverage judgement. The commercial opportunity was material to the product portfolio. Our supported capabilities concerned intake, evidence handling and service coordination. The proposed decision responsibility would have required a different basis of expertise, authority and assurance from the product we could responsibly offer.

The sales sponsor argued that a narrow first release could win the relationship and the remaining capability could be developed afterwards. I understood the attraction, particularly because the prospect wanted one supplier and had linked the commercial value to the broader scope. My concern was that the agreement would attach a decision promise before we had a supported proposition for making it. A future roadmap item could not supply the missing basis at the point of commitment.

I recommended declining the proposed annual engagement and offered a separately scoped ₹1.1 crore workflow proposal. That alternative retained customer ownership of insurance judgement and specified the organisation and handling work the product could support. Legal, engineering and other responsible owners reviewed the proposed boundaries. I did not present the reduced scope as a way of delivering the same decision indirectly.

The prospect declined the narrower proposal because it did not meet the full need. No contract was signed, and neither figure became recognised revenue from this discussion. The ₹4.8 crore was a proposed opportunity, not cash lost from an existing agreement or a saving achieved. We accepted the commercial disappointment rather than claim that a clearer scope had automatically won the customer.

What I would change is the timing of the product conversation. The scope question should have been examined before sales discussions made the larger package feel like a near-complete deal. A CPO needs to be able to explain what the product will not responsibly promise, while still listening carefully to the unmet need. Declining this proposal did not mean the customer's problem was unimportant; it meant our current offer could not honestly be described as its full answer.

Our 2025 plan proposed retiring an older workflow version used in fourteen customer instances. Nine had a verified export route suitable for the agreed transition. Five still needed continuing read access while their outstanding requirements were resolved. The product roadmap treated the newer version's availability as the main condition for retirement, but that did not settle what customers still needed from the older record.

The engineering sponsor wanted to proceed on the original date because maintaining the version diverted capacity from current work. I agreed that indefinite support was not a reasonable default. Customer and legal owners nevertheless needed to establish the remaining contractual and handling requirements. A majority being ready did not make the other five instances disappear, and the product team could not invent a universal retention period to simplify the decision.

I recommended a six-month postponement with ₹1.2 crore of support expense, alongside named work for the outstanding transitions. The continuing route was bounded and focused on the required read access; it was not a promise to keep adding features to the older version. Engineering, security and customer professional owners retained their responsibilities for the arrangements within their remit.

The immediate result was a revised retirement decision and funded continuity for the unresolved cases. It did not establish that every customer had completed migration or that the eventual retirement would require no further decision. We retained the nine ready instances and five outstanding ones as distinct positions. No customer records were represented as safely disposable merely because the original product deadline had arrived.

The tradeoff was real: support expense and capacity remained tied to an older product for another six months. Next time I would make the exit evidence part of the retirement proposal from its beginning, rather than treat it as a customer-success task after the date was chosen. A product lifecycle should account for the obligations left by its use, including the work that continues after the portfolio would prefer to move on.