Open to TPM & product roles · Bengaluru
Technical program manager for regulated financial products. Five years across all three, and it shows in how I run programs.
2021 — 2022
2023 — 2024
2024 — now
The same product built for four enterprise clients across two countries — each with its own rules, and one team building it.
A multi-step sign-up redesigned so a missing document changes the route instead of ending it — every user gets a way forward.
A product embedded inside two of India’s largest consumer apps — three organisations, one plan, and review cycles nobody controlled.
What it actually took to turn "make me a website" into a page built for two different readers at once — and where the honest version of that process included redoing the same section three times before it was right.
“He handled escalations independently and effectively — managing complex client concerns with diplomacy and professionalism, rarely requiring my intervention.”Kevin Thomas · Manager, Signzy Technologies More recommendations on LinkedIn ↗
Open to technical program management and product roles. Based in Bengaluru, India. Email is the fastest way to reach me.
Current-account onboarding for three large Indian banks and a payments platform in the UAE — the same core problem each time, shaped by a different institution, policy and market.
A current account is opened by a business, not just a person — so onboarding has to establish both who the business is and who stands behind it. Each of these institutions wanted that journey to work digitally.
Three were large Indian banks. The fourth was a payments platform in the UAE, which meant a different market and a different regulatory context sitting on top of the same basic problem.
The problem looked the same four times. It never was.
Turned each client’s process into a buildable spec. I sat between the institution and engineering, translating how each one wanted onboarding to work into requirements the team could build against.
Separated what was genuinely different from what only looked different. Some variation came from real policy; some was just wording or order. Telling the two apart kept the build from splintering into four unrelated products.
Stayed with it through delivery. Requirements don’t end at sign-off — I stayed close to the build to answer the questions that only show up once engineering starts.
Working as the analyst on these is where I learned what a vague requirement costs downstream. It’s the main reason I run programs the way I do now.
Map each institution’s policy owners before writing a single requirement. The fastest way to a clean spec is knowing who decides what — not just what the current process happens to be.
Business loans for sole proprietors — people running a shop or a small trade, often without the paperwork a lending flow usually assumes. The job was to verify them properly without turning every missing document into a dead end.
Results across my Finbox programs program-level, not specific to this one case
A sole proprietor applying for a business loan is not a salaried applicant with a clean paper trail. Some have a GST registration; some have several. Some have a Udyam registration instead. Some have neither, and still run a perfectly real business.
A lending journey has to establish who the applicant is, where they are, and whether the business is real — and it has to do that in an order that doesn’t lose people before they’ve had a reason to stay.
Every verification step is both necessary and a place where applicants quit.
Sequenced the checks so each one earns the next. Mobile number and OTP first. Then PAN, with name, date of birth and gender fetched automatically rather than typed. Then the Aadhaar–PAN linkage check, then address and pincode — with serviceability confirmed before the applicant is asked for anything about their business.
Pulled GST from PAN instead of asking for it. Where the PAN mapped to several GSTINs, the applicant picks the right one from a list. Where it mapped to none, they can enter a GST number or a Udyam registration instead, upload a supporting document, or continue without one. Every applicant has a way forward.
Kept the lender visible throughout. Consistent branding across every screen, and the journey reachable from the lender’s own site — so a first-time borrower never wonders whether they’ve landed somewhere they shouldn’t.
My first instinct on journeys like this is to start sketching screens. The better starting point is two questions: which applicants are dropping out, and why. The answer decides which step deserves the most design effort — and it’s rarely the one you’d guess.
When a requirement arrives, ask what problem it’s solving and for whom before touching a single screen. Most requirements arrive as solutions — “add this field”, “make it like theirs” — and the real work is walking them back to the person who’s actually stuck.
A personal loan journey that had to work not only in the lender’s own channel, but embedded inside two of India’s largest consumer apps — each with its own rules, reviews and release schedule.
Results across my Finbox programs program-level, not specific to this one case
Distribution for consumer lending increasingly happens where people already are — inside the apps they open every day, not on a lender’s own site. So the same personal loan journey needed to run inside two large consumer platforms.
That turns a product build into a three-way program: the lender who owns the loan, the platform that owns the user, and the team building the journey in between.
Almost none of the difficulty was in the journey itself.
Kept one core journey, adapted only at the edges. Rather than building a separate flow per partner, the core lending journey stayed the same and only the entry point, presentation and hand-offs changed for each platform. One thing to test, one thing to fix.
Ran it as a program across three organisations. A shared sequence everyone could see, clear owners on each side, and an escalation route agreed before anything went wrong rather than improvised after.
Planned around partner timelines from day one. Review queues and release windows outside our control were treated as fixed dependencies in the plan, not surprises discovered near the end.
In partner integrations, the critical path usually runs through someone else’s organisation. The most useful thing a program manager can do is find that path early and keep the conversations on it moving — long before anyone is waiting on it.
Map every organisation’s approval path in week one. Engineering estimates are rarely what decides a launch date in embedded lending — the review cycle you don’t control is.
This portfolio started as "make me a website" and went through a dozen real direction changes before it looked like this. The interesting part isn't the animations — it's what had to be figured out underneath them.
Measured on this site checked while building it
The brief started as "I want to level up and be the best PM at my company," widened into "let's build a portfolio," and widened again into "make it look cool, like a top design studio." None of those are a spec. Each one had to be turned into an actual decision before anything could get built.
The harder problem showed up once real content entered the picture: this site needed to do two contradictory jobs. A senior hiring manager scanning it needs proof of delivery under pressure. A nineteen-year-old deciding whether to send a cold email needs it to feel warm and safe to approach. Most portfolios pick one register. This one had to hold both without either undercutting the other.
Three constraints stacked on top of each other, and each one changed what "good" meant.
Reframed before building. Early on, the instinct was to make requirements literal — "add branding," "make it flashy." Instead each request got pushed back to the actual problem underneath it: not "what animation," but "what does this page need to prove, to whom." It's the same move I make on programs, and it's how this site itself got made.
Anonymised rather than dropped — and kept honest. The strongest work stories involved a named employer and well-known partners, none of which were mine to publish. They were rewritten around the transferable problem with every identifying detail removed. Along the way, anything that had crept in as framing rather than fact came back out: the case studies say only what actually happened.
Separated the two audiences structurally, not just tonally. Mentorship lives on its own page, linked from the header, so a hiring manager reading proof of delivery never has to wade through a mentoring offer, and a prospective mentee never has to read it as a sales page. That page also deliberately uses less motion than the rest of the site — calmer, warmer, on purpose.
The visual craft got well ahead of the actual content more than once — a polished animation pass would ship while half the page still read "[X]" in metrics and placeholders in the case studies. Motion is the easy part to get right and the part most likely to be mistaken for progress. The harder, slower work — real numbers, a real testimonial, a real photo — came later, and the site was weaker until it did.
Scope creep isn't only a client-work problem — it happens just as fast on a project of one, especially when every new idea is easy to say yes to. And the thing that actually kept this project honest wasn' more polish; it was periodically asking "who exactly is this for, right now" and letting that question override whatever looked coolest in the moment.