Hello
000
View

I get complicated things shipped — on time.

Technical Program Manager. I run the programs with too many moving parts, too many stakeholders, and a date that isn't moving. The messier it gets, the more useful I am.

CurrentlyTPM — Finbox
DomainFintech · Lending · Platforms
FocusDelivery · Clients · People
BasedIndia — working globally
ONBOARDING · BANK A ONBOARDING · BANK B ONBOARDING · BANK C PAYMENTS PLATFORM LENDING · PL LENDING · BL PLATFORM INTEGRATIONS SCOPE BUILD LIVE COMMITTED DATE
Scroll
DiscoveryDeliveryScopingDependenciesTrade-offsEscalationsJourneysLaunchesMetricsStakeholdersPrioritisationDeadlinesDiscoveryDeliveryScopingDependenciesTrade-offsEscalationsJourneysLaunchesMetricsStakeholdersPrioritisationDeadlines

How a program actually moves

SCOPE before the date is promised BUILD parallel, never sequential VENDORS INTEGRATE where most programmes slip RISK REVIEW ESCALATION HARDEN the week nobody scoped SIGN-OFF LAUNCH on the committed date
Swipe to follow the route
Impact
0

Programs delivered end to end — onboarding and lending

0

Partner platforms and institutions integrated with

0

Years running cross-functional delivery

0

Regulated domains — bank account onboarding and lending

Swipe
How I work, in practice
001

Launching a lending journey under a fixed date

001
Enterprise client

A full business lending journey, committed to a date before the requirements were stable. I negotiated scope directly with the client, ran the build across product, engineering, risk and several external vendors, and absorbed a mid-build policy change without moving the launch. The hard part was never the software — it was holding four parties to one sequence.

Client-facingMulti-vendorFixed deadline
002

Making reliability someone’s problem

002
Enterprise client

A consumer lending program running on third-party services no single team owned — when one degraded, everyone agreed it was bad and nobody owned fixing it. I set vendor SLAs, built the escalation path, and tied downtime to lost business so it stopped being an engineering complaint and became a number someone had to answer for.

Vendor managementEscalationsSLAs
003

Building the site you’re reading right now

003
Personal project

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.

ScopingIterationSelf-directed
In other words
“He handled escalations independently and effectively — managing complex client concerns with diplomacy and professionalism, rarely requiring my intervention.”
Kevin Thomas · Manager, Signzy Technologies
The route here
I've sat on all three sides of the same table — building it, specifying it, and owning whether it lands.

I started as an engineer, moved to translating business requirements into things teams could actually build, and now run delivery end to end. It means I know what a vague requirement costs downstream, because I've been the one receiving it.

Dec 2024 — Present

Finbox

Technical Program Manager

Own delivery of personal and business lending journeys for an enterprise client end to end — scope, vendors, engineering, risk and the client relationship — including taking those journeys live inside three major consumer platforms. The work lives or dies on dependencies nobody controls, which is the part I'm there for.

Owning delivery
Mar 2023 — Dec 2024 · ~1.75 yrs

Signzy Technologies

Business Analyst

Owned current-account onboarding programs for three of India's large banks and a major payments platform — translating what each client said they wanted into specifications engineering could build against, then staying with it through delivery.

Learning to specify
Sep 2021 — Nov 2022 · 1.3 yrs

Netcracker Technology

Associate Software Engineer

Built and shipped software on large enterprise systems, and spent the period shadowing a product owner — which is where I first saw how a requirement becomes a build plan, and how much gets lost between the two.

Learning to build
What I get called in for
A Getting it out the door
Programs that have to land on a date +
Multi-team, multi-vendor delivery where the hard part is never the code — it's the dependency graph, the integration contracts, and the four people who each assume someone else owns the decision. I find that gap early and close it.
Client and stakeholder management +
I sit on the client side of the table and the build side of it. Scope gets negotiated honestly, expectations get set before they're missed, and nobody finds out about a slip in the steering committee.
Delivery that has gone sideways +
Late, blocked, or quietly stalled. I come in, work out what's actually holding it — usually a decision nobody will make rather than a technical problem — and get it moving again without a reorganisation.
Last-mile problem solving +
The week before launch, when the vendor fails, the policy changes, or something nobody scoped surfaces. This is the part of the job I'm best at and, oddly, the part I enjoy most.
B Working out what to build
Turning a request into a problem worth solving +
Stakeholders hand over solutions disguised as requirements — "add this screen", "make it like theirs". I work it backwards to the actual problem and who has it, because building the request as stated is how teams ship things nobody needed.
Journey and funnel design +
Multi-step flows where every extra field costs you users. I map where people drop, separate the friction you can remove from the rejections you can't, and resequence so the expensive steps come after someone is invested rather than before.
Scoping and prioritisation +
What makes v1, what waits, and what quietly gets cut. Usually the useful work is arguing something out of scope rather than into it, and being able to explain that decision to the person who asked for it.
Defining what success actually means +
Agreeing the metric before the build, not after launch when everyone reverse-engineers a number that makes it look fine. Then instrumenting it properly, so the answer exists when someone asks.
About
Most teams don't need more ideas. They need someone who gets one all the way out the door.

I'm the person a program gets handed to when it has too many owners, a hard date, and a client watching. Plans are easy. Landing them through other people's teams, vendors and priorities is the actual job.

I started as an engineer, moved into writing the requirements engineering builds from, and now own whether the thing actually lands. Each step taught me what the previous one was getting wrong — and the pattern I keep finding is that programs rarely fail on the technical problem. They fail on the decision nobody wants to make.

I like the deadline pressure and I like the last-minute problems — the vendor that fails three days out, the requirement that changes after sign-off. That's usually when I'm most useful to a team.

What I want next is more of the hard version of this: regulated, multi-party programs where the date is real, the dependencies aren't mine to control, and shipping it requires getting a lot of people to agree on a sequence.

Program deliveryClient managementStakeholder alignmentRisk & escalation Vendor managementCross-functional leadershipScope negotiationProduct discovery
Mentorship — outside of work
Praffulchandra Jain
Nobody gave me the time to figure this out. That's exactly why I'm giving mine.

I didn't have someone to ask when I had no idea what I was doing. I had to work it out on my own, slower than it needed to be. So I keep a few hours aside every week for students and early-career folks — mostly the ones who don't have anyone in their family or network already doing this work.

This sits completely apart from my consulting work. Nothing is being sold here, there's no signup and no waiting list. You write to me, I write back, we talk.

01

Your résumé, read honestly

What a recruiter actually sees in the first eight seconds, which lines are doing nothing, and what to cut. I'll be straight with you rather than kind about it.

Students · Early career
02

Getting into product

How PM and TPM roles actually differ, what the interviews really test, and how to build proof you can point at before anyone gives you the title.

Career switchers
03

Interview practice

Mock rounds on product sense, metrics and execution — and turning what you've already done into stories that land instead of ramble.

Actively interviewing
04

The other stuff

Which offer to take. Whether to switch. How to handle a manager. How to stop feeling stuck. Not every question is a career question, and that's fine.

Anyone
Swipe

Tell me where you are and what you're stuck on. One honest paragraph is enough — I'd rather hear from someone unsure whether to write than have them talk themselves out of it.

Write to me
Contact

Got something that has to ship?