Routable
B2b Fintech Startup
Cross-Border Payments
Timeline
~5 months
Main Squad
Waqas (Director of Product)
Ming (Pod Product Manager)
Chris (Tech Lead)
Hansel (Frontend Lead)
Supporting Squad
Olga (PD Director)
Diandra (Original feature PD)
Bianca (Design Systems lead)
Omri (Co-founder)
Routable
B2b Fintech Startup
Cross-Border Payments
Timeline
~5 months
Main Squad
Waqas (Director of Product)
Ming (Pod Product Manager)
Chris (Tech Lead)
Hansel (Frontend Lead)
Supporting Squad
Olga (PD Director)
Diandra (Original feature PD)
Bianca (Design Systems lead)
Omri (Co-founder)
Routable
B2b Fintech Startup
Cross-Border Payments
Timeline
~5 months
Main Squad
Waqas (Director of Product)
Ming (Pod Product Manager)
Chris (Tech Lead)
Hansel (Frontend Lead)
Supporting Squad
Olga (PD Director)
Diandra (Original feature PD)
Bianca (Design Systems lead)
Omri (Co-founder)
Context
Routable is a modern bill payments, payouts, and invoicing platform that primarily focuses on helping its clients automate their B2B payments.
My team, the Payments Method pod, enabled our clients to pay their international vendors in over 220 countries and territories. Routable calls this "cross-border payments" because all of Routable's clients are based in the U.S. and Canada (for the time being). Prior to these updates, clients could only pay vendors who also lived in the U.S. and Canada.
Problem & Opportunity
Several clients, as well as Routable's target market, need the ability to pay vendors in countries outside the U.S. and Canada (which many competitors offer). These businesses either used additional methods or a competitor product (like Bill.com) to pay their international vendors. Most of these companies estimated that ~30% of their payments were international, and some went as high as 90%. Since this is a table-stakes opportunity, strategic differentiation would come design.
Routable's TAM would nearly double from cross-border payments. And the proposed 1-2% take-rate (fee) on each payment could be worth $10-20M in additional revenue if Routable processed $1B in cross border payments for its clients, which executives projected to hit in the coming years.
Summary
I switched from a different pod in the middle of Q4 2021, and within 5 months, we had completed about 95% of the design work needed to support this initiative. Unfortunately, I was laid off near the end of the project due to company-downsizing.
Research & Strategy
By the time I joined, the Payment Methods pod had already run discovery interviews with clients and prospects to learn about their international payments wants and needs. We had most of the information we needed to confidently move forward, but needed to learn more about syncing international payment data with accounting software. I decided to run a qualitative survey in order to get information quickly and because it was unlikely deep discussions were required.
Creating the survey and identifying participants helped me ramp up fast, and the results of the survey helped us plan our product strategy for data syncing. Other than that survey, additional research wasn't necessary.
The product team had already broken the cross-border payments initiative down into epics that would allow us to ship early and often to a beta-testing cohort. The API had already been updated to support cross-border payments, which affected all projects to follow since that defined our data structure.
From this point on, my time was dedicated to being heads-down, checking in with internal stakeholders, and collaborating internally.
Research & Strategy
By the time I joined, the Payment Methods pod had already run discovery interviews with clients and prospects to learn about their international payments wants and needs. We had most of the information we needed to confidently move forward, but needed to learn more about syncing international payment data with accounting software. I decided to run a qualitative survey in order to get information quickly and because it was unlikely deep discussions were required.
Creating the survey and identifying participants helped me ramp up fast, and the results of the survey helped us plan our product strategy for data syncing. Other than that survey, additional research wasn't necessary.
The product team had already broken the cross-border payments initiative down into epics that would allow us to ship early and often to a beta-testing cohort. The API had already been updated to support cross-border payments, which affected all projects to follow since that defined our data structure.
From this point on, my time was dedicated to being heads-down, checking in with internal stakeholders, and collaborating internally.
Research & Strategy
By the time I joined, the Payment Methods pod had already run discovery interviews with clients and prospects to learn about their international payments wants and needs. We had most of the information we needed to confidently move forward, but needed to learn more about syncing international payment data with accounting software. I decided to run a qualitative survey in order to get information quickly and because it was unlikely deep discussions were required.
Creating the survey and identifying participants helped me ramp up fast, and the results of the survey helped us plan our product strategy for data syncing. Other than that survey, additional research wasn't necessary.
The product team had already broken the cross-border payments initiative down into epics that would allow us to ship early and often to a beta-testing cohort. The API had already been updated to support cross-border payments, which affected all projects to follow since that defined our data structure.
From this point on, my time was dedicated to being heads-down, checking in with internal stakeholders, and collaborating internally.
Iterative Design
My first priorities were:
Support development to display read-only cross-border payment data
Update the CSV Upload feature to support cross-border payments
A lot of work had already been done on how to display read-only cross-border payment data by Bianca, the designer who was previously on the Payment Methods pod and who was now focused entirely on the design system.
An amount like the above will appear in several different places. Most of my support was in working directly with developers to ensure elements were properly responsive and no data was being cut off. Lots of edge-case work across the whole product.
As for CSV Upload, I ran through many of QA's testing tasks, picked the original designer’s brain, and documented the existing flow in a diagram since I was unable to find one that was up-to-date.
Iterative Design
My first priorities were:
Support development to display read-only cross-border payment data
Update the CSV Upload feature to support cross-border payments
A lot of work had already been done on how to display read-only cross-border payment data by Bianca, the designer who was previously on the Payment Methods pod and who was now focused entirely on the design system.
An amount like the above will appear in several different places. Most of my support was in working directly with developers to ensure elements were properly responsive and no data was being cut off. Lots of edge-case work across the whole product.
As for CSV Upload, I ran through many of QA's testing tasks, picked the original designer’s brain, and documented the existing flow in a diagram since I was unable to find one that was up-to-date.
Iterative Design
My first priorities were:
Support development to display read-only cross-border payment data
Update the CSV Upload feature to support cross-border payments
A lot of work had already been done on how to display read-only cross-border payment data by Bianca, the designer who was previously on the Payment Methods pod and who was now focused entirely on the design system.
An amount like the above will appear in several different places. Most of my support was in working directly with developers to ensure elements were properly responsive and no data was being cut off. Lots of edge-case work across the whole product.
As for CSV Upload, I ran through many of QA's testing tasks, picked the original designer’s brain, and documented the existing flow in a diagram since I was unable to find one that was up-to-date.
This diagram was a useful artifact to define the steps in the flow that would need to be updated to support cross-border payments. This was the quickest way to start collaborating with developers and other stakeholders to limit assumptions, and it helped my new Product Management counterpart, Ming, understand the feature and proposed updates more quickly.
The CSV Upload epic ended up being a bit of a moving target, but since both the product manager and I were new in our own way, that would have been tough to avoid. My initial design explorations were quite conservative, which goes against what I typically strive for with this kind of timeline: Go big and pare back as needed. It seemed like I had wasted time early on, but it actually paid off when we needed a quick update to keep one of our beta clients from churning!
If you'd like to see the whole file, here's the link 🡥
Check out this slideshow for a deeper dive on the changes and the decisions behind them:
This diagram was a useful artifact to define the steps in the flow that would need to be updated to support cross-border payments. This was the quickest way to start collaborating with developers and other stakeholders to limit assumptions, and it helped my new Product Management counterpart, Ming, understand the feature and proposed updates more quickly.
The CSV Upload epic ended up being a bit of a moving target, but since both the product manager and I were new in our own way, that would have been tough to avoid. My initial design explorations were quite conservative, which goes against what I typically strive for with this kind of timeline: Go big and pare back as needed. It seemed like I had wasted time early on, but it actually paid off when we needed a quick update to keep one of our beta clients from churning!
If you'd like to see the whole file, here's the link 🡥
Check out this slideshow for a deeper dive on the changes and the decisions behind them:
This diagram was a useful artifact to define the steps in the flow that would need to be updated to support cross-border payments. This was the quickest way to start collaborating with developers and other stakeholders to limit assumptions, and it helped my new Product Management counterpart, Ming, understand the feature and proposed updates more quickly.
The CSV Upload epic ended up being a bit of a moving target, but since both the product manager and I were new in our own way, that would have been tough to avoid. My initial design explorations were quite conservative, which goes against what I typically strive for with this kind of timeline: Go big and pare back as needed. It seemed like I had wasted time early on, but it actually paid off when we needed a quick update to keep one of our beta clients from churning!
If you'd like to see the whole file, here's the link 🡥
Check out this slideshow for a deeper dive on the changes and the decisions behind them:
Around the time this was wrapping up, it became clear that we could no longer update various areas of the product to support what any of us would consider a minimum viable product for cross-border payments. Important data wouldn't show up in certain views, there were disclaimers left and right about why certain functionality was blocked, and important functionality was missing. My new priorities became:
Update the flagship payment flows to support cross-border payments
Update the vendor object across the entire product to support international vendors
Put another way, it was time to update the rest of the product. On top of that, this needed to be shipped in one quarter — a new requirement from executives.
Around the time this was wrapping up, it became clear that we could no longer update various areas of the product to support what any of us would consider a minimum viable product for cross-border payments. Important data wouldn't show up in certain views, there were disclaimers left and right about why certain functionality was blocked, and important functionality was missing. My new priorities became:
Update the flagship payment flows to support cross-border payments
Update the vendor object across the entire product to support international vendors
Put another way, it was time to update the rest of the product. On top of that, this needed to be shipped in one quarter — a new requirement from executives.
Around the time this was wrapping up, it became clear that we could no longer update various areas of the product to support what any of us would consider a minimum viable product for cross-border payments. Important data wouldn't show up in certain views, there were disclaimers left and right about why certain functionality was blocked, and important functionality was missing. My new priorities became:
Update the flagship payment flows to support cross-border payments
Update the vendor object across the entire product to support international vendors
Put another way, it was time to update the rest of the product. On top of that, this needed to be shipped in one quarter — a new requirement from executives.
Oh-Shit Design
I couldn't have agreed more with this new holistic approach — I had mentioned to several coworkers how disruptive it must be to have such an inconsistent experience, even for a beta-testing cohort. What I didn't expect was the short timeline to complete everything. Be careful what you wish for, I guess.
Payment method object
Decoupling address b/t vendor and payment method since the latter needs its own and can be different
Vendor object
Payment object vs bill object
Side-by-side complication
Oh-Shit Design
I couldn't have agreed more with this new holistic approach — I had mentioned to several coworkers how disruptive it must be to have such an inconsistent experience, even for a beta-testing cohort. What I didn't expect was the short timeline to complete everything. Be careful what you wish for, I guess.
Payment method object
Decoupling address b/t vendor and payment method since the latter needs its own and can be different
Vendor object
Payment object vs bill object
Side-by-side complication
Oh-Shit Design
I couldn't have agreed more with this new holistic approach — I had mentioned to several coworkers how disruptive it must be to have such an inconsistent experience, even for a beta-testing cohort. What I didn't expect was the short timeline to complete everything. Be careful what you wish for, I guess.
Payment method object
Decoupling address b/t vendor and payment method since the latter needs its own and can be different
Vendor object
Payment object vs bill object
Side-by-side complication