From implementing a rule to deciding what it promises

Mandate

Make the administrative commitment and support implications of the scheduling product clear

Outcomes

• Revised combined resource reservations after nine clashes in sixty rehearsed appointments
• Separated waitlist offer, acceptance and expiry states
• Funded a keyboard-operable task route with remaining assistance needs recorded
• Made acknowledgement of consequential schedule handoffs explicit

Decisions in context

The CPO role brought the product promise and its support cost into the same executive account. I lead thirty-eight colleagues through four leads, with ₹9.4 crore annual expense and ₹2.1 crore approved investment. The CEO is Saira Venqari; engineering reports separately to the CTO. Our provider customers retain clinical judgement, and Madan Qervali advises on the boundary between an administrative workflow and a clinical decision. Recent choices have required displaced roadmap work as well as new functionality. We changed the reservation model, separated an offer from a confirmed appointment and funded a keyboard route and acknowledged handoff. Each result remains tied to its observed population. I want the leadership team to understand what the product has established, what remains uncertain and who must do the remaining work after a release. I am not a statutory director of Kelqora.

Reason for the move

Current appointment; considering a first non-executive seat with employer consent

Mandate

Develop a product approach that represents provider scheduling constraints without taking clinical decisions

Outcomes

• Brought provider operating constraints into product discovery
• Clarified which workflow choices required clinical advice
• Developed product leads able to account for support obligations

Decisions in context

I joined Kelqora to work on appointment coordination in a setting where administrative convenience could be mistaken for a broader professional judgement. The company employed 220 people and recorded ₹58 crore revenue in FY 2017. I led twenty-five colleagues through three leads with ₹6.1 crore annual expense. We needed to understand the provider's working arrangements before deciding what the product could promise. A room reservation was within the administrative workflow; deciding the clinical priority of a person's need was not. That distinction required conversations with clinic teams and our adviser rather than a generic software rule. I also learned to ask what support would be needed when the preferred route failed. The later CPO appointment extended these questions into investment and executive prioritisation, where accepting one product obligation meant postponing another piece of the roadmap.

Reason for the move

Promoted to chief product officer

Mandate

Understand the full appointment or access task, including interrupted actions and alternative routes

Outcomes

• Added recovery from interrupted tasks to research plans
• Examined alternative interaction routes alongside preferred demonstrations
• Developed product research and design leads

Decisions in context

Belthari gave me responsibility for a larger product group and a wider range of service settings. The company had 205 employees and ₹41 crore revenue in FY 2011; my remit was sixteen colleagues through three leads and ₹3.2 crore annual expense. A successful demonstration was no longer enough to explain whether a product worked for the customer. I watched people return to an unfinished request, correct a mistake or use a different interaction method, and saw how much of the task our preferred path left unexplained. Those observations changed the questions I asked before approving a release. I wanted the team to describe recovery and assistance as part of the product account. The title was an executive appointment, not statutory board service. Moving to Kelqora let me apply that experience to a more specific operating context with clearer professional boundaries.

Reason for the move

Joined Kelqora to lead product in a provider-specific scheduling environment

Mandate

Translate customer scheduling problems into product choices with explicit limitations

Outcomes

• Progressed into management of seven product colleagues
• Used support cases to question proposed scheduling rules
• Completed a part-time product-management diploma while employed

Decisions in context

The move into product analysis changed my responsibility from implementing a rule to examining whether it was the right rule. Nervoshi employed 140 people and recorded ₹22 crore revenue in FY 2004. I became product manager in 2007, leading seven colleagues with ₹86 lakh annual expense. I studied part-time at Kervoni Product Institute and completed the diploma in November 2009 without a break in employment. Customer support gave the work practical depth:an exception was often evidence of a legitimate operating arrangement rather than an inconvenient departure from our design. I learned to explain what the product supported and what it did not, including the manual work still expected from a customer. Belthari later offered a larger team and more varied appointment and access settings in which to develop that judgement.

Reason for the move

Moved to Belthari for a broader product leadership remit

Mandate

Implement scheduling rules and investigate exceptions under engineering review

Outcomes

• Learned to trace calendar behaviour through customer support cases
• Developed an understanding of operating exceptions
• Moved from engineering implementation into product analysis

Decisions in context

My first appointment followed computer engineering studies completed in May 1998. I joined Nervoshi in July as part of an eight-person engineering group, reporting to an engineering manager without independent spending or hiring authority. The firm employed sixty-two people and recorded ₹7.6 crore revenue in FY 1998. Scheduling rules initially looked like technical problems with tidy answers. Customer support showed me why a working organisation did not always fit those answers. A resource might be available for one task but unsuitable for another, or a change might create work for somebody who had not made it. I learned to investigate the operating context before treating an exception as an error in user behaviour. That curiosity led to the internal move into product analysis, where I could help decide which rule should be built in the first place.

Reason for the move

Transferred internally to product analysis