Abhijeet (Abhi) Ranadive is Chief Product Officer at Routable, where he leads product strategy for the company’s payments experience, including its instant payouts capability. Routable is a payouts platform that gives enterprise companies end-to-end orchestration across approvals, compliance, and reconciliation, so they can automate and scale high-volume payouts globally via a developer-first API. He previously served as VP of Product for Galileo FinTech at SoFi, and held product leadership roles at Intuit, Braintree (a PayPal service), and PayPal, following earlier work in enterprise architecture and API management at Cisco.
In this conversation, Abhi talks about what it takes to build instant payments into the core of a customer experience - from identifying the specific moments when speed actually matters to a customer, to keeping the underlying complexity of real-time money movement invisible to the people who depend on it. He shares how Routable rethought its product experience around trigger moments and conversion, the metrics that became essential once decisions had to be made in near real time, and why trust, rather than speed alone, is what keeps a payments product credible.
Rethinking the experience for instant payments
Instant payments aren’t simply a faster version of traditional payments — they change the economics of a marketplace. What do product teams need to rethink once payment becomes part of the customer experience rather than just the first step in a workflow?
Customer empathy is a foundational pillar for our product team, and it’s one of our company’s values. For us, it was: How do we engage with empathy with our customers? We are a two-sided platform in many ways: the businesses sending money and the payees receiving it. What we uncovered was that they want to shorten the loop of earning and getting paid and the instant rails are increasingly in demand to accomplish that quickly.
When we talked to our customers, we found that they were very interested as well, because for them it was a retention lever. It was like, “Hey, my payees and stakeholders need it, and it will help us make them more satisfied and help them close that gap between earning and paying.” We needed to rethink our experience because it was not built for real time payments, and we had to find where the trigger moments were.
There are a lot of payees who are like, “Give me the money, I am fine whenever it comes.” but there are others who are really interested in instant payments. We wanted to capture the group that was super interested and had high intent. The other interesting insight was that there was a segment that was very interested in instant payments on the weekends — maybe they needed the money for a trip and couldn’t wait for Monday. So we realized that there was a group that always wanted instant and others that wanted it situationally at the right moment, but how do we find those moments and trigger the experience at that moment?
We had to think about the customer journey and figure out how to insert the experience, and what kind of experience could help make that choice. It’s almost like a checkout conversion. Once we have that buyer intent, how do we convert that intent into action as fast as possible and close that gap? Those were the two big aspects of rethinking the experience for instant payments.
There has been a shift in the market, too. There was a time when instant payments didn’t have much adoption, there wasn’t as much customer propensity to take it on. But with the new rails coming in — RTP and FedNow, and even stablecoins, we’ve seen a shift in the market in the last 12 to 18 months where instant has become the primary choice for all parties. In the past, the recipient always wanted their funds fast, and that makes sense. But now every party sees the benefit of having instant visibility into transactions. Instant has become a core pillar of our product strategy. We pride ourselves on paying anyone anywhere, including global markets, so having instant payment available not only in the U.S. but in international markets is the core strategy for our business.
What customers actually wanted
Besides the segment that wanted payments faster on weekends, were there other customer needs you uncovered?
From a payee standpoint, those were the two critical insights: There are some groups that say, “I always want it fast,” and the other group was a bit more situational.
One of the things we learned from the businesses was that, for them, instant was both a retention lever and a satisfaction lever. We also saw that instant could be a monetization lever, giving businesses an opportunity to turn payments into a profit center rather than simply a cost of doing business. This is what we are championing with our clients: If you can enable instant and close the gap between earn and pay, then you can drive satisfaction and retention for your payees and also create value for the business.
Balancing speed and trust
FinTech products require balancing speed, risk, and trust. Have there been situations where making a product faster would undermine customer trust, or the other way around?
Trust is our real product. In payments, the businesses we serve value that they can trust us to send the money to the counterparty. The receiving parties trust that we will deliver the money to them. We always strive not to undermine this trust at any point, and we also have to ensure there is no operational complexity.
One of the things we’ve enabled well is what I call a product operations function, which is to look at the product and the needs of the clients post-launch of the product in the market. Many product teams are focused on building the product and launching. But I think the hard work comes after the launch, because that’s when you have to fine-tune the product and make sure it’s operationally viable. We talk about value and viability, and that is what PMs own. Most of the time viability is business viability, and that happens upfront. But if the operational viability for the product is lacking after the launch, it will be very hard to keep the product maintained in the market, no matter how valuable the product is. So we reversed it, and took a pre-mortem approach: What will go wrong, and what do we need to have upfront to make it operationally viable?
We spent a reasonably good amount of time on beta and pilot before going to GA. That wasn’t because we weren’t feature complete, we were feature complete in a traditional sense, but we wanted to build hardened requirements for supportability and operations. So even if one transaction doesn’t get to the intended party, or it’s late or delayed, we can have a remediation with the right tools. It’s all about visibility, having the observability, and then having a remediation action. I have a product operations lead on my team who was super focused on building those requirements upfront in the product build cycle, rather than after the fact.
Leading the cross-functional build
Building products like instant payments requires close alignment across product, engineering, banking partners, fraud, operations, and customer support. What leadership practices become most important for that kind of cross-functional alignment?
One of our key values is “Collaborate to win.” I strongly believe that successful teams have a clear north star metric that everyone is aligned to. It’s about shared outcomes and shared context. It’s easy to say this, but it’s hard to practice. Getting buy-in and alignment is where the real hard work is — communicating it out and getting the buy-in. Once you establish and get that buy-in, execution is smooth.
It takes a lot of upfront hard work to get that shared outcome and shared context. But, the hardest part was getting that alignment, not just with internal parties but with some of the external partners too. Once we got external partners to buy into the north star and gained that alignment, the rest of execution was much smoother.
That must be difficult, too, since regulatory and compliance factors change over time.
Compliance and risk are big for us, so we had those functions participating right from the outset. In fintech, regulatory compliance is part and parcel of the product design. The bigger issue to tackle was focus and prioritization. We took a few cycles to build it, considering the complexity of the product buildout. The real question was how do we keep teams focused and filter out all the noise? This is where a lot of the product leadership role comes in: Make sure your teams are focused, do continuous and rigorous prioritization, and make choices of what not to do, especially saying no to a lot of non-critical product requests, so the team can remain focused on what they need to deliver.
Several of your products, including this one, required building entirely new capabilities rather than extending something that already existed. When you’re creating a new team around a technically complex problem like that, what do you focus on first?
I’m a big fan of product vision north star, aligning the shared outcome and then sharing the context across all teams. That’s a crucial step, especially for a large cross-functional team. The first step is team formation, staffing the right people, this product required a village to build. But the other important part I want to call out is the right process to complement the team — we use this execution framework called Shape Up. It operates on a six-week cycle, and every six weeks you build something that is either demoable or releasable. It’s very different from agile methodology — it’s based on agile principles, but it takes it to the next level.
I want to tie this back to the product operating model: How do you create a truly empowered team? We’ve been working for a while on this concept of empowered teams of engineering, product, and design, that can take a problem, own it, work through the Shape Up methodology to break it down into six-week cycles with clear goals, and then execute on that. Creating the shared context and shared outcomes and getting that alignment upfront, plus the model of empowered teams using the Shape Up framework, has helped us move with high velocity toward the desired outcome.
Data at the speed of instant
Instant payments don’t just speed up access to money — they also accelerate learning about customer behavior, like the insight about weekend timing. How did having those near real-time signals change the way you make product decisions?
With instant payments, you have real-time data. Data-driven is one of the key principles we had, but instant took it to the next level. In a more traditional sense, you could probably get away with looking at data weekly, but in an instant scenario, we had to build metrics and dashboards so that almost at a daily level we are looking at the data and how things are performing. For example, not everyone is eligible for these instant offers, so we want to make sure that we continuously monitor the eligibility and how the funnel is converting.
We get real-time data and make decisions based on it. Our operating model changed to a consumer-centric mode where the data and decisions are real-time. Instant changes that paradigm for B2B. Now you’re in a consumer-centered model where you’re reviewing data in real time, looking at product behaviors and user behaviors, and adjusting levers in real time. Using those levers so we can adjust them in real-time to hit our outcome metrics was a substantial change for us.
You’re analyzing data more frequently. Are there certain metrics that have become more valuable given the shorter payment cycle?
At an overall level, the north star metrics didn’t change. But at a more granular level, we had to enable new metrics. One of which is the eligibility percentage: How do we maximize the percentage of transactions that qualify for instant?
This goes back to the tradeoffs we discussed on risk and compliance complexity, which are being managed through the eligibility criteria. We had to balance maximizing reach while minimizing compliance risk and fraud risk. We had to figure out how to balance them to have high eligibility and low risk.
The second lever was conversion. You may have a high intent, but the intent may not translate into completed action. So how do you close that gap between intent and action? We built an end-to-end metrics funnel, from notification email sent, to email opened, to button clicked, and then to accepting the instant offer. Enabling that funnel conversion metric was a big part of what we accomplished, and we’ve built a culture to make decisions based on this metric.
Owning the complexity
Reducing the time between work and payment is clearly a benefit, but it adds complexity on the technical and operational side. How do you decide what parts of that complexity customers should experience, and which should remain invisible?
One of our core product tenets is to own the complexity, it’s also Routable’s brand promise. We own the complexity so that there is no operational chaos on the customer side. We need to tackle regulatory complexity, fraud management complexity, and experience complexity. So, how do we make all of this simple and almost invisible to both parties, especially to the clients who are sending money? That was the key for us: building an experience that does not require much incremental effort for either party.
We inserted a trigger moment in the payment notification. If you’re already getting these notifications, that’s the right moment to make a choice about changing the payment speed. We had to figure out how to insert an experience that is seamlessly integrated into that notification trigger and doesn’t come across as a marketing offer. That was a core tenet for the experience design.
There was another level of complexity — technical architecture complexity. It’s not just about the payment; with the rails and the experience being instant, and all these real-time signals, the platform had to evolve to support instant money movement. Money movement is now happening in seconds versus minutes, so we decided to build a new platform to support the needs of the experience. That was another complexity we had to abstract away from both parties, we rolled it underneath the experience so it’s invisible to the customers.
You ask about tradeoffs. For Routable, it’s not a tradeoff of convenience and complexity. It’s really about trust - that’s our product. Our clients trust us to pay what is due, and our payees trust us that they’ll get what they are owed. That was something we didn’t compromise on. We won’t make tradeoffs on trust or on compliance and risk, but we will make tradeoffs on our timeline to get us to our goals.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.