Article
February 11, 2026
Visa, Sr. Director of Product
Member
Most product advice assumes a simple operating model: move fast, ship often, iterate based on user feedback. That model works well for consumer software and early-stage SaaS. It breaks down quickly in highly regulated and complex domains like payments.
In payments (one of the most regulated and high stakes domains), every product decision needs evaluation by multiple stake holders such as risk/fraud teams and compliance/legal teams that determine viability of the product. A small change, like how money movement is approved to what data is logged when facilitating financial transactions, can have significant consequences on the product.
Having built and launched payments products in payments for more than a decade, I’ve learned that success doesn’t come from avoiding regulation or slowing innovation. It comes from designing products that assume constraints from day one. This article shares practical lessons for product managers building and launching products in payments and other regulated domains.
In most products, your primary stakeholders are customers, engineering, and design. In payments, additional stakeholders shape the product whether you involve them or not: compliance, legal, risk, fraud, audit teams, payment processors, banks and card networks.
The common mistake is treating these groups as downstream reviewers. By the time a product reaches formal review, it’s often too late to change foundational assumptions without delays or rework.
Strong payments teams involve these stakeholders early not to seek approval for every idea, but to understand non-negotiables. What must always be logged? What actions must be reversible? Where is flexibility allowed, and where is it not? For global products, regional nuances can lead to significant scope changes and pivots.
A simple but effective practice is maintaining a stakeholder map alongside the PRD. For each group, document decision authority, review cadence, and absolute constraints. This turns reviews into alignment checkpoints instead of late-stage blockers.
In consumer software, discovery typically starts with user pain points and ideation. In payments, discovery for pain points or enhancements must be accompanied by discovery of constraints.
Product managers should view regulatory requirements, data handling rules, transaction limits, and auditability as defining aspects of the solution space. Ignoring them early can lead to promising concepts that cannot be shipped.
One effective approach is to create a short constraints brief before feature discovery begins. This answers questions such as:
When teams align on constraints early, discovery becomes sharper. Instead of debating what is possible, teams focus on what is safe, compliant, and valuable within known boundaries.
High-performing product teams in fintech treat compliance as a core product capability as opposed to treating it as a gate at the end of development. This shift in approach can be in a counter-intuitive way very helpful in accelerating delivery.
Audit logs, permissioning, approval workflows, configurable limits, and policy engines may not feel customer-facing, but they dramatically reduce launch friction and long-term risk. More importantly, they make future product development faster.
In my past experience, we’ve made the decision to put in low effort monitoring and manual controls in place when testing new concepts. Most of the time, we ended up learning about surprising situations that the teams may have overlooked.
In regulated domains, MVP does not mean the smallest feature set. It means the smallest version of the product that is compliant, auditable, and operationally safe. My rule of thumb for product managers that I mentor is: understand that payments are high stakes because of how deeply personal they are for customers (not just because of regulation), and you will end up building products that more often than not comply with the regulation.
A payments MVP must answer questions that are often ignored early:
Teams that skip these questions may ship faster initially, but they pay for it later through delayed launches, forced rollbacks, or regulatory escalations. A well-designed MVP in payments may feel heavier, but it creates a foundation that supports faster iteration over time.
Payments launches are rarely binary. The safest and most effective launches are staged and intentionally constrained.
This might mean starting with internal users, a small group of trusted merchants, limited transaction volumes, or specific geographies. Feature flags, configurable limits, and controlled exposure are core product decisions.
A strong launch plan prioritizes observability over announcements. Can the team clearly see transaction failures? Are edge cases logged and reviewable? Is feedback routed to the right owners in real time?
Treating launch as a process reduces risk and builds confidence across stakeholders.
Agentic commerce, where AI agents initiate and execute transactions, will fundamentally change product decision-making in payments.
Historically, payments products have assumed a human decision-maker at the point of action. Agentic systems break that assumption. When software can decide when to pay, how much to pay, or which method to use, PMs are defining authority rather than designing flows. This shifts the PM’s role in three ways.
First, constraints become first-class product decisions. Transaction limits, approval thresholds, retry behavior, and reversibility define the safe operating boundary of an agent and must be deliberately designed.
Second, explainability becomes a core acceptance criterion. In an agent-driven system, success is not just a completed transaction, but the ability to explain why it happened. Auditability becomes part of product quality, not compliance overhead.
Finally, risk ownership shifts earlier. Decisions about defaults, permissions, and automation levels directly determine downstream regulatory and operational exposure. Risk is encoded at design time, not discovered at launch.
Agentic commerce accelerates the need for payments products that are architected for autonomy and accountability, and will amplify the need for regulation-aware product thinking.
Building payments products requires PMs to operate beyond feature delivery. The role becomes one of system design and long-term risk management.
Key skills include translating regulatory intent into product requirements, influencing stakeholders without formal authority, and evaluating tradeoffs across longer horizons.
Documentation, often undervalued elsewhere, becomes a force multiplier. Clear decision records prevent repeated debates and accelerate future development in regulated environments.
Regulation is often framed as a tax on innovation. In payments, it can be a moat.
Teams that design within constraints build more resilient, trustworthy products. They move faster over time because foundational decisions don’t need to be revisited. Customers, partners, and regulators gain confidence in their systems.
Building products in regulated domains is about choosing the right constraints early and using them to our advantage to build solid products that are fair and transparent.
We are proud to be a leading contributor in content for product leaders. See below for more great resources from Products That Count.
In this episode hosted by Sonjoy Ganguly, Emrecan Dogan will be speaking on why shipping more features doesn’t mean creating more value.
Explore the journeys of 2026’s top product leaders in our latest eBook. The Product Leader Awards spotlight leaders who are building learning organizations, making AI...
In this episode of the CPO Rising Series hosted by Jay Patel, Jonathan Shottan speaks on building the world’s largest kinetic dataset.