How I think about product
From the teller window to the product suite
My career started where most people's relationship with money begins — at the bank. As a college teller, I handled real people's real money every day. There's something clarifying about that kind of responsibility. You're not thinking in abstractions; you're thinking about the person in front of you and what they actually need. That instinct has never left me.
When I moved into payments technology, I learned quickly that software is only as good as the understanding behind it. My first hard lesson came through defects — the kind that ruin a release and ruin your day. But the deeper lesson was upstream: requirements gathered poorly produce defects no amount of testing can save you from. More critically, users will rarely hand you a problem statement. They'll describe symptoms. They'll explain workarounds. They'll tell you what they want, not what they need. The job is to close that gap.
I've spent my career talking directly with clients and users — not because it's a best practice, but because it's the only way to really see your product. Every conversation opens a perspective you didn't have before.
“There is a 99% chance users are not going to tell you their exact problem. Understanding behavior is how you find it.”
Why Payments
The moment of trust
Payments is where finance becomes real. It's not a feature — it's the moment of trust between a product and the person using it. I've worked on both sides of the ecosystem, from issuing to acquiring, and each transition revealed a completely new world with its own rules, rails, and failure modes.
What I keep returning to is this: the technology changes constantly, but people's relationship with money doesn't. That tension — between the speed of innovation and the weight of trust — is what makes payments one of the most interesting and demanding problems in software.
Areas of expertise
Where I spend my thinking
User Research & Discovery
Users rarely hand you a problem statement. They describe symptoms, explain workarounds, and tell you what they want — not what they need. Getting to the real problem requires asking the questions that feel too basic to ask.
Payments Domain
Deep experience across both sides of the ecosystem — issuing and acquiring. From processing infrastructure to the user experience layer, I understand how payments work at every level of the stack.
Requirements & Definition
Requirements gathered poorly produce defects no amount of testing can save you from. Translating user behavior into clear, testable specifications is one of the highest-leverage things a PM can do.
Engineering Collaboration
Software development is a team sport. I learned early that the relationship between product and engineering determines the quality of everything that ships. The best outcomes come from shared understanding, not handed-down specs.
Recent from Martin Fowler