Tell me about a time when you had to deal with ambiguity.

S: As part of one of my previous experiences, I was in-charge of building a payment verification portal for our finance operations team, and the target was to launch pan India. Initially, the plan was to launch the MVP in one state and then scale up the same aggressively pan India. However, last-minute client level requirements — such as differing documents, additional client specific data points to be captured, etc.— made it unclear whether this portal could be seamlessly used across all our clients.

T: I had to decide whether to delay the multi-state rollout, build complex client-specific logic, or move ahead with a generalized model. The ops team wanted coverage now, but engineering flagged a risk of compliance violations and rework.

A: Actions -

• Assessed different client requirements:Around 40% of our clients needed specific additional docs/ data points as part of their requirements, but there was no such record maintained in the system anywhere, it was present just in the SOP docs.

• Modularized compliance rules: Instead of hard-coding policies, I directed the team to build a compliance engine that could ingest configurable rule sets per client. This created short-term overhead but long-term agility. 

• Launched for normal clients: We did MVP for a few normal clients, followed by extension to our remaining normal clients and used BAU process for the remaining clients. Once the exception configs had been ingested into the system, then went ahead with an aggressive scale up plan launching for the remaining clients within a period of 4 weeks

• Used feedback loops: Integrated feedback and additional requirements in an ongoing manner
   

R: We launched on time for ~60% of our target regions and expanded to full base within the next 4 weeks, with no major compliance incidents. Engineering velocity improved due to modular rule logic, and our regulatory adaptability became a selling point for new enterprise customers.