A parallel between freediving and product management for the payments platform

Arraial Do Cabo, Brazil. Credit: Jonatha Borba

This will start a bit on a personal note to draw a parallel between sports (freediving) and one of our main priorities this year in the payment platform: 360 optimizations.

I am a product person and an avid freediver. In many ways, freediving made me a better product leader not only for its disciplined athletic dimension but also for the universal wisdom it carries. Having grown up in West Africa, I have been freediving for as far as I can remember. I came to product management a few years into my career as a software developer. I realized that yes, I loved solving complex problems, but I enjoyed even more finding out which problems to solve (i.e. what people really needed).

There are many parallels between freediving and product management. Here is one: you got to know what you are optimizing for.

Knowing what you are optimizing for in Freediving helps define the progression path

People seek different things when they put on a wetsuit and jump in the ocean or pool. Some come to tame a fear of the water, others to be better spearfishermen, a few come to perform and break records, and a growing number dive for the pleasure of being immersed. I am definitely in that last category. I came to know a bit later about the science behind the physiological response of the diving reflex, but it always felt awesome.

Let’s break down a dive. There are three phases:

Phase 1 or the “pure pleasure phase” is the initial phase. The diving reflex kicks in immediately when your face is immersed. It slows your heart rate, creates vasoconstriction (i.e. narrowing of blood vessels around the heart) and optimizes the blood flow toward the vital organs. Its objective is to enable immersion for an extended time. And yes, it feels great! Very comparable to a deep meditative state.

In Phase 2 or “I want to breathe phase” your body is telling you that you might want to bring in some fresh air. It is reacting to an elevated rate of carbon dioxide (CO2). This CO2 is a by-product of your body’s metabolism while it consumes oxygen and creates energy. It is supposed to be expelled when you exhale. In effect, you still have plenty of oxygen. This is only an early signal (i.e. it’s a leading indicator of troubles, not trouble yet). As you get to know yourself and these signals, this phase can also be understood, controlled, and agreeable.

In Phase 3 or “get me out of here” phase you are getting dangerously close to your limits. We also call it the “fighting phase.” This is the red zone. Either someone is holding your head down or you are definitely not here for the pleasure anymore except for the satisfaction of pushing your own limits. Training for this phase not only requires careful progression as with anything related to “limit” but also some mental preparedness. The Risk of syncope is always looming.

Knowing what you are optimizing for (i.e. long, deep and agreeable dives for me) is the prerequisite to determining your training. It starts by breaking down and controlling all the elements influencing the progression: 1) Stretching before a dive, 2) the right balance of air to take in the lungs, 3) the relaxation state, 4) The saving of energy through effortless movement, and even 5) controlling the train of thoughts running in your brain.

Now how do you measure it? To measure the agreeable portion of a dive you use the BOLT score. Hold your breath and count until you feel you want to breathe. For anyone, a healthy breathing pattern will get you a score of 40 or more. Less than that, you might want to consult. For experienced freedivers, this would be in multiple minutes. Remember, after the first urge to breathe the dive is not over, it is just more or less a struggle based on technique and experience.

More on this later. Let’s switch to the parallel with product optimization in a payments platform.

What are we optimizing for in Payments?

In the payment platform, we enable commerce and support our company’s mission to democratize financial services. Our merchants and partners leverage our platform to do just that: to enable commerce and reach users where they are. I like to think of merchants’ needs as a hierarchy with 1) The table stakes 2) Access to paying customers, and 3) Optimization.

1) At the base, the table stakes without which we can’t be in business. In the last few years, we “built an amazingly robust platform” as measured by our Availability numbers and our Straight Through Processing Rate. Security and Risk management have always been PayPal’s secret sauce. Being close and proactively compliant with our networks and regulators partners has also been part of our DNA since the beginning. This allows us to go up in the pyramid of needs to FOCUS and EXCEL in the upper layers.

2) Solving for access is an ever-evolving investment. Without diving into the topic, I would stress one aspect of our current strategy for access which has implications with our “optimization” layer. We go direct to the source and remove the middlemen as much as possible. Not only do fewer hops save cost, but it also increases our reliability, lowers latency, and increases the approval rate.

3) Once we provided relevant access, there are only a few things that merchants (and hence our platform team) would want to optimize for, and we’ve been doing this for years: Approval Rate, Speed, and Cost (more importantif you are a large enterprise). This is at the core of what we do as payment product professionals.

How are we optimizing going forward?

Exactly as with the practice of freediving, once we define what we are optimizing for, it creates different ways to think about it and progress. Here are a few implications:

First, we are not optimizing for three different things but for one — the removal of friction. As product managers in the payment space, we are always optimizing for the removal of any and all kinds of friction. You probably heard this before, “everybody wants to buy things, but no one wants to pay.” You can stretch this a bit: “no one wants to be reminded that they are paying by trying a different card, having longer than expected payments experience, or have to call customer support to … (fill in the blanks).” On the other hand, merchants want to focus on their business rather than having to orchestrate between multiple providers for approval rate or cost. We want to optimize payments so that merchants don’t have to, and so customers don’t have to think about it.

The merchant context/segment influences what to optimize for — if you are a small or medium-sized business (SMB), you probably don’t care how much processing a transaction costs since you pay a flat fee no matter what. If you are a Bill Pay company, you bill the customers with your card/payment instrument on file at set times. In this case, to some extent, the speed at which the payment is processed does not matter as much as the cost of a transaction. If you are a large car-hailing service with large volumes, the experience matters as does the cost of processing since you are on an Interchange++ business model (i.e. downstream cost passed through with a fee). So context matters. What we optimize for depends on the segment and the merchant.

Get it right the first time every time — once we know what optimization means for the merchant, we evaluate every single transaction in real-time. Then we dynamically set our processing rule accordingly. (e.g. Do we route via a Global Network or a local scheme if it’s a dual-brand card for that merchant category or for this transaction value?) Doing so, we are maximizing getting it right the first time, in return, this reduces our reliance on excessive retries which not only are costly from a transaction expense but also make the user do two full round trips with the processors.

Where are we going with this? In other words, we want to optimize for every single transaction at the transaction grain taking into account dynamically the merchant context/preferences. For that, our platform is increasingly becoming smart first with at least a Machine Learning model running for every single transaction, and up to three for certain transactions. All this without adding additional latency since our models are tightly integrated and take advantage of the white space in our processing stack.

And how do we measure it? We introduced a new metric (i.e. equivalent of the BOLT score in freediving). We call it the Primary Approval Rate (aka PAR score). It measures our ability to get it right the first time once we know what we are optimizing for by segment and merchant. As with freediving, the optimization is not over at the PAR score; this is simply the agreeable part where all our metrics are aligned. After that, we can still optimize, but it’s a controlled struggle.