The hidden trade-off between global growth and local optimization

A regular look at the decisions, trade-offs, and compromises behind building payments.

Every payments product manager is constantly balancing priorities, managing a list of problems they know they should solve.

Enter a new market, improve conversion rates, reduce payment failures, or optimize existing payment flows.

The question is rarely whether those problems matter. The question is: which one gets your team's attention first?

The trade-off I didn't expect

I experienced this firsthand while working at Decathlon.

At the time, one of the company's strategic priorities was accelerating growth in one of our fast-growing markets: South Korea. A key part of that strategy was supporting local payment methods. For Korean consumers, paying with familiar payment experiences is essential, so integrating Korean Cyber Payment (KCP) quickly became a clear business priority.

Even with a strong payments engineering team, what looked like a straightforward integration quickly became much more complicated. Technical challenges, testing limitations and unexpected issues turned what we expected to be a relatively simple project into weeks of engineering work.

But the engineering effort wasn't what stayed with me. What stayed with me was the opportunity cost. 

While we were investing weeks of engineering time to unlock one market, we were postponing improvements that could have benefited many others. At the same time, we were dealing with tokenization challenges that were affecting payment performance across some of our largest markets, but we simply didn't have the engineering capacity to tackle both initiatives.

That was the trade-off. 

Ignoring South Korea wasn't an option, but neither was ignoring the payment performance of our biggest markets. Both priorities were valid. The difficult part was accepting that choosing one inevitably meant delaying the other.

I finished that project thinking differently about payments than when I started it.

The opportunity cost nobody talks about

What that experience taught me was that every new payment integration carries a hidden cost. And that cost isn’t just the engineering effort required to deliver it. It’s everything your team can't work on while it's happening. 

While you're integrating a new payment method, other priorities like improving authorization rates, solving tokenization issues, or optimizing checkout don't disappear. They simply move further down the roadmap.

That's when I realized the hardest part of payments product management isn't deciding what's important. It's deciding what has to wait.

The best payment teams aren't the ones that build everything. They're the ones that create enough flexibility that they don't have to keep making the same trade-offs.

From solving payment problems to solving trade-offs

That experience changed the kinds of problems I wanted to solve.

Today, working on the platform side at Primer has given me a different perspective on those trade-offs.

I don't spend my time thinking about how to make another payment method easier to integrate. I think about how merchants can stop treating every payment decision as an engineering project in the first place.

Modern payments infrastructure should give businesses the flexibility to evolve their payments strategy without constantly reshuffling engineering priorities.

Adding a local payment method shouldn't consume an entire roadmap. Neither should testing a new routing strategy or adapting a checkout flow for a new market.

Those should be operational decisions, not engineering ones.

That's the kind of problem I'm excited to work on because it gives payments teams more time to focus on improving performance, while engineering teams stay focused on building the products that differentiate the business.

Every roadmap is really two roadmaps

Looking back, the biggest lesson I took away from this experience is this: 

Every roadmap is really two roadmaps.

There's the work you choose to build, and there's the equally important list of valuable initiatives that have to wait.

The reality is that every product team has trade-offs, but they shouldn't have to make those trade-offs every time they want to grow.

‍