The Card PM's Day: What You Actually Do - ProductFTW #83
A card PM opens the day inside other companies' loops.
TL;DR
- A card PM's day is dominated by partner engagement: bank sponsor, processor, networks, fraud, and compliance.
- The real job is owning tradeoffs nobody else will: friction vs. fraud, speed vs. compliance, rewards generosity vs. unit economics.
- Most of your roadmap is non-negotiable work imposed from outside (network mandates, regulatory changes, partner audits)
- The PMs who thrive treat constraints as core to the product, not as obstacles.
- If you're trying to break in, learn the money flow first. The features make sense only once you understand how the program makes (and loses) money.
A good joke in product management is that the job description means something different to everyone. Someone who works on a continuous-development web product has a very different role from someone who makes packaged (installed) software, like core apps on a desktop.
Similarly, the tasks and responsibilities of a fintech card product manager differ significantly from those of a traditional software PM. Often, the role takes on a greater business or general management function. After building card and payment products at Green Dot, Wallaby, Bankrate, Apto, and Vertical Finance, here’s my take.
Wake Up to New Constraints and Requirements
A software PM usually opens the day inside their own loop: standup, designs, and the backlog. A card PM opens the day inside other companies' loops. Before I look at my own roadmap, I'm usually dealing with:
- An email from the bank sponsor asking for a change to a disclosure, a marketing review, or evidence for an upcoming audit.
- A processor ticket: the settlement file looked off, or a new feature needs a config change on their side that's gated behind their release cycle, not mine.
- A network bulletin (e.g., Visa, Mastercard) announcing a mandate with a compliance deadline I didn't choose and can't negotiate.
- A reconciliation exception: the bank sponsor report, processor settlement file, and network data don’t agree, and someone needs to figure out where the discrepancy originated before it becomes a customer or finance problem.
None of that was on my roadmap. All of it is now my problem. The first skill of a card PM is triaging externally-imposed work against the things you actually wanted to build, because the external work has hard deadlines and real penalties, and the internal work doesn't.
Even when all trade-offs feel bad, you still have to make them!
Here's the part that surprises people: the most important things I decide in a week aren't features. There are tradeoffs that sit between teams, where each team optimizes for its own metric, and someone has to own the whole.
- Friction vs. fraud. The risk team wants more verification steps; growth wants fewer. Every step you add kills some legitimate signups and stops some fraud. That curve is a product decision, and the PM owns where you sit on it. (This is why authentication in fintech is a product problem, not an engineering checkbox.)
- Speed vs. compliance. Engineering can ship the feature in a sprint. Legal needs three weeks and a change to the disclosure. The PM decides what "done" means and sequences the work so the launch is real, not a demo that can't go live. (See Managing the Legal Files.)
- Generosity vs. unit economics. Richer rewards drive signups and destroy margins. When rewards post, how repayment works, which payment options you surface: these feel like settings and are actually the economics of the program. (More in Why Rewards Timing Matters and Credit Card Repayment Timing Is a Product Decision.)
A generalist PM can have a great career without ever touching a P&L. A card PM who can't read the program economics is just taking dictation from the finance team.
Getting to the core product work
The middle of the day looks more familiar: working with design and engineering on the things you do control. It’s not photo sharing, as I like to say (sorry, photo-sharing PMs).
A bug in Instagram is an annoyance.
A bug in a card product can double-charge someone, decline a legitimate purchase at the worst moment, or expose data that triggers a regulatory filing.
That's why card products can't ship like software products: the operational discipline–testing, staged rollout, reconciliation, and rollback plans are heavier because the consequences are irreversible.
Today, systems are far more resilient, but I can recall outages that left cardholders at the lower end of the spectrum unable to pay for food or gas. That is not OK. You simply cannot lose people’s money!
When something does go wrong, the support experience becomes the product. A card PM spends real time on the unhappy path (disputes, declines, locked accounts) because that's where trust is won or lost.
So, why do you like fintech?
Good question. When I left Green Dot in 2009, I took a detour from fintech to work at yellowpages.com. I thought it would be so great to ship code all the time, work on the web, and avoid banks.
First lesson: if you want to avoid compliance issues, a company owned by AT&T isn’t a good call.
Second lesson: you can’t ignore your passions!
I enjoyed my time at AT&T and learned a lot there. However, the challenge of building reliable, secure, and life-critical fintech products holds an enduring allure for me. The higher stakes and the bigger challenges are motivating. I still build some apps on the side for fun, but I bring my desire for precision and accuracy over from fintech, rather than taking a break from it.
Fintech is more serious than many apps, but it is not as serious as medical research or the software that powers rockets. I don’t think fintech is directly life-or-death, but it is very serious. I enjoy the higher standard and working with my partners across the fintech stack (even if I sometimes wish banks would respond to compliance requests more quickly!).
Lessons for getting into fintech
The most common mistake I see from PMs trying to move into fintech is leading with feature ideas. The fintech interviewer doesn't care about your feature instincts yet; they want to know if you understand the money flow. Where does revenue come from (interchange, interest, fees)? Who are the partners, and what does each one control? What can the PM actually decide versus what's imposed by the network or the regulator?
Learn that first, and the features make sense. Skip it, and you'll design beautiful flows that legal kills in week one. The fastest way to learn the business your product lives inside is to read the card industry from the inside, which is exactly what our sister publication, CardsFTW, exists to teach.
About ProductFTW
ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.