Banking, SaaS, BaaS, mobility & mCommerce — different industries, different customers. The job was always the same: see how every part connects, and make it one — and attract people to the mission.
A product is something you recommend — not because you're paid to, but because it solved your problem well enough that you want others to have that experience. The recommendation is the proof. Velocity, OKRs, NPS come after: they explain the result, they don't replace it.
Most problems aren't one thing. A bad customer experience, a process running on debt, two systems quietly contradicting each other — underneath, they connect. So before deciding what to build, I look for how the parts fit and where it actually breaks — not just the symptom in front of me.
The work is order, not a list. Some fixes are quick and temporary — a bridge that buys room for the real change later; some are foundations you don't rush. Weighed against what's real — time, capacity, vendors, the debt already there — that becomes a sequence: now, soon, long-term, or honestly never. That's what I mean by a roadmap: a direction, not a backlog.
I think in systems before features. When something feels wrong — a slow team, a fragmented product — my first question isn't "what should we change?" but "what setup keeps producing this?" The root is usually one of three: fragmentation nobody named, incentives pointing the wrong way, or ownership that exists in title only. Naming which one cuts through months of debate.
Speed only matters if it's repeatable.
The ticket is closed. The feature is not done. The problem is not solved. And it's not forgotten.
Process isn't the enemy of speed. Ambiguity is.
Transparency isn't a value — it's access: to the data, the metrics, the goals, the status.
Open to Director and Head of Product roles in fintech — building from zero, consolidating fragmented platforms and processes, and scaling them across markets with measurable impact.